On Friday 09 January 2004 01:40 am, L. Mark Stone wrote:
I looked in the archives, but the previous posts on this topic didn't say for sure whether these log entries are benign (or not).
Anyone care to hazard a guess at the interpretation of the following entries?
Note that the machine generating these messages has a fixed private IP address of 192.168.15.225, runs Samba server and connects to the Internet (via wireless) through a SonicWall Tele3 appliance (if all of that info is helpful).
Thanks!
Jan 8 20:33:13 outside kernel: SuSE-FW-DROP-ANTI-SPOOFING IN=wlan0 OUT= MAC= SRC=192.168.15.225 DST=192.168.15.255 LEN=259 TOS=0x00 PREC=0x00 TTL=64 ID=6763 DF PROTO=UDP SPT=138 DPT=138 LEN=239
Hmmm... The 192.168.15.255 address is the broadcast address for the 192.168.15.0/24 subnet, so you shouldn't really have an interface with that IP address. Thus, this box ('outside') is receiving a broadcast message from another box on that subnet. Actually, it looks like 'outside' is sending this packet. The SPT= and DPT= are Source and Destination Port - 138 is something to do with NETBIOS, so likely related to samba. Maybe 'outside' is broadcasting for any other smb servers on the network?
Jan 8 20:33:13 outside kernel: martian source 192.168.15.255 from 192.168.15.225, on dev wlan0 Jan 8 20:33:13 outside kernel: ll header: ff:ff:ff:ff:ff:ff:00:80:c8:16:38:4a:08:00
This is nothing to worry about too much. I've been investigating martian source packets for a month or so recently, and all I can discover is that they are Mostly Harmless. The MAC address of the offending machine is contained in the 'll header:...' line. As to why they occur or how to get rid of them, there seems to be no answer. The best I found is document RFC1812 (from www.w3c.org) : <QUOTE> 5.3.7 Martian Address Filtering An IP source address is invalid if it is a special IP address, as defined in 4.2.2.11 or 5.3.7, or is not a unicast address. An IP destination address is invalid if it is among those defined as illegal destinations in 4.2.3.1, or is a Class E address (except 255.255.255.255). A router SHOULD NOT forward any packet that has an invalid IP source address or a source address on network 0. A router SHOULD NOT forward, except over a loopback interface, any packet that has a source address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks. A router SHOULD NOT forward any packet that has an invalid IP destination address or a destination address on network 0. A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks. If a router discards a packet because of these rules, it SHOULD log at least the IP source address, the IP destination address, and, if Baker Standards Track [Page 96] RFC 1812 Requirements for IP Version 4 Routers June 1995 the problem was with the source address, the physical interface on which the packet was received and the Link Layer address of the host or router from which the packet was received. 5.3.8 Source Address Validation A router SHOULD IMPLEMENT the ability to filter traffic based on a comparison of the source address of a packet and the forwarding table for a logical interface on which the packet was received. If this filtering is enabled, the router MUST silently discard a packet if the interface on which the packet was received is not the interface on which a packet would be forwarded to reach the address contained in the source address. In simpler terms, if a router wouldn't route a packet containing this address through a particular interface, it shouldn't believe the address if it appears as a source address in a packet read from this interface. If this feature is implemented, it MUST be disabled by default. DISCUSSION This feature can provide useful security improvements in some situations, but can erroneously discard valid packets in situations where paths are asymmetric. </QUOTE> You can turn off the logging of these with: echo 0 > /proc/sys/net/ipv4/conf/<interface>/log_martians but I would expect that if you change the IP of 'outside' wlan0 you'll not see the errors. HTH Dylan -- "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin