Re: weird packets.. anyone?

From: Greg White (gregw-freebsd-security@greg.cex.ca)
Date: 08/03/01 

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>

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

Relevant Pages

  • Re: slow access with China
    ... I know that the chinese goverment filters ... I can confirm that the Chinese do filter and analyze traffic, I've experienced this in the 2000's in travel there, where, when using standard ports for protocols like http and IM communication my services disconnected and slowed down to a crawl. ... Trace analysis of my own socket communication definitely showed that I was being transparently proxied and also filtered by making a connection through to a host in another country where I could see the "results" of the communication, which showed invalid values for TCP windowing and TTL values that proved a new socket connection was being made on behalf of my host's original request. ...
    (comp.security.firewalls)
  • Re: line drops when a telephone is connected. Please Why?
    ... > telephone into the line my connection is dropped. ... > without filters, taking sky off the line but nothing seems to change. ... > As soon as I plug a telephone back into the line (at any point on the ... extension wiring connected into the back of the faceplate? ...
    (uk.telecom.broadband)
  • Re: UDP connection over GPRS/3G fails when Wifi is ON
    ... a UDP server over the GPRS/3G network (I downloaded a free ... This works when the Wifi is OFF. ... there is an active WIFI connection to the web. ... The GPRS connection stops when there is active WiFi connection? ...
    (microsoft.public.pocketpc.developer)
  • VPNclient, protocol ESP, AH and firewall
    ... I've setup a connection to a remote side using Cisco VPNclient on ... in the case of IPsec for VPN it is 'udprelay', ... and UDP 4500 to the remote VPNserver (the later one I've figured out ... Initializing the VPN connection. ...
    (comp.os.linux.networking)
  • Re: bind() udp behavior 2.6.8.1
    ... any firewall must keep some sort of state table even if it is udp. ... numbered port is making a udp dns request, and thus be able to allow ... connection is already established. ...
    (Linux-Kernel)