Date: Thu, 2 Aug 2001 16:03:30 -0700 From: Greg White <gregw-freebsd-security@greg.cex.ca> To: FreeBSD Security <freebsd-security@FreeBSD.org> Subject: Re: weird packets.. anyone? Message-ID: <20010802160330.R19198@greg.cex.ca> In-Reply-To: <20010802164110.A64693@tmd.df.ru>; from tmd@tmd.df.ru on Thu, Aug 02, 2001 at 04:41:10PM -0400 References: <20010802164110.A64693@tmd.df.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 02, 2001 at 04:41:10PM -0400, Vlad wrote: > I've got this today in my logs: > > Aug 2 12:51:32 tmd ipmon[35772]: 12:51:31.270526 ed0 @0:5 b 0.0.0.0,68 -> 255.255.255.255,67 PR udp len 20 328 IN > Aug 2 12:57:54 tmd ipmon[35772]: 12:52:34.606148 3x ed0 @0:5 b 169.254.179.233,137 -> 169.254.255.255,137 PR udp len > 20 96 Looks like totaly normal broadcasty traffic for a cable modem setup (and based on your supplied addresses, that's what you have, right?). The first looks like a normal host-broadcast request for DHCP/BOOTP -- you'll see alot of this if your local cable segment is busy. See below for how I handle this on my cable connection. The second appears to be a broadcast NetBIOS-NS request from a DHCP client who did not recieve an address. 169.254.0.0/16 is reserved for clients in that state. It has an RFC associated with it, ISTR, but can't recall which one at this point. > > and connection to 138. You mean your machine accepted a connection on NetBIOS-dgm? That's odd. :) Or do you mean attempts? I simply drop all tcp and udp >134 <140 and ignore them. Windows machines generate this crap all day long. > > each of connection was followed by the following entries in the log: > > Aug 2 13:33:39 tmd /kernel: Connection attempt to UDP 24.43.202.10:1931 from 24.2.9.35:53 > Aug 2 13:33:39 tmd /kernel: Connection attempt to UDP 24.43.202.10:1934 from 24.2.9.33:53 > Aug 2 13:33:39 tmd /kernel: Connection attempt to UDP 24.43.202.10:1940 from 24.2.9.33:53 > Aug 2 13:33:52 tmd /kernel: Connection attempt to UDP 24.43.202.10:1939 from 24.2.9.35:53 > Aug 2 13:33:52 tmd /kernel: Connection attempt to UDP 24.43.202.10:1942 from 24.2.9.33:53 > Aug 2 13:33:52 tmd /kernel: Connection attempt to UDP 24.43.202.10:1941 from 24.2.9.35:53 > Aug 2 13:34:06 tmd /kernel: Connection attempt to UDP 24.43.202.10:1943 from 24.2.9.35:53 > Aug 2 13:34:09 tmd /kernel: Connection attempt to UDP 24.43.202.10:1944 from 24.2.9.33:53 > Aug 2 13:34:39 tmd /kernel: Connection attempt to UDP 24.43.202.10:1945 from 24.2.9.35:53 > Aug 2 13:34:52 tmd /kernel: Connection attempt to UDP 24.43.202.10:1950 from 24.2.9.33:53 > Aug 2 13:35:00 tmd /kernel: Connection attempt to UDP 24.43.202.10:1952 from 24.2.9.33:53 > Aug 2 13:35:00 tmd /kernel: Connection attempt to UDP 24.43.202.10:1951 from 24.2.9.35:53 > Aug 2 13:35:09 tmd /kernel: Connection attempt to UDP 24.43.202.10:1954 from 24.2.9.33:53 > Aug 2 13:35:39 tmd /kernel: Connection attempt to UDP 24.43.202.10:1953 from 24.2.9.35:53 > Aug 2 13:35:39 tmd /kernel: Connection attempt to UDP 24.43.202.10:1955 from 24.2.9.35:53 > Aug 2 13:35:39 tmd /kernel: Connection attempt to UDP 24.43.202.10:1956 from 24.2.9.33:53 > > and then repeated.. > > 24.32.202.10 - my ip > 24.2.9.33 - primary DNSof my ISP If you meant 24.2.9.35 right above this, then that does look just like normal DNS traffic to me -- either keep state on all your outbound DNS requests, or allow this server to talk to you from UDP 53 - UDP ephemeral (>1024). If you meant .33, then it seems likely that someone is attempting to spoof UDP traffic through your packet filters. My recommendations: 1. Drop all traffic not destined to your IP (or subnet, if you have one) as soon as possible. If you need DHCP, set specific rules to allow only your provider's DHCP in -- if necessary, drop filters and sniff a session, or log everything for a little bit to find out which. You'll need to rewrite your filter rules if your provider changes DHCP servers, but IMHO it's more secure that way. Then, make a rule that drops everything not headed directly for you into the bitbucket. 2. Ignore _any and all_ NetBIOS traffic. See above for ports, etc. 3. Use stateful filtering whenever possible. If you're feeling adventurous, and have time on your hands, control the traffic as it leaves your network, rather than trying to filter the replies, and just keep state on everything you allow. If you're _sure_ that any traffic you generate must be legit, just keep state on outbound UDP and TCP SYNs. 4. Now you should be able to log everything else, with some exceptions. Many cable providers try to stuff routing information down your throat, and you may have some twit constantly poking a service you don't run, like RPC/Portmap. Deny this kind of crap and don't log it. 5. Log everything else. Hope this helps, GW -- Greg White To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010802160330.R19198>