OpenBSD Journal

Distributed port scanning using OpenBSD's packet filter

Contributed by jose on from the interesting-tricks dept.

ste writes: "Distributed port scanning using OpenBSD's packet filter

By using openBSD's packet filter pf one can utilize the NAT address pools added into OpenBSD 3.3 to aid in distributed port scanning.

http://www.networkpenetration.com/pfdistnatscan.html "

Now that's an interesting use of PF, and a quick way to learn the idea of NAT pools in PF.

(Comments are closed)


Comments
  1. By Matt () on

    I think using that term was a little misleading, or at least was not used in the context that I am used to seeing it in.

    When I read distributed port scanning, I thought it was a method to do something like
    nmap $someaddressrange
    and have those queries broken up amongst several computers who share the workload, each scan a section of $someaddressrange, and then comine their results, thus reducing the amount of work any one machine had to do, and getting the results faster.

    This seems like more of an obfuscation technique to mess with IDSs. You could potentially set up a very large address pool, scan a remote host, and make that host think it is being port scanned by many different hosts at once. (right?)

    Regardless of my interpretation, it's still pretty interesting. Food for thought and all that.

    Comments
    1. By Matt Burke () matt@NOSPAMbotchitt.com on mailto:matt@NOSPAMbotchitt.com

      The usual definition of distributed portscans means using 1000's of hacked boxes around the internet to each hit one single port on a victim machine, like a DDoS, except used to probe not attack.

      This completely obliterates software such as portsentry.

      The technique described in the article requires hogging a large IP range to be of any effective use.

      Comments
      1. By Jeroen () on

        "The technique described in the article requires hogging a large IP range to be of any effective use."

        I can think of a lot other usefull uses of spare IPv4 addresses and therefore hope that large IPv4 ranges are not used for this matter only nor i hope people want large IPv4 ranges only for this matter.

        PortSentry is not *that* usefull anyways, especially not on IPv4 (dunno if it's ported to IPv6). If an IPv4 address is spoofed during sending it will block that spoofed IPv4 address as if it was configured in the context as you said. Oops.

    2. By Clint () spam@rules.com on mailto:spam@rules.com

      I don't really get the point of this. As it points out, the header will be rewritten as the single eternal IP of the gateway box anyway, so from a box in the internet's perspective, its always the same source IP. So what is the value of this idea?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]