Shunze 學園 > 搜尋 > 搜尋結果 哈囉，還沒有註冊或者登入。請你[註冊|登入]

作者 文章
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》API應用範例顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

在防止“暴力猜測帳密”上，由於XG只是進行routing，將連線需求轉給後端的server，
所以XG本身並不知道每次連線所輸入的帳號/密碼是否正確？
自然也就無法辦到“輸入錯誤帳密幾次後，封鎖惡意IP”這樣的工作...

但假設後端主機可以主動擷取“輸入錯誤次數過多的IP資訊”,
那XG能否主動去封鎖這樣的惡意IP連線？

答案是可以的！
XG提供API功能，讓後端主機可以透過XML格式，將要阻擋的IP物件直接在XG中建立。
我們只要在防火牆規則中，預先建好阻擋規則，
再由後端主機去維謢這個block IP清單或群組，就可以實現這樣的需求。


使用API功能時，請先確認執行的管理員帳號是否具有物件的寫入權限。



然後再於API Configuration中放行後端主機的使用權限，



這樣就後端主機就可以使用管理員權限帳號來執行API功能了∼


首先，我們可以透過以下指令來查看IP物件清單與格式。

https://XG_IP/webconsole/APIController?reqxml=<Request><Login><Username>admin_account</Username><Password>P@ssw0rd</Password></Login><Get><IPHost><Name></Name><IPFamily></IPFamily><HostType></HostType><IPAddress></IPAddress></IPHost></Get></Request>


若我們要取得Block_IP這個IP List物件的內容，可透過以下指令。
https://XG_IP/webconsole/APIController?reqxml=<Request><Login><Username>admin_account</Username><Password>P@ssw0rd</Password></Login><Get><IPHost><Filter><key name="Name" criteria="like">Block_IP</key></Filter></IPHost></Get></Request>


若Block_IP這個IP List物件不存在，我們可以透過以下指令來建立。
https://XG_IP/webconsole/APIController?reqxml=<Request><Login><Username>admin_account</Username><Password>P@ssw0rd</Password></Login><Set operation="add"><IPHost><Name>Block_IP</Name><IPFamily>IPv4</IPFamily><HostType>IPList</HostType><ListOfIPAddresses>199.199.199.199</ListOfIPAddresses></IPHost></Set></Request>


若Block_IP這個IP List物件已存在，我們可以透過以下指令去更新它的IP內容。
https://XG_IP/webconsole/APIController?reqxml=<Request><Login><Username>admin_account</Username><Password>P@ssw0rd</Password></Login><Set operation="update"><IPHost><Name>Block_IP</Name><IPFamily>IPv4</IPFamily><HostType>IPList</HostType><ListOfIPAddresses>199.199.199.199</ListOfIPAddresses></IPHost></Set></Request>


要刪除Block_IP這個特定IP List物件，則可透過以下指令。
https://XG_IP/webconsole/APIController?reqxml=<Request><Login><Username>admin_account</Username><Password>P@ssw0rd</Password></Login><Remove><IPHost><Name>Block_IP</Name><IPFamily>IPv4</IPFamily><HostType>IPList</HostType></IPHost></Remove></Request>


若我們不想用IP List物件來管理，想要透過IP群組的方式來管理，
將要被封鎖的IP物件直接加到Block_IP_Group群組中，可以透過以下指令來建立隸屬於群組的IP物件。
https://XG_IP/webconsole/APIController?reqxml=<Request><Login><Username>admin_account</Username><Password>P@ssw0rd</Password></Login><Set operation="add"><IPHost><Name>Test_IP</Name><IPFamily>IPv4</IPFamily><HostType>IP</HostType><HostGroupList><HostGroup>Block_IP_Group</HostGroup></HostGroupList><IPAddress>199.199.199.199</IPAddress></IPHost></Set></Request>



有了以上幾個sample指令後，
在後端主機上，我們就可以透過curl(linux主機)或powershell(Windows主機)於XG上直接建立封鎖物件了∼


參考資料
How to use the API



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2020-09-11, 12:11 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》更新補充顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

上文範例為LAN to DMZ的UDP flood設定，
如果是要防護來自WAN to DMZ的TCP flood又該如何設定呢？

由於來自WAN端的外部IP是無法直接連到位在XG內部的Server，
這類連線需求必需透過XG的business application rule進行DNAT轉址後才能辦到，
因此設定WAN to DMZ的flood防護時，雖然最終目的是內部Server的虛擬IP，
但在設定時，還是要把目標IP設定為XG上mapping給內部Server的外部IP。

例如XG上的WAN配置了一個外部IP 123.123.123.1，
並把這個IP的TCP 8080 port導向內部web server 172.16.16.1。
那我們要對這台web server進行TCP flood防護時，
就該進行如下的配置。

system dos-config add dos-policy policy-name SYN-Flood_over_200 SYN-Flood 200 pps per-src
system dos-config add dos-rule rule-name W2D_TCP_8080 src-zone WAN dstip 123.123.123.1 netmask 255.255.255.255 protocol tcp dport 8080 dos-policy SYN-Flood_over_200


以上指令在參照上述的說明後，目標IP的選擇沒有太大問題，
比較有問題的會是，為什麼我們要擋的明明就是TCP的flood，但在dos-policy中的設定卻是SYN-Flood？

這是XG上比較吊詭的地方...
在 dos-config 中的flood參數只有SYN-Flood，沒有TCP-Flood；
而在 dos-rule 卻反過來，protocol的參數只有tcp，沒有syn！？
所以在TCP flood的防護上，只能使用這樣的配搭配設定了...



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2020-09-11, 12:07 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》重設admin密碼顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

在韌體版本17.5之前，
要重設admin密碼只能用console線接著，然後在開機時按下Enter鍵，選擇進入SFLoader來達成。









在韌體版本17.5之後，原廠增加了一個新的方式，
一樣用console線接著，然後在輸入admin密碼時，直接輸入RESET進入特殊的功能選單。

登入後會發現17.5的選單多出了 4 的功能選項，提供管理者重設admin密碼。
重設後的admin帳號密碼為admin，
請登入WebUI後再去變更為所要的密碼。



17.5之前(如下圖)，就只有三個選項，沒有重設admin密碼的新功能。




參考資料
How to reset the admin password



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2020-02-12, 10:55 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》透過IPsec VPN將分公司流量全部導向總公司，怪怪的？顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

客戶有需要，要將分公司流量透過IPsec VPN全部導向總公司，
然後統一在總公司做網頁控管。

IPsec VPN串好了，但分公司user對外卻有些怪怪的？
有些網站打不開、Line只能通話，無法傳送接收訊息？
這是怎麼回事？



原來這是一個和TCP設定封包所帶的資料上限MSS (maximum segment size)有關的問題。
MSS的預設大小是1460，在這樣全導向總公司的環境中，
封包在分公司經過IPsec再次封裝後，就有可能超過1460的允許大小，而導致部分網站與應用軟體無法正常開啟。

原廠建議修改的大小為1300，
我記得在之前的某些版本XG，可以直接在WAN的interface設定中去修改MSS的大小。



但在這個最新的17.5.9 MR-9版韌體中，
修改這個設定是無效的，狀況無法排除！
必需在分公司的XG中，於advanced shell中以iptables指令來設定MSS的大小為1300。

iptables -t mangle -I POSTROUTING -s 192.168.2.0/24 -d 0.0.0.0/0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300;
iptables -t mangle -I POSTROUTING -s 0.0.0.0/0 -d 192.168.2.0/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300;


查詢iptables指令設定結果如下。
iptables -L -t mangle | grep TCPMSS


不過這個指令不是永久性的，重開機後就失效了。
為了讓它永久性的的生效，可以把它寫在 customization_application_startup.sh 中，
流程如下。
mount -o remount,rw /
vi /scripts/system/clientpref/customization_application_startup.sh
mount -o remount,ro /


完成後的 customization_application_startup.sh 應該有如下的內容。
#!/bin/sh
iptables -t mangle -I POSTROUTING -s 192.168.2.0/24 -d 0.0.0.0/0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300;
iptables -t mangle -I POSTROUTING -s 0.0.0.0/0 -d 192.168.2.0/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300;
exit 0;


經過以上的調整後，分公司透過總公司連外的奇怪問題總算是一舉排除了∼



參考資料
How to set the MSS value for remote network(s)
IPSec VPN - Path MTU
TCP maximum segment size 是什麼以及是如何決定的



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2020-01-03, 13:55 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》Bridge Mode下所有網頁都打不開？顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

同事在使用bridge mode做PoC時遇到了一個奇怪的問題，
當啟用Web Filter時，所有網頁都打不開，
即便是選擇Allow All也一樣！

但改為none時，所有網頁卻都可以正常開啟了！
這是怎麼回事？


原來有沒有啟用web filter在封包的處理上有很大的不同，
當選擇為none時，XG不進行過濾，封包直接經由橋接配對送到另外一端。

但選擇其它web filter時，XG會以proxy的架構來處理封包，
封包會先停留在XG上，然後由XG比對pattern，判定這個封包該擋，還是放？

這時若XG本身無法更新pattern，那麼在檢查時就會出了問題，無法判斷該擋還是該放？
然後就造成了啟用web filter後，所有網頁無法開啟的狀況！

同事的這個案例，是因為環境中有兩個routing設備-既有防火牆與Core Switch，而XG就夾在兩個設備之間。
在這個案例中，XG的gateway指向既有防火牆與Core Switch都可以連外，所以也沒有想到會是gateway的問題。

直到後來發現雖然gateway指向既有防火牆可以通，
但XG的license sync與pattern update都會失敗，才發現是這個問題。
在將gateway改指向Core Switch後，問題總算順利排除。

至於環境中的gateway究竟是要指向既有防火牆還是Core Switch？
這要看環境架構而定。
不過一個簡單的測試方法就是去試license sync與pattern update，
成功了，就是對的；錯了，就改成另一個吧∼



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2019-12-25, 15:35 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》SSLVPN無法連結Alias IP的服務？顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

客戶反映一個問題，透過SSLVPN連公司後，
VPN user無法再透過XG WAN端的alias IP連回內部主機服務，
即便在既有的W2L business application rule中，於來源區域再加入VPN也不行...

這個問題在測試後，確實如此！
以traceroute去追踪，發現只有撥入的WAN介面IP可以追踪到，
其它alias IP都完全沒有回應，
這實在太怪了！


最後順子發現，除了上述business application rule中來源端需加入VPN區域外，
還需要在SSLVPN的設定中，將alias IP加入“允許的網路資源”中，這樣才能解決此問題。



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2019-10-28, 16:21 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》No LAN to LAN loopback rule顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

Cyberoam在建立Virtual Host服務時，
會很貼心的幫管理者自動建立LAN to LAN的 loopback 規則，
讓內部user也能透過此Virtual Host的外部IP，連到開通服務的內部主機。
順子認為這點是Cyberoam優於Sophos XG的一個地方。

但奇怪的是，客戶的Cyberoam在建立Virtual Host時，
卻不會主動建立loopback規則，管理者必手動補上這種規則。

這問題以前在奕瑞時遇到過一次，
但反正都可以手動補建loopback規則，且客戶沒有反映，所以就不了了之...


最近新接觸的客戶又遇到了相同問題，
這次，順子開了case，想到明確知道如何去處理這問題！

開case後，經原廠查看驗證，這問題可透過組態檔還原到其它設備，而重現此問題，
也就是說，這問題不是硬體上的問題，而是組態上的問題。

之所以產生此問題，是因為Cyberoam database裏的NAT表格中，
預設值有亂碼所致。

不過很遺憾的是，解決方式原廠並沒有透漏，
且強調只能在LAN端以SSH連入修正。
而我並不在客戶端現場，所以沒看到原廠是透過哪些指令連入修正...

因此最後我還是不知道該如何修正此問題，
若不幸遇到此問題時，還是只能開case請原廠協助處理了。



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2019-10-16, 14:40 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》透過聯防阻止L2層級的病毒擴散顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

防毒軟體與防火牆聯防，是Sophos在併購了Cyberoam後的主要產品訴求。

封包在經過Sophos XG routing後，可以直接透過防火牆規則，來阻止中毒電腦的橫向擴散。





但L2層級，不經過Sophos XG的縱向擴散，Sophos又是如何進行防禦呢？



很明顯的，由於L2層級的封包直接就在交換器上交換掉了，
所以無法透過防火牆來防禦，
要防禦L2層級的縱向擴散，只能透過防毒軟體來進行。

要做到縱向擴散的防禦，Sophos在Sophos Central上提供了以下兩項設定。

  • 拒絕來自中毒電腦的連線



    啟用這項設定後，中毒的電腦就無法再與您的電腦進行聯繫。

    這項設定是在Sophos Central中 Global Settings 裏 General 區塊下的 Reject Network Connections 中設定。



  • 中毒電腦的自我隔離



    啟用這項設定後，中毒的電腦會被Sophos Central自動隔離，
    除了幾個修正中毒狀態的必要網站外，其它IP、FQDN都會被Sophos Central禁止連結，來達到保護效果。

    這項設定是在Sophos Central中 Endpoint Protection 裏 Police 中的 Threat Protection 中設定。
　

搭配Sophos Central與Sophos XG進行聯防後，
不論橫向或縱向的病毒擴散，都在聯防機制下多了一層保護∼


有客戶在問，L2防止擴散機制，一定要有XG防火牆參與在其中嗎？
能否略過XG，直接透過Central向端點Agent通知，進而達到縱向的防禦效果？

答案是不行...
原廠 KB 中有提到，這個機制是由防火牆來share有問題的端點網卡，
所以需要防火牆居中傳遞。



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2019-09-23, 12:34 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》Wifi Roaming顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

Sophos XG的Wifi Roaming一直飽受用戶質疑其功能，
有不少用戶在 Community 中反映，手機必需斷線再連線才會切到另一個訊號較強的AP。
若真的需要斷線再連線才會切換AP，那還叫Wifi Roaming嗎？


Wifi Roaming 802.11r是需要在無線設備與用戶端兩邊都支援的情況下，才能順利運作的。

Sophos上要啟用Wifi Roaming，很簡單，只要啟用“Fast Transition”即可，
不過要能看到“Fast Transition”選項，加密的部分必需選擇WPA2以上的“AES”才行。



在XG上成功啟用“Fast Transition”後，接著就是用戶端的問題了。


在一般的認知上，我們都以為用戶端設備在同時支援2.4G與5G的情況下，
傳輸能力較好的5G會優先使用！

然而事實上不是如此，
以Windows電腦來說，某些版本的驅動程式，預設並不會以5G為優先考量，
Windows電腦會以2.4G去聯結AP。

而在2.4G訊號涵蓋範圍是5G的一倍的情況下，
或許user以為在行進時，訊號已經很弱了，應該切換到另一顆AP去。



但實際上以2.4G的涵蓋範圍來看，user還在足夠強度的訊號範圍內，並不會切換到另一顆AP去。



User還是必需要關掉無線，然後再重新開啟無線，才能連到訊號較強的另一個AP。
造成user認為Wifi Roaming只是噱頭，沒有作用！


因此順子建議，在無線環境中佈建足夠多的AP的情況下，
務必確認Windows電腦的Wifi設定是以5G為優先選擇。(iOS 11以後，預設已經是以5G為優先了，但Android的部分順子就查不到了...)



或是乾脆獨立5G的無線網路，不要將2.4G與5G混用，造成使用者誤用到2.4G的困擾。
如果覺得在切換上還是不夠主動，甚至可以考慮調高漫遊的積極度。




順子在強制使用5G的情況下，實際進行Sophos XG的Wifi Roaming測試，
測試結果發現，以ping來觀察的話，在AP切換時，ping最多只會掉一個，且Line的通話並不會斷。

Sophos XG的Wifi Roaming，其實也沒有那麼不堪啊∼



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2019-08-16, 11:14 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370
shunze 離線
《分享》SIP環境參數調整顯示主題 搜尋由 發表的其他文章 回報給版主 IP 位置 回此頁最上方

今天在討論區中看到一篇有關SIP的環境參數調整，
原來除了 system system_modules sip unload 外，還有以下幾個參數可以調校。

set advanced-firewall udp-timeout-stream 150

預設時間是60秒，放大到150秒，有助於減少VoIP環境下UDP timeout的機會。

set ips sip_preproc disable

透過以上指令，可以在IPS的封包中，停用對於SIP的預先載入模組，減少一些干擾，預設是enable。

set vpn conn-remove-tunnel-up disable

在Site to Site VPN環境中，不會因VPN tunnel-up，而flush SIP連線，預設是enable。
比較特別的是，這個指令無法以tab鍵自動帶出/顯示後續參數！


參考資料
VoIP calls may drop or encounter poor quality



♥順子老婆的網拍，請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
2019-07-22, 12:13 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
跳到:
顯示從 41 到 50 在所有的 2070 個結果中.  «123456789...»

Powered by: Burning Board 1.1.1 2001 WoltLab GbR