I'm very familiar with different applications of scanning tools (. . . and you can use -mtu to specify the size of the fragments in nmap . . .) but every piece of information I read about scanning and enumeration seems to always conclude with " . . . but this is only effective against old or poorly configured firewalls . . ."


Where can I get information about some of the more advanced scanning techniques that would be effective against modern, well-configured firewalls?


. . . or at least some information on the order of: "regardless of the firewall's configuration or age, X, Y, Z will at the very least give you information about S, R, T, which can be used to discern L, M, and N"

I'm looking for a resource primarily. Books cost $$ and I understand that, so I'm not anti-books.

  • 1
    @ruief unless it's unpatchable Feb 10, 2013 at 17:07
  • No, I certainly don't. Firewalls always must traffic information, and in some cases that involves leaking information about the information they are trafficking in an unavoidable way. I'm not looking for a magic script that punches holes in firewalls. I'm looking for scanning methodologies that take advantage of the foundational fact that a firewall is bidirectional.
    – gal
    Feb 10, 2013 at 17:11
  • 1
    Search for Firewall Fingerprinting
    – Ali Ahmad
    Feb 10, 2013 at 17:12
  • @AliAhmad TY =)
    – gal
    Feb 10, 2013 at 17:17

1 Answer 1


There are some academic papers on the subject, but they don't tend to address evasion.

The reason you keep seeing the caveat "old and poorly configured" is because it holds pretty true - there is a limited set of 'valid' connections and connection types, and it's entirely possible on modern firewalls, properly configured, to enumerate them all and simply ignore all other types (even if that's not what the user did explicitly).

Cisco IOS, to take the most famous example, is decades old, and TCP/IP just hasn't changed all that much; so there's been an awful lot of time to harden it against unwanted traffic (especially since that's a firewall's core competency).

Additionally, devices are also fast enough now that even very complex rules don't cause much overhead in most installations and so some of the old "packet X takes 50x longer to process than packet Y" indicators just don't work because 50x slower is still faster than the clock on the wire.

  • Seems the link to the paper is down. I fixed your link to reflect the correct address. Feb 11, 2015 at 19:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .