Date: Mon, 11 Sep 2000 06:53:36 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Emmanuel Gravel <egravel@earthlink.net> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Strange TTL Exceeded messages Message-ID: <Pine.BSF.3.96.1000911053145.10146D-100000@gaia.nimnet.asn.au> In-Reply-To: <200009101838.LAA01178@falcon.prod.itd.earthlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Sep 2000, Emmanuel Gravel wrote: > At 12:21 PM 9/10/00 -0500, Dan Debertin wrote: > >On Sun, 10 Sep 2000, Emmanuel Gravel wrote: > > > >> Knowing I shouldn't have much (any) traffic on my system I ran ethereal > >> overnight to see what my firewall could and couldn't catch. Apart from the > >> usual querries on ports 139 and 137, I saw something strange. I recieved > >> about 20 TTL Exceeded messages from a host I never sent any info to > >> (according to the ethereal log) just past 3 this morning. > > > >Somebody (possibly you) was using traceroute. It uses ICMP > >TTL-exceded-in-transit and destination-unreachable messages to do its work > >(I won't explain how traceroute works here, but read any good TCP/IP book > >for more info). One of the better references regarding traceroute and many other things you may encounter is http://www.robertgraham.com/pubs/firewall-seen.html > At 3 AM I was fast asleep :) According to the ethereal logs, there were no > transmissions at all originating from me. And since it's in the non-routable > addresses, it must mean someone was sending this to me with forged > origin info. Something strange though. I have these rules in the firewall: > > ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} > ${fwcmd} add deny all from any to 10.0.0.0/8 out via ${oif} > > and ipfw -a list gives > > 00600 0 0 deny ip from 10.0.0.0/8 to any via ep0 > 00700 18 1160 deny ip from any to 10.0.0.0/8 out xmit ep0 > > Keep in mind I did try pining the host, and tried a traceroute on it... Which explains why your ping and traceroute failed :) apart from the address being unrouteable - but which doesn't explain how you could have received those ICMP packets in the first place, given rule 600, unless: . They did appear against rule 600 and you've since cleared that? or . They came via another interface, perhaps somewhere on the inside, assuming you have an inside LAN also? Logging is the go either way. > Just a quick question about this, I know the first number is the ifpw > rule sequence #. I believe the second is number of packets. So the > third, would it be number of bytes? It would. > I did a timestamp on it, and it shows that rule 00700 was first logged last logged .. the stamps are updated per hit. > at 10 this morning. Also keep in mind that I restarted my rules a few > times... I know I shouldn't have, and checked them in more detail (to > see if the firewall actually dropped the packets). I'm not logging them, > so I'll start to now... Shouldn't get too much data though :) You may be surprised :) Using ipfw zero rule [..rule] saves reloading. > I know that icmp ttl exceeded messages are common with a traceroute, > however why would I get so many from the same host (in a normal situation, > considering I would have actually done a traceroute, which isn't the case)? Can't imagine. > Also, anyone know of anything running on port 27374? This, and any SubSeven V2. On the increase here lately, with fewer of the old 1243 .. No use chasing source addresses on these either; invariably spoofed, I think the address the trojan contacts if triggered is embedded anyway. > setup connection from the outside (usually on port 139 :) just got blocked > a few minutes ago... Just trying to understand what kind of weird traffic is > coming in on my system :) Mind you, if it's not something known, it may > just be BO or Netbus trying in on a different port too... Wasn't dumping > packets when I got it... Deny, and log for education, anything not specifically allowed; there are almost daily new ports being used by more scripts/trojans .. even so, after many months of (futile) UDP 137 scanning, we're seeing TCP 139 scans in waves just the last few days here, and so have specific rules to deny and log till limit some of this 'snow' first (UDP 111 137, TCP setup on 139, 1243, 12345, 27374, 111 among others) just because there are so many of them, which will otherwise quickly exceed logging limits for all nonspecific denied traffic that we do want to know about. FWIW, all of the TCP 139 (netbios-session) scans we're getting appear to have spoofed source addresses, having checked a few out. Which is a bit baffling, wondering what useful info could be gleaned without hoping to get responses back - unless these are perhaps part of a distributed DoS against the spoofed sources (ie, are they in fact the targets?) Cheers, Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1000911053145.10146D-100000>