2017-11-11 327 views
0

Gooday to All,我寫下了一個非常敏感的Web應用程序,其功能就像文件瀏覽器,而不是使用sftp/ftp或ssh。它純粹使用http/https。我使用request.remote_addr來確定客戶端的IP地址。如果IP不在列表中,則拒絕。有沒有關於python-flask的request.remote_addr的缺陷?或者它是可靠的(沒有反向代理)

good_ips = ['127.0.0.1','192.168.1.10','192.168.1.1'] 
if request.remote_addr in good_ips: 
    pass 
else: 
    sys.exit() 

它工作正常,但我只想問,這是多麼可靠和安全:)。

如果ip不在列表中,這將是結果。其他明智的網站將運行良好:D。

謝謝你,美好的一天! Result if ip is not in the list

回答

0

不,這不足以在您使用它時構建「敏感」服務。

查看https://en.wikipedia.org/wiki/IP_address_spoofing只是一個可能出錯的開始。

您應該使用身份驗證,例如使用公鑰(SSH支持)或密碼。 Kerberos也是一種可能性。

+0

哦。好的,謝謝你,先生。它不是主要的過濾器。只是一個避開陌生人的層;)但事情是,它不在私人IP上。我計劃做的是把我的公共ip放在那裏。作爲另一層。 (在這些主題上發現了一些問題 https://security.stackexchange.com/questions/105675/ip-spoofing-how-secure-is-to-control-access-by-user-s-public-ip-address) 所以,簡而言之,我不能依靠通過公共ip進行控制訪問。但不管怎麼說,只是爲了另一層保護而添加它;) – screaminghard

0

源IP過濾是否適合您的措施取決於您的確切場景和威脅模型。 @JohnZwinck是正確的,因爲它本身通常是不夠的,但對於某些應用程序來說,它可以。

雖然在單獨的IP數據包中僞造源IP很容易,但是http通過tcp,並且現代實現的tcp受到地址欺騙保護。儘管如此,較舊的TCP實現(在較早的操作系統中)仍然很脆弱。所以如果你的服務器有一個最新的操作系統,那麼欺騙一個源IP並不是一件簡單的事情。使用允許列表中的地址危害客戶端可能更容易。

可能出錯的另一件事與網絡地址轉換(NAT)有關。假設您將應用程序中的訪問限制爲內部IP地址(192.168.0.0/24)。一切正常,但是您的安全部門決定需要爲所有Web應用程序設置反向代理。代理已部署,並且所有工作都正常。然而,現在你的應用程序接收到來自代理服務器的所有請求wuth一個內部地址,所以應用程序中的限制沒有多大意義。客戶端也可能發生類似事件,在某些情況下,客戶端可能會在NAT後面,這意味着它們將具有相同的明顯的客戶端IP地址 - 這可能是好的或壞的。

最好的做法當然是要有正確的驗證(通過密碼,客戶證書,還是多因素等等,但是你固定希望它是),與IP限制是額外的層提供更多安全。

+0

感謝您的信息和見解先生:)是的。我決定在運行時實施登錄系統。 :)我也發現了一些關於代理的答案和解決方案(關於如何使用代理獲得客戶端的IP):)謝謝先生 – screaminghard

相關問題