[atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection

On 2014.05.21. 17:37, john wrote:
> On 21/05/14 17:20, Philip Homburg wrote:
>> 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.
> I agree i suspect if one has gone to this much trouble then high ports
> will also be closed and port 22 will be restricted to know hosts/subnets

Which brings us back to the original point: if 443 is closed / filtered, the
chances are that so is 22. (As it's almost always an explicit user action to
fiddle with these.)

We can spend resources researching how often this happens, what we can do
about it, implementing fallback mechanisms and workarounds, use different
ports or even protocols. But at the end of the day, we'd likely save only a
fraction of the struggling probes.

Robert