On Mon, Dec 10, 2001 at 01:52:51PM +1000, mdevin wrote: > 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? Whoops. It does actually work sorry. I forgot that my /etc/hosts.deny file had this in it: ALL: PARANOID After commenting this out, things worked for No 6. above which goes to show that what you were saying works exactly as you said. Thanks for pointing this out, it has really edemucated (sic) me. > > > > > 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. Now after proving that it does actually work, still nothing was logged by my firewall despite exactly the above iptables rules right at the head of my INPUT chain. Thus I can only conclude that the state INVALID match does not stop this sort of thing. Please someone refute this if I am wrong. Cheers. Mark.
Attachment:
pgpPs5_GuzuZh.pgp
Description: PGP signature