Yet another reason to block RFC 1918 address ingress/egress

Wed Aug 18 04:36:01 PDT 2004

Noted the folowing in today's review of my home packet filter's logs.
I had seen similar ones as of a couple of weeks ago, but finally got
around to mentioning it:

Aug 17 09:48:34 janus /kernel: ipfw: 1210 Deny TCP 172.16.1.21:4138 63.193.123.122:25 in via dc0
Aug 17 09:48:37 janus /kernel: ipfw: 1210 Deny TCP 172.16.1.21:4138 63.193.123.122:25 in via dc0

We see here an attempt to access my SMTP server from a machine using the
IP address 172.16.1.21, coming from the Internet-facing NIC.

Aug 17 13:50:28 janus /kernel: ipfw: 3020 Deny UDP 63.193.123.122:2727 192.168.0.5:53 out via dc0
Aug 17 13:50:28 janus last message repeated 2 times
Aug 17 13:50:48 janus /kernel: ipfw: 3020 Deny UDP 63.193.123.122:2727 192.168.0.1:53 out via dc0
Aug 17 13:50:48 janus last message repeated 2 times
Aug 17 13:50:52 janus /kernel: ipfw: 3020 Deny UDP 63.193.123.122:2727 192.168.0.2:53 out via dc0
Aug 17 13:50:52 janus last message repeated 2 times

And here's an attempt to use 192.168.0.1 as a nameserver to resolve
something (on the part of some machine on my net) -- likely trying
to resolve the domain part of an envelope-sender.

Even if either of the above is the result of an honest configuration
error, it's the sort of thing that really needs to be corrected, not
worked around.  And I suspect that at least the first (and likely both)
are the result of spammers.

Yes, I know about "not ascribing to malice what can adequately be
explained by stupidity."  I have my limits.  :-}

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Evidence of curmudgeonliness:  becoming irritated with the usage of the
word "speed" in contexts referring to quantification of network
performance, as opposed to "bandwidth" or "latency."