Reliable Alive Test through Firewall


#1

I am scanning my services which are all behind a firewall using an external remote sensor, but I’m having problems with the first stage where it identifies which addresses to scan.

  • I can’t assume alive because there are too many and it would take more than a month to scan
  • I could allow Pings through just for the scanner but not all machines respond to ping
  • I could use a TCP-SYN but that doesn’t allow me to ICMP Ping as well
  • The alternatives which include ICMP ping all use TCP-ACK which is useless against a stateful firewall because it only tests the firewall’s reaction, not the rulebase or the server. It is completely up to the firewall configuration whether it drops these silently or sends a RST so either way it doesn’t tell you whether there is a host behind it.

There doesn’t seem to be an option for ICMP Ping and TCP-SYN which to me seems the obvious test. I could clone and modify the scan, then use “scan config default” but then I won’t get updates to the scan config.

Does anyone have any suggestions for a reasonably reliable way to test hosts are alive?


#2

It´s the nested interest of a firewall to block communication, so scanning trough a Firewall is never a good idea.

If you have a stateful Firewall, you might fill up the session table by sending a lot of SYN-Requests there and opening a state with every packet. So be careful. ICMP is normally blocked as well.

The best practice is to place a sensor behind the Firewall and scan from inside (Only port 22 SSH trough the Firewall). Otherwise you need to accept the timeouts and delays and Scan by “Consider Alive” trough the Firewall. I would reduce the scan timing to avoid a rapid fill up of the session table. As you already noticed this is not very performant, but there IS_NO_OTHER solution for that scenario.


#3

Thanks Lukas, in our case we specifically bought a slave gsm25 to do external scanning so it’s interesting to hear you don’t support that approach - something I need to discuss with our reselller.

I will take the “low and slow” approach and just use ICMP accepting that not all servers will respond (I’ll hve to punch an ICMP hole in the firewall to allow it in from the GSM). Consider Alive was just too slow, the tasks took far too long to be useful.

Thanks for the advice


#4

To be clear, it is useful to check what services and vulnerabilities are accessible from outside, like just scanning port 443 for remote accessible vulnerabilities, but this is not a replacement for a “internal” DMZ sensor behind the firewall to get the full score of your landscape.

This is a technical limitation of TCP/UDP there is no way to deal with the timeouts if you scan trough a firewall esp. if you don´t control this firewall.


#5

be clear, it is useful to check what services and vulnerabilities are accessible from outside, like just scanning port 443 for remote accessible vulnerabilities, but this is not a replacement for a “internal” DMZ sensor behind the firewall to get the full score of your landscape.

Oh OK that’s exactly what I am doing.

This is a technical limitation of TCP/UDP there is no way to deal with the timeouts if you scan trough a firewall esp. if you don´t control this firewall.

I do control the firewall, that’s how I can allow ICMP through, but without some really specific settings just for the GSM scans, even if I could do SYN and ICMP, the SYN test is not reliable as the firewall may proxy these and the ACK test is no good as the firewall always throws them away so I am left with ICMP or Consider Alive.

added after last post
Well, your reply certainly was confusing, It seems to have no relation to the question asked, makes irrational statements about technical issues and diagnoses firewalls you have no knowledge of. Then you locked the post. That’s a pretty shoddy way to treat paying customers.


#6

Sorry this is very confusing, you can just allow a probing from your sensor IP, that´s it. Not global and fall back to ICMP alive test. Other ICMPs must be allowed anyway or your internet connection is total broken :wink:

Closing the topic here …


closed #7