192.168.1.2 is the LAN address of my Gentoo Linux machine.

the router logs are full of **SMURT**
what does this mean ???

[code]
2005/01/31 18:20:08 : **Smurt** from 192.168.1.2
2005/01/31 17:00:03 : **Smurt** from 192.168.1.2
2005/01/31 15:39:58 : **Smurt** from 192.168.1.2
2005/01/31 14:59:54 : **Smurt** from 192.168.1.2
2005/01/31 14:39:49 : **Smurt** from 192.168.1.2
2005/01/31 14:29:45 : **Smurt** from 192.168.1.2
2005/01/31 14:24:42 : **Smurt** from 192.168.1.2
2005/01/31 13:11:01 : **Smurt** from 192.168.1.2
2005/01/31 12:30:57 : **Smurt** from 192.168.1.2
2005/01/31 12:10:52 : **Smurt** from 192.168.1.2
2005/01/31 12:00:48 : **Smurt** from 192.168.1.2
2005/01/31 11:55:45 : **Smurt** from 192.168.1.2
[code]

i am using a Q-tech home broadband router. (cheap, but supports NAT/ port forwarding, DMZ and DynDNS.org)

all google results are in languages i do not understand, thanks.

I think it's a typo from the manufacturer.. could be SMURF
which is a spoofed icmp packet attack..
http://www.google.com/search?hl=en&l...e:SMURF+Attack

ill set my firewall to log all outgoing ICMP traffic, and see whatt turns up.

ahg !!!! HELP!

this is my firewall's OUTPUT chain

shortly after adding th LOG rule, i logged 1035 hits !

all like this..

somthing just pinged my whole 192.168.1.* !
and not from the outside, from my own linux box

rkhunter and f-prot found nothing.

ideas ???

panick averted... i think.....
could this be samba looking for hosts ???

it probably is...

I doubt it. Those are ICMP host unreachable messages leaving the loopback adapter and have your box as the source AND destination addresses. Maybe you have some kind of firewall issue where you're mistakenly blocking internal traffic? If this was Samba looking for hosts, you'd expect it to be on the standard SMB ports. Try using tcpdump to capture some packets on various interfaces (especially lo) and make sure to use the -e option to dump the link level info (what you'd like to get is traffic to/from 192.168.1.2):

tcpdump -e -i <interface> src and dst host 192.168.1.2

Then look at the MAC addresses in the link level info to track down where the initial packets that generate the icmp errors are coming from.

my LISa daemon settings regarding finding new hosts...

If these packets are truely being output through lo (and not eth0) then how is my router logging them ???

i will start the tcp dump and post back here if i find an new info.

hmm....

ive been using

iptables -A INPUT -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
to allow internal traffic...

i assumed that internal traffic addressed by it eth0 address would have been allowed by my

iptables -A INPUT -m state --state ESTABLSIHED,RELATED -j ACCEPT
rule ???

the tcp dump rule you game me picks up rejected pings to my own eth0 address.

i am quite satisfied that my machine is not compromised, would you agree ?

I misread the log messages. If you look at each one, what is generating the msgs is an initial ICMP ping to a host on the 192.168.2.X network probably going out the external interface, which is immediately followed by a subsystem ICMP host unreachable through lo. The subsystem ICMP host unreachable (1st part of log msg) is what is getting logged and the iniitial ping is included in the log message for reference (2nd part of log msg). You can prove this to yourself by having tcpdump listen on lo and then ping a non-existant IP address, you should then see traffic to 192.168.1.2 from 192.168.1.2 over the loopback interface.

So it is LISa incrementally pinging each host on the network and not a compromise or someone trying to spoof IP addresses (as in a smurf attack). For some reason, the router is flagging the internal traffic generated by LISa as smurf, probably the ping to the network broadcast IPi what is getting flagged.

As for your iptables rules, as you can see from this example there are alot more types of traffic on lo addressed to IPs other than 127.0.0.1. I usually use:

iptables -i lo -j ACCEPT

and then just filter invalid IPs like 127.0.01 on the external interfaces.