> Nov 14 08:43:42 fwbox kernel: Packet log: ext-if DENY lo PROTO=1 > x.y.z.a:3 x.y.z.a:1 L=100 S=0xD0 I=157 F=0x0000 T=255 (#1) > ... > > This stuff ricochets on the loopback lo with a 'destination-unreachable' > > ICMP packet as the source protocol and an 'unassigned' ICMP packet > (type 1) as the destination. > If I interpret RFC 792 (ICMP) correctly, ICMP type 3, code 1 is: host unreachable. I don't know why you're seeing them, but in ipchains logs, for ICMP they use the source port placeholder of TCP or UDP for the ICMP type and the destination port is replaced by the ICMP code. There is no notion of source or destination types and/or codes in ICMP.
However, your ipchains rules are preventing your box from receiving its own ICMP messages on the loopback interface, which is probably being used by two processes to communicate. In general, people allow unrestricted communication via the loopback interface, since everything remains within the machine itself and is invisible to the outside. > -- Is this a smurf attack? > Doesn't look like it to me, since Smurf involves ping packets, i.e. you'd be seeing echo replies(ICMP type 0, code 0), and probably to a different box than your own. > -- If so, am I getting hammered from outside? > Not likely, at least that's not what you're seeing, since only the loopback interface is involved. Could be that some outside action is triggering the inter-process communication on your box, but the packets being logged originate from your box and are destined to it as well. > -- Have I been breached and a trojan is trying to launch an attack from > my firewall box? > Perhaps. I'm a bit confused by the code that the ICMP messages you're seeing have. After all, host x.y.z.a is reachable.. One explanation could be that you're 'reject'ing some traffic and that ipchains' 'reject' message is an ICMP host unreachable. Now it shouldn't be the messages you're logging themselves, as those say that the reaction of the kernel packet filter is to deny (i.e. silently drop) them. Could be you're being hit by an attacker spoofing his IP address for x.y.z.a. He could be sending packets that your box is rejecting with an ICMP host unreachable, which is sent to the supposed originator of the offending packet, which is the spoofed address of the box itself. But this is really wild speculation. > -- Or is this something caused by a configuration error on my part? > (http://linux.oreillynet.com/lpt/a/linux/2000/03/10/netadmin/ddos.htmlsugg > ests that logging can itself trigger DOS) > A configuration error is very much possible. > This pattern in the log continues until I restart the box Windoze style. > Is there a more > appropriate way to abort this? > Well, you could allow any traffic across the 'lo' interface, I don't see much harm done in that (does anybody else?). If you're looking for the root of the problem, I suggest you set up logging rules to catch any packets from the machine to itself on all interfaces and you should be able to find the packets that trigger the 'ICMP flood' you're observing. > As an attempted preventative, I've added to the firewall initialization > script to turn on /proc/sys/net/ipv4/icmp_ignore_echo_broadcasts > However, this has not eliminated this problem. > Good thing to do nevertheless. > BTW, the relevant part of the ipchains script (for the external > interface of the firewall box) is this: > > # rules for firewall box itself > # EXTIF is eth1 > # I'm not running DNS here but rather pointing to the ISP's DNS > # --allow www (for dselect upgrade of firewall box) > # --allow DNS so www will work > > /sbin/ipchains -A ext-if -i ! $EXTIF -j DENY -l > /sbin/ipchains -A ext-if -p TCP --dport www -j ACCEPT > /sbin/ipchains -A ext-if -p TCP -s $DNSIP1 domain -j ACCEPT > /sbin/ipchains -A ext-if -p UDP -s $DNSIP1 domain -j ACCEPT > /sbin/ipchains -A ext-if -p TCP -s $DNSIP2 domain -j ACCEPT > /sbin/ipchains -A ext-if -p UDP -s $DNSIP2 domain -j ACCEPT > /sbin/ipchains -A ext-if -p TCP --dport 61000:65096 -j ACCEPT > /sbin/ipchains -A ext-if -p UDP --dport 61000:65096 -j ACCEPT > /sbin/ipchains -A ext-if -p ICMP --icmp-type ping -j ACCEPT > /sbin/ipchains -A ext-if -p ICMP --icmp-type pong -j ACCEPT > /sbin/ipchains -A ext-if -j icmp-acc > /sbin/ipchains -A ext-if -j DENY -l > Well, the log says that it's the topmost line of these that is denying the packets in question, which makes sense, since they're not on the external interface. The question is, when is the 'ext-if' chain called? Glancing over http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO-7.html, I guess your 'ext-if' corresponds to 'bad-if' in their example. Now, from my observation, it is very much possible to see traffic on the loopback interface with both source and destination addresses matching an IP address given to one of the physical interfaces. IIRC, it happens on DNS lookups, for example, if you have a DNS server or cache running on the machine itself and put (one of) the machine's 'external' address(es) into /etc/resolv.conf. However, it's been a while since I actively investigated this. HTH Tobias _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
