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

Sat Jan 12 00:02:29 PST 2002

> 
> 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.

Interesting you should mention that;  a long while back the Linux Gazette
Answer Gang had a thread about answering the telnet port with an ascii
art banner "GO AWAY."  It was rather cute :) (If it were *me* I would have
used "TRY SSH." but it wasn't, and the thread was mostly answered before I
got to it.)  What they were actually asking for help about, was making sure 
the whole banner was sent, without turning the beastie into something that 
might have to make decisions and lead to security holes too.  I seem to 
recall a brief sleep interval was considered sufficient.  And if your 
firewall logs completed connections as the handshake settles in, that
should keep it from having to write anything.

> 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

If the ownership data is wrong that high up, it might have had a hole
for quite a while, but who would be the recipient of the bad news?