What to do when mail to a netblock coordinator bounces....

[Wolfgang Rupprecht]

david at catwhisker.org (David Wolfskill) writes:
> Yesterday morning, as I was reviewing the mail from the preceding night,
> I noticed that someone tried (once) to contact an SSH server on my
> mother's (grandfathered static) DSL installation.  (It happens that there
> is an SSH server, but I block access to it from nearly all IP addresses;
> I don't see any point in increasing exposure.)

One thing to remember is that if the intrusion log comes from a
firewall logfile where the firewall blocked the first SYN packet then
you may not have a truthful IP address to work with.  Some of the
script-kiddie programs will allow a list of *source* IP's to be
specified.  Clearly they won't get a reply back for any probe that
doesn't have an IP which routes to them, but burying their real probe
in a flurry of forged-IP probes will create a real mess for the admins
that are trying to unravel the attack.  

Forged source-IP packets like this can also be used for pranks, ("Why
is www.cert.org trying to connect to tcp/23 ?"

To get stronger proof of the IP that the attacks are coming from, you
really want to establish a full-duplex communication with the
attacker.  While even then it is sometimes possible for them to
simulate a full-duplex connection, it is not very easy since they
would have to predict what you are going to send and pretend that they
got it.  If the attack is on a tcp port, the TCP-ISN-randomization
done in modern kernel is pretty darn hard to guess at correctly.

The simplest way to force a full-duplex communication for tcp ports is
to have inetd start a "hello world" type program that outputs a line
or two of information and then closes the TCP connection.  By the time
inetd spawns your program TCP has already gone through the 3-way
handshake (syn, syn-ack, ack).  Just to add frosting to the cake, the
program can also optionally log the IP and even rebuild the firewall
block list after adding this IP address.

If the attacker is at all clever then the attack is going to come from
a compromised machine (open socks proxy, remote-root bug, snooped
password etc).  Alerting the remote org's admin would be the friendly
thing to do.  If the IP that the attacks are coming from reverse maps
I'll send a message to abuse at their.domain .  I have just recently
started doing "jwhois ip-address" lookups.  The ARIN's whois now does
the correct CIDR-type lookup and will give you the nested info.  Of
course if that info is wrong, we are back to your real question, and
I'm not sure I'd do more than just block the IP and move on.

-wolfgang

-- 
       Wolfgang Rupprecht <wolfgang+gnus at dailyplanet.wsrcc.com>
		    http://www.wsrcc.com/wolfgang/
Coming soon: GPS mapping tools for Open Systems. http://www.gnomad-mapping.com/