Good day, all,
On Fri, 15 Dec 2000, Michele Jordan wrote:
> Well, actually, now that I really look at it, I bet 194.122.33.243 is
> your firewall, based on the lo in the message, showing this packet is
> being seen on the loopback address. Perhaps more of a
> misconfiguration on the firewall somehow than an attack.
(I agree...)
> Michele Jordan wrote:
>
> > I would read those messages to say that you are receiving packets
> > with an inside address (194.122.33.243) on the outside interface. So
> > they are being denied because the address is seen on the wrong
> > interface (bad-if). This is a standard attack, spoofing the inside
> > address to perhaps get past filters.
(I don't agree - read on...)
> > "David D.W. Downey" wrote:
> >
> > > On Fri, 15 Dec 2000 [EMAIL PROTECTED] wrote:
> > >
> > > > since 3 days now I'm getting the following entries in my logfile:
> > > >
> > > > Dec 15 12:30:15 firewall kernel: Packet log: bad-if DENY lo PROTO=1
> > > > 194.122.33.243:3 194.122.33.243:1 L=92 S=0xC0 I=4595 F=0x0000 T=255 (#1)
This, as someone already mentioned is an icmp unreachable message
(proto=1 => icmp, and the icmp code 3 following the source address and
subcode 1 following the destination address imply "host unreachable").
The firewall is whining because it sees what _appears_ to be a
spoofed packet; it sees a source address and interface combination that
shouldn't happen. I'll bet that 194.122.33.243 is one of your ethernet
inteface IP addresses. Here's what happened.
Your machine tried to send a packet to some host on the Internet.
Since it was going out, say, eth0, it was given a source address of
194.122.33.243. The packet never left the system; some internal check on
the destination address decided that the destination IP was unreachable
before it even left the system.
The IP stack now needs to alert the sender (itself) that the
destination host is unreachable, so it crafts an icmp host unreachable
packet and sends it back to itself. The destination IP is itself
(194.122.33.243). The source address for that packet the same. Since the
packet is going right back to itself, the _loopback_ interface (lo in your
log entry) is picked for actually sending the packet. All completely
legal.
The problem comes because your firewall rules aren't complete
enough to recognize that packets on the loopback interface may legally
have source and destination different from 127.0.0.1, and so logs it as a
"bad-if" error; it thinks these packets should be on eth0 instead of lo.
Usually that's the case, but not always.
I ran into the same problem when I was writing automatic spoof
blocking for Mason. Here's how I handled it:
"We have a special case to allow first. Say 192.168.0.1 is eth0's
ip. If I telnet to that IP on this machine, the source and destination
addresses will be 192.168.0.1 - the spoof block would see this as spoofing
because the packets are showing up on an interface other than eth0. We
need to exempt lo from the check. '-j RETURN' on a chain inserted into
input will do that."
I feel this is safe as an outside user can't inject packets into
the loopback interface.
You might want to contact the author of your firewall script and
ask him/her to update it to allow other addresses on the loopback
interface and no longer log them.
> > > To find out what particular ports are you can also hit
> > >
> > > http://www.stengel.net/tcpports.htm
> > > OR
> > > http://users.dhp.com/~whisper/mason/nmap-services (I like this one)
I can't take credit for this one, even though I include a copy in
the Mason package. It's originally from the nmap package.
Cheers,
- Bill
---------------------------------------------------------------------------
"Absence of evidence is not evidence of absence."
-- SETI, the Search for Extra-Terrestrial Intelligence
--------------------------------------------------------------------------
William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, named2hosts,
and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
