This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection
- Previous message (by thread): [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection
- Next message (by thread): [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Philip Homburg
philip.homburg at ripe.net
Wed May 21 17:20:01 CEST 2014
On 2014/05/21 17:13 , john wrote: > On 21/05/14 16:58, Philip Homburg wrote: >> I'm curious what this firewall is trying to do. If it allows >> unrestricted outbound connectivity over ssh, but not ssh on port 443. >> What is that rule trying to protect? > Its trying to prevent exactly this. A lot of exploits/malware dial home > using the same assumption you do. i.e. 443 will be open. however most > of the don't use ssl. With this in mind many IDS will drop anything > talking on 443 that isn't ssl/tls. They also do the same protocol > analysis on other ports so trying port 80 in this case is also likely to > be drooped, as the traffic is not http. But in those setups, port 22 is usually closed. And if you really want to prevent malware from dialing home, you would have to close all other ports as well. Typically, I find port 22 closed and then port 443 wide open. So the availability of port 22 is what surprises me. Philip
- Previous message (by thread): [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection
- Next message (by thread): [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]