On Sun, Dec 09, 2001 at 07:45:52PM +0100, Guido Hennecke wrote: > Please dont answer to the list _and_ to me. Thank you. > > At 09.12.2001, Tim Haynes wrote: > > "Phillip Hofmeister" <firstname.lastname@example.org> writes: > > [snip] > > > > If an attacker in the same network sets a route like that: > > > > > > > > 127.0.0.1 Gateway <your official ip address> Interface <his > > > > externel interface> > > > Couldn't this be countered with: > > > ipchains -i !lo -d 127.0.0.1 -j DENY > > > ? > > Better, > > iptables -A INPUT -m state --state INVALID -j LOG > > iptables -A INPUT -m state --state INVALID -j DROP > > (and OUTPUT as well, for those paranoid enough to do egress filtering). > > > > Also, > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > with echo 1 > /proc/sys/net/ipv4/conf/*/log_martians > > for logging/fun purposes. > > rp_filter will not help with that. > OK, you guys have started to confuse me a little just when I thought I was getting a handle on this firewalling stuff. Now, please explain what an attacker would do in your example above. Do you mean the following?: 1. The attacker (on your LAN) alters his routing table so that all packets destined for 127.0.0.1 go to your official IP address via his LAN interface. ie. something like: # route add -net 127.0.0.0 gw 192.168.1.1 eth0 (Where 192.168.1.1 is the address of your firewall box running ssh - which you are trying to prevent the attacker from logging into.) 2. Then when he does ssh into 127.0.0.1 Is that what you meant? Would that mean that your firewall box (running ssh) would see the packets as coming from source 192.168.1.2 (the attacker's IP address on the LAN) and going to destination 127.0.0.1 (local)? Then the sshd daemon would see the connection attempt as seeming to be a local connection (127.0.0.1). If I have got the reasoning correct, then I can see the problem. It would seem easy to do this from the LAN, but I don't think possible from the internet - since packets with destination 127.0.0.1 would not get routed. Second question: Why does the state INVALID match match these packets. Are they flagged as invalid because they have come in from eth0 but with a destination of 127.0.0.1 (which should be impossible)? Thanks to anyone who can make this a little clearer. Cheers. Mark.
Description: PGP signature