Monitoring dark address space?

Mailman List Mirror (Read Only)
1

NANOG,

I was wondering how many of you are running some sort of detection tool on "dark address" space on your network? In an effort to curb malicious outbound non-spoofed traffic from "owned" client machines I think one of the easiest methods we have is to look for scans in what should be dead space. The source-address spoofed traffic is easy to drop, the "legal" traffic is a bit more complex and I'm looking for non-inline methods of curbing this traffic.

My questions are:

1) Are you doing this and if so, what tools are you using? Some sort of simple listening device with thresholds would probably do the trick if one machine monitored an entire /24 or some random /32's out of a /16.

2) What techniques seem to be better? Monitoring an entire /24 or picking a distributed selection of IPs from a /16? (using a /24 or /25 is much easier on the administrative end of things from where I sit...)

3) What sort of threshold metrics for considering something to be malicious have you found to be good? (ports/second, ip/second, etc)

4) Are there downsides to this (aside from false positives, which would hopefully be rare in truly dark address space).

Off-list replies are fine and I'll summarize after a few days.

thanks,
davidu

2

davidu@everydns.net (David A.Ulevitch) writes:

I was wondering how many of you are running some sort of detection tool
on "dark address" space on your network?

ooooh, ooooh, me!

In an effort to curb malicious outbound non-spoofed traffic from "owned"
client machines I think one of the easiest methods we have is to look for
scans in what should be dead space.

you're right.

The source-address spoofed traffic is easy to drop, the "legal" traffic
is a bit more complex and I'm looking for non-inline methods of curbing
this traffic.

since this space has no dns records pointing into it, the only traffic it
will see is from errors/typo's, and network scanners. some scanners use
pseudorandom selection, some are serial, but none are nonmalicious.

My questions are:

1) Are you doing this and if so, what tools are you using? Some sort
of simple listening device with thresholds would probably do the trick
if one machine monitored an entire /24 or some random /32's out of a
/16.

in freebsd ipfw:

  pipe 1 config mask src-ip 0xffffffff buckets 32768 bw 10Mbit/sec
  pipe 1 ip from any to x.y..0.0/16 in
  fwd 127.0.0.2 ip from any to x.y.0.0/16 in

"pipe 1" is just there for measurement purposes, and ddos prevention.
the address i fwd it to is an extra loopback alias defined in rc.conf:

  ifconfig_lo0_alias0="inet 127.0.0.2 netmask 255.255.255.255"

this box also runs zebra to inject this /16 into the local OSPF, which
elsewhere triggers some router of jabley's to inject it into BGP. there
are two listeners, both written locally, that are started in rc.local by
scripts that look like this:

  while :; do
        ( src/httpk/i386/httpk -b reject-all.vix.com -t 3 -h 127.0.0.2 \
                -s http -f endoftheline.html -l |
          tee tee | src/httpk/pgit.pl ) > log 2> err
        sleep 45
  done

and this:

  while :; do
        ( src/smtpk/smtpk -l 127.0.0.2 |
          tee tee |
          src/smtpk/pgit.pl ) > log 2> err
        sleep 2
  done

the "tee" file is sort of unreadable. for httpk it looks like this:

  src [209.148.235.157].3083; dst [149.20.195.105].80; Sat Apr 17 03:55:07 2004
  GET / HTTP/1.1
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
  User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
  Host: 149.20.195.105
  Connection: Keep-Alive

whereas for smtpk it looks like this:

  Message-ID: <050048052046049053050046049057049046053049@5914ASDE.vicp.net>

3

since this space has no dns records pointing into it, the only

> traffic it will see is from errors/typo's, and network
> scanners.

And blowback from other people forging your addresses as sources.

(We've had quite a few goober-with-firewall reports of that type -
especially from a certain manufacturer of networking equipment who
shall remain nameless, even though they ought to know better.)

>> 3) What sort of threshold metrics for considering something to be
>> malicious have you found to be good? (ports/second, ip/second, etc)

> the false positives are less than one in ten million.
> "blackhole 'em all."

If you're actually going so far as to accept the connections, yes. If
you're just counting packets, then a little more caution is possibly
indicated.

> it's a l-l-lotta d-d-data, m-m-man. otoh, between this and
> postprocessing my maillogs looking for wormspoor, i have a
> personal blackhole list with almost a million hosts on it now,
> and about 20% of the ones who probe my smtpk (which always
> accepts all mail you send it) later try to spam my main mail
> server (which is in a different netblock).

Oooooh. _Very_ interesting.

4

NANOG,

I was wondering how many of you are running some sort of detection tool on "dark address" space on your network? In an effort to curb malicious outbound non-spoofed traffic from "owned" client machines I think one of the easiest methods we have is to look for scans in what should be dead space. The source-address spoofed traffic is easy to drop, the "legal" traffic is a bit more complex and I'm looking for non-inline methods of curbing this traffic.

My questions are:

1) Are you doing this and if so, what tools are you using? Some sort of simple listening device with thresholds would probably do the trick if one machine monitored an entire /24 or some random /32's out of a /16.

We run one on a /16. You can find details here:
http://noc.ilan.net.il/research/riverhead/
We also know of the SWITCH dark address monitor at:
http://www.switch.ch/security/services/IBN/
I'd be interested in knowing of any others.

The stats haven't been updated in a while but that will change over the next few months.

-Hank

5

> since this space has no dns records pointing into it, the only
> traffic it will see is from errors/typo's, and network scanners.

And blowback from other people forging your addresses as sources.

Actually, not. Very few modern MTA's correctly implement "@[dot.ted.qu.ad]"
parsing, and other than zone file typo's, no MX points into this address
space. So the blowback comes to my real MX's, not to this "dark space".

(We've had quite a few goober-with-firewall reports of that type -
especially from a certain manufacturer of networking equipment who
shall remain nameless, even though they ought to know better.)

Apropos of that, I'm appending my current list of antivirus spoor in postfix
format. Antivirus vendors know that viruses usually have forged sources, but
they get to spam you for free using their customers' own e-mail servers, all
in the guise of telling you that their product filtered something bad and by
the way here's the URL if you want more information about their product. As
it turns out, if you blackhole the servers who send you this crap, the customer
who installed the antivirus software calls YOU. If on the other hand you
reject it at SMTP level you cause a "double bounce" to the customer's own
"postmaster" account, and the customer calls THEM (the antivirus sw-vendor.)

> false positives are less than one in ten million. "blackhole 'em all."

If you're actually going so far as to accept the connections, yes. If
you're just counting packets, then a little more caution is possibly
indicated.

Packet counting _never_ helps you. Simply put, probitive malware does not
have to send enough packets that it'll show up on quantitative IDS "radar".
And for that matter, a number of non-malware systems (like some IRC nets I
know of) will do a virus probe with no ill intent. Unless you're going to
accept the connection (and perform a transaction successfully, such as
pretending to accept some mail or sending them some web data), you cannot
learn anything about the vileness of the initiator's intentions, or even
the level of technical sophistication of the initiating host's owner/op.)