Date: Thu, 22 Feb 2001 09:28:55 -0500 From: Bob Johnson <bob@eng.ufl.edu> To: michael@fastmail.ca Cc: security@freebsd.org Subject: Re: Odd firewall messages Message-ID: <3A952227.57E6D4D4@eng.ufl.edu>
next in thread | raw e-mail | index | archive | help
> > > Date: Wed, 21 Feb 2001 21:31:39 -0500 (EST) > From: "Michael Richards" <michael@fastmail.ca> > Subject: Odd firewall messages > > - --------------Boundary-00=_RC050TY66ERNTT4D7TH0 > Content-Type: Text/Plain > Content-Transfer-Encoding: 7bit > > Aside from my bind problems, I finally got a firewall up and running > for our servers. The ipfilter rules catching the odd packets are: > # Nasty Packets: > # Block any packets which are too short to be real. > block in log quick all with short > # Block any packets with source routing set > block in log quick all with opt lsrr > block in log quick all with opt ssrr > # block any traffic claiming to be from an RFC reserved IP space > block in log quick on xl1 from 192.168.0.0/16 to any > block in log quick on xl1 from 172.16.0.0/12 to any > block in log quick on xl1 from 10.0.0.0/8 to any > # block localhost type IPs > block in log quick on xl1 from 127.0.0.0/8 to any > # block anything claiming to be a '0.x.x.x' > block in log quick on xl1 from 0.0.0.0/8 to any > # block IANA IPs reserved for use in auto-configuration > block in log quick on xl1 from 169.254.0.0/16 to any > # block IPs reserved for documentation authors > block in log quick on xl1 from 192.0.2.0/24 to any > # reserved SUN IPs for private cluster interlocks > block in log quick on xl1 from 204.152.64.0/23 to any > # multicast traffic > block in log quick on xl1 from 224.0.0.0/3 to any > You might want to block incoming packets that claim to be from your network if you don't already do so. It is a courtesy to others to also block outgoing packets that do not claim to be from your network. That helps suppress some forms of DoS attacks that might be relayed through you. > Now I seem to be getting a number of weird packets presumably probing > my machine for various open ports: > > 21/02/2001 04:51:05.250782 2x xl1 @0:6 b 10.0.0.1,137 -> x.x.x.x,137 > PR udp len 20 19968 IN > 21/02/2001 04:51:05.357334 xl1 @0:4 b 192.168.0.1,137 -> x.x.x.x,137 > PR udp len 20 19968 IN > 21/02/2001 05:08:04.033088 xl1 @0:4 b 192.168.1.20,137 -> x.x.x.x,137 > PR udp len 20 19968 IN > 21/02/2001 05:08:05.529631 xl1 @0:4 b 192.168.1.20,137 -> x.x.x.x,137 > PR udp len 20 19968 IN > 21/02/2001 05:08:07.033451 xl1 @0:4 b 192.168.1.20,137 -> x.x.x.x,137 > PR udp len 20 19968 IN > 21/02/2001 05:30:15.651130 xl1 @0:1 b 205.188.246.17,46666 -> > x.x.x.x,25 PR tcp len 20 7168 - IN > 21/02/2001 06:05:22.220902 xl1 @0:6 b 10.23.32.72,39666 -> x.x.x.x,25 > PR tcp len 20 10240 -A IN > > I haven't figured out what the last 2 log entries are or do only > because I haven't read into the docs far enough yet. The hard part about dealing with port 137 probes is that many Windows systems generate them as part of their normal operation, so you often have to see a definite scanning pattern to be sure they are not legitimate. There are a few trojan horse programs out there that systematically search for writable network shares on Windows systems: they start with systematic probes for port 137. Of course, seeing them come from a private IP number makes them interesting... Port 25 is incoming mail. Depending on your configuration, either someone is legitimately trying to deliver mail to you, or they are probing for mail servers to exploit. Port 80 (which by the miracle of modern technology I know you are going to mention in a later message) is HTTP, i.e. the default web server port. > > The thing I find curious is the first set of packets. These are > coming from RFC reserved IP addresses. Why on earth would I probe you > using a return address of 10.0.0.1 because I probably won't ever get > a response. Before the firewall was plugged in (it had a bypass > during setup and testing) I presume that the response for these > packets were just fired back and filtered out somewhere. Since rule > #2 and #3 do not seem to be firing I assume they are not source > routed so as to have the return source pass through the attacking > machine. Without a clear idea of how you get to the Internet this is only a guess, but some of the larger ISPs use private IP numbers for their internal routers, nameservers, security scanners, etc. This could be a legitimate security scan from your provider. You might try turning off the firewall briefly and doing traceroute 10.0.0.1 to see if you can actually reach a real system with that address. Or you might ask your ISP. > > Anyone have any wisdom when it comes to decoding what I'm seeing here? > > thanks > - -Michael Only guesses. - Bob 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?3A952227.57E6D4D4>