[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: iptables ruleset ...



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manfred Sampl said:
> Hi,
> 
> My input ruleset doesn't work as it should... I'm using woody /
> netfilter on 2.4.27 (debian kernel I think) for doing the routing on a
> DSL connection.
> 
> I can't reach ssh on the external interface.
> 
> What is wrong? and are the spoofing rules not redundant? The default
> policy is DROP.

LOG is your friend. Use it before the end of your script and see what's
getting dropped. If it's not getting logged, then some explicit DROP
further up in the chain may be getting it. I find this technique
useful:

iptables -L -n -v > iptables1

...now try to ssh in from the outside...

iptables -L -n -v > iptables2

diff iptables1 iptables2

The output of diff should narrow it down as to what rule increased its
counter. Of course, it's not perfect and in the time you take to run the
two commands, other counters will probably increase as well. But it
should help give you an idea.

Also it may not be getting there at all. Perhaps your isp doesn't allow
ssh connections in at all and it's getting dropped upstream.
tcptraceroute is great for that kind of testing. Overall I'd say your
script should work. Other things to look at are making sure your ssh
server is listening on all interfaces with something like:

netstat -an | grep :22

should show something like:
tcp        0      0 0.0.0.0:22    0.0.0.0:*       LISTEN

As far as the spoofing rules go. Yes, it would get dropped eventually if
the default policy is drop. But it's nice to set that rule up front. It
keeps it from having to traverse the entire chain. You know you should
never get traffic on your internet interface from these ranges, so just
drop it up front. Also goes nice with a LOG rule to see if your upstream
is leaking private space traffic out onto the net. :)

/phil


-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCChbe0q9tKssDeQcRAjQUAJ9jMmWCteFpbMbOKnDORMMFyZ9aagCdGeAw
9NNBunHhrNVbNoMPeCoJYqQ=
=Cakq
-----END PGP SIGNATURE-----



Reply to: