[lug] eth0: tx interrupt but no status

D. Stimits stimits at idcomm.com
Mon Dec 10 22:10:38 MST 2001 

Paul Bille wrote:
> 
> Dec 10 18:12:00 liz kernel: eth0: tx interrupt but no status
> Dec 10 18:16:14 liz last message repeated 4 times
> Dec 10 18:18:13 liz kernel: eth0: tx interrupt but no status
> Dec 10 18:19:29 liz last message repeated 5 times

Don't know what to say about this.

> 
> Anyone familiar with a hacker named Garry Williamson out of Australia?

Never heard of him.

> 
> Actually, I don't imagine the hacker is Garry. Maybe Garry's system has been
> hacked. In any case, I got a very strange e-mail from Garry's system. and
> someone has been hammering on my system all day long.
> 
> This is the e-mail message I received from Garry at 6:18pm Dec 10:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> I'm wondering why the below information is attached to the three hack
> attempts that have been trying to finger my puter,.... just wondering that
> is ........cause if I can find this then maybe I can get into you, perhaps
> you never thought of that ................aye ?
> Login: paul Name: Paul Bille
> Directory: /home/paul Shell: /bin/csh
> On since Mon Dec 10 11:03 (MST) on :0 (messages off)
> Mail last read Mon Dec 10 18:27 2001 (MST)
> Plan: Paul Bille
> <http://bille.cudenver.edu/author>
> Regards,
> Garry Williamson
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~

Finger is basic info. I know it has been used before to gather info, I
don't know of any recent hacks to use it directly against a machine,
though there certainly could be. What it does mean is that you have the
service running, I'd block SYN packets to the finger port, maybe all udp
to finger port. That anyone would think showing you this info was in any
way a threat makes me roll my eyes back and laugh, muttering "how
stupid".

> It could be just some kid who's fascinated because "finger" actually works.
> On the other hand it could be a warning.

Anyone that has been around UNIX for any length of time, certainly a
real cracker, would know about this and not think it particularly
interesting, even if the info might have some use.

> 
> I don't think my system has been compromised yet but . . . Here are a few
> lines from my syslog that concern me:
> 
> Dec 9 19:52:36 liz rpc.mountd: export request from 192.207.173.213

rpc is a big threat. Unless you offer your NFS mount to random addresses
on the Internet, it should be summarily firewalled. At least against any
IP not expected. If it is a dynamic IP expected, you'd maybe allow only
the /24.

> 
> I don't know anyone on 192.207.173.xxx and I certainly didn't export my disk
> to them.
> Name: j30.engr.subr.edu
> Address: 192.207.173.213
> 
> Dec 10 15:44:52 liz sshd[1980]: log: Connection from 211.120.48.7 port 3409
> Dec 10 15:44:57 liz sshd[1980]: log: Could not reverse map address
> 211.120.48.7.

Looks like you are squashing traffic without reverse lookup. Or at least
logging it. That's good.

> Dec 10 15:44:57 liz sshd[1980]: fatal: Did not receive ident string.

Looks like you require identd run (auth). Which is really good, because
it denies spoofing if a connection is to be maintained. Still, some of
the ssh packages out there that are only moderately old have some sort
of weakness against real crackers.

> What is the significance of port 3409? It's not one of the "well known
> ports". I don't think I'm providing a service on 3409.
> I can trace 211.120.48.7 back to shinkawa.jp but I can't get anything with
> nslookup.

Haven't heard of anything on 3409. Run this to see what is listening
there, if anything:
fuser -v -u -n tcp "3409" -n udp "3409"

Just because you logged a request to reach the port doesn't mean
anything is there to listen...xinetd or inetd could be reporting the
attempt regardless of whether something is there.

> 
> All day long I've been getting:
> Dec 10 19:20:44 liz kernel: eth0: tx interrupt but no status
> Dec 10 17:05:58 liz kernel: eth0: tx interrupt but no status
> Dec 10 17:09:58 liz kernel: eth0: tx interrupt but no status
> Dec 10 17:10:00 liz CROND[5584]: (root) CMD ( /sbin/rmmod -as)
> Dec 10 17:10:15 liz kernel: eth0: tx interrupt but no status
> Dec 10 17:12:25 liz kernel: eth0: tx interrupt but no status
> Dec 10 17:20:00 liz CROND[7074]: (root) CMD ( /sbin/rmmod -as)
> Dec 10 17:30:00 liz CROND[7523]: (root) CMD ( /sbin/rmmod -as)
> Dec 10 17:33:24 liz kernel: 202.101.5.90 sent an invalid ICMP error to a
> broadcast.
> Dec 10 17:33:27 liz kernel: 202.101.5.90 sent an invalid ICMP error to a
> broadcast.
> Dec 10 17:37:05 liz kernel: eth0: tx interrupt but no status
> Dec 10 17:53:26 liz kernel: eth0: tx interrupt but no status
> Dec 10 17:54:01 liz kernel: eth0: tx interrupt but no status
> Dec 10 17:54:02 liz fingerd[9511]: rejected @ebille.cudenver.edu
> Dec 10 17:54:12 liz fingerd[9579]: rejected @ebille.cudenver.edu
> Dec 10 17:54:15 liz fingerd[9604]: rejected @ebille.cudenver.edu

I have to wonder if this is spoofed or not. But I get a number of hits
from .edu's, I think some of the more savvy, as well as the more naive
and less experienced, crackers originate at universities, where they can
avoid using their own IP. The finger line itself I think is harmless. I
have to wonder what the tx interrupt thing means.


> Dec 10 18:12:00 liz kernel: eth0: tx interrupt but no status
> Dec 10 18:16:14 liz last message repeated 4 times
> Dec 10 18:18:13 liz kernel: eth0: tx interrupt but no status
> Dec 10 18:19:29 liz last message repeated 5 times
> 
> It appears they've been hammering on the system but as far as I can tell
> they haven't compromised the system yet.  I don't want to take the system
> off line but I am concerned. Is anyone else experiencing this kind of
> activity? Is it anything to be concerned about?

I would be concerned about anything related to NFS and rpc, but not
finger. I would probably use:
  whois cudenver.edu

And forward log excerpts and such to find out if the abuse@ or other can
figure it out. The whois also lists a local contact:
   Domain Name: CUDENVER.EDU

   Administrative Contact, Technical Contact, Billing Contact:
      Hagan, Randy  (RH286)  randy at CARBON.CUDENVER.EDU
      University of Colorado, Denver
      Computing Services, Campus Box 169
      1200 Larimer Street
      Denver, CO 80204
      (303) 556-2312

Funny thing is that after I did a traceroute to the address you found in
your logs, I got a firewall deny to my own port 0. It was from
64.86.83.122 (assuming non-spoof), it is
"if-10-0.core1.Washington.Teleglobe.net". Mostly I don't see default
route or broadcast type port attempts.

But when someone tries something more than a port scan, such as what you
are seeing, I track them down and report them to all technical contacts
I can find. If I traceroute and it drops at some point, I'll find out
the technical contact for the last point, and ask them.

D. Stimits, stimits at idcomm.com

> 
> Thanks,
> Paul
> http://bille.cudenver.edu/author/
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

More information about the LUG mailing list