Ah, looking at my firewall I've got: -A output -s 127.0.0.1/255.0.0.0 -d 127.0.0.1/255.0.0.0 -p 17 -j ACCEPT -A output -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j REJECT -l -A output -s 0.0.0.0/0.0.0.0 -d 127.0.0.0/255.0.0.0 -j REJECT -l -A input -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l -A input -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l
So from what you are saying I should add: -A output -s 127.0.0.1/255.0.0.0 0 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 3 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 4 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 8 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 11 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 12 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT ? Should these be allowable from 127.0.0.1 to anywhere? And would the ICMP port orginate on the 127.0.0.1 end or the destination end? Micah On Sun, 11 Feb 2001, Simon Murcott wrote: > Tim Bishopric wrote: > > > This log shows that Ipchains is rejecting outbound loopback (lo) traffic > > with a source IP of 127.0.0.1 and a destination of 127.0.0.1. Protocol 1 > > is ICMP (see /etc/services) and I think type 3 reports "destination > > unreachable." If you block ICMP, you will have problems with DNS, > > timeouts, etc. > > > > More info: > > http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html#2 > > It is definitely not wise to block ICMP unreachables, source-quench, > parameter-problem and time-exceeded. But it is wise to block ICMP redirect, > timestamp-(req|reply), info-(req|reply) and address-(req|reply). The only > exception is that if you can trust a router then it MAY be ok to accept > redirects > from it. > > I leave pings up to your descretion :p > > I usually recommend blocking all ICMP except for: > 0 echo reply (ping reply) > 3 destination unreachable > 4 source quench > 8 echo request (ping) > 11 time exceeded > 12 parameter problem > > This stuff is all diagnostics, the rest has questionable use (even on > internal networks). > > Regards > > Simon Murcott > e. [EMAIL PROTECTED] > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
