On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > I try to explain again: > > You have a Linux box with "eth0" and "eth1". "eth0" is the Internet > interface, "eth1" is the interface to the LAN. > > IP addresses: eth0 - 123.123.123.123 > eth1 - 192.168.0.1 > > You want remote access from your LAN to the Linux Box with ssh. So you > bind the sshd to 192.168.0.1 and think, now the sshd is only reachable > from your LAN. > > The atacker is client at the same provider than you are and in the same > network segment (sorry for my english!). > > The atacker sets a route like this: > > route add 192.168.0.1 gw 123.123.123.123 > > And now "ssh 192.168.0.1" will work without routing on _your_ box > activated. So the FORWARD chain from ipchains will not work for that. OK I just tried something similar. Here is what I just did: 1. First to prove that I can indeed ssh in on loopback I did: ssh 127.0.0.1 ---> worked OK 2. I added a route for my LAN IP address (192.168.0.2) via loopback route add 192.168.0.2 gw 127.0.0.1 3. Then I edited /etc/ssh/sshd_config and changed the IP addresses that sshd will bind to so that it only binds to 192.168.0.2 ListenAddress 192.168.0.2 4. Then told sshd to reload its config /etc/init.d/ssh reload 5. Then tried to ssh in on loopback again (should now refuse). ssh 127.0.0.1 ---> Secure connection to 127.0.0.1 refused 6. Then tried to ssh in on 192.168.0.2 (should work) ssh 192.168.0.2 ---> ssh_exchange_identification: Connection closed by remote host What is the go here? From what you were saying above, No 6. should have worked, right? > > > 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)? > > I don't know. I am not very experianced with iptables. > Also, my firewall (iptables) which does have the following rules: iptables -A INPUT -m state --state INVALID -j LOG iptables -A INPUT -m state --state INVALID -j DROP Did not log anything during this experiment. So I still not sure about the state INVALID match for these packets. Can you explain why the above test did not work? Cheers. Mark.
Attachment:
pgpTkoqAamYpD.pgp
Description: PGP signature