Allowing SSH on LAN with iptables

[alienjon]

I have my iptables setup on a server to drop all packets by default. I would like to allow unfettered access to SSH to this server so long as you are on the LAN (192.168.1.*). Currently, I cannot SSH to the machine at all. The following line allows access, except despite my specifying the LAN IPs, I can also access it from the Internet:

[Logicien]

First I would verify that your machines are seen on your local network

[alienjon]

I can ping and access the server just fine without any iptables policies set. The setup I currently have is actually a bit more than I mentioned in my OP, but I'm only referencing the relevent commands (by that I mean that without the line in the OP allowing ssh connections I am unable to connect because the default policy is to DROP, but when I add the line there seems to be universal access to the machine.

I had tested from my cell phone, actually, as I can connect via wifi with a local address or via the mobile data and connect via the cell connection with a non-local address. The only thought which comes to mind is that my lan gets access to the internet through a router, which forwards all port 22 traffic to this server. Is it possible that iptables is registering the router's address (which would be on the lan) instead of the wan address?

[Logicien]

If you don't want any service of your local network be available from Internet you can block them at your router level and/or at the Linux Netfilter level. Some routers have the option to act only as a modem. Linux is my only router, firewall and gateway to Internet for all my local networks, cabled, wireless, Bluetooth and virtual. My cable modem do not have any of these capabilities. According to GRC | ShieldsUP! — Internet Vulnerability Profiling no port is open and I am not seen from Internet.
_________________
Paul

[NeddySeagoon]

alienjon,

Your router will do NAT, so anything permitted from the outside world will appear to originate from the router on your LAN.
For NAT to work, the router must be doing forwarding.

That means you need to drop packets that have your router as the source address.
That can be messy if you have several subnets in use. Depending on the setup, the other subnets may be NATed too, so you won't be able to connect from them.

The right place to drop internet packets you don't want is your router.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[alienjon]

[Hu]

It is certainly possible that your router is NAT'ing Internet packets to appear to come from the router. If that is happening, I would consider that to be an incorrect configuration of the router. NAT should only be used when the intended recipient cannot cope with the true address. When you connect from the LAN to the WAN, NAT is necessary because peers on the Internet have no way to route traffic to a 192.168.x.x source. When the WAN peer connects to you, your normal routing could send the traffic back to them, so your router should not be configured to NAT WAN traffic.

Your shown iptables rules would likely achieve your goal, but I think you would be better served identifying why traffic from the Internet appears to originate from the LAN and change the configuration to prevent that.

[alienjon]

[szatox]

Login with ssh from the outside and type "who".
You should find your session together with the IP your server sees as your client's.

[Hu]

If ss shows the true IP, then that is also the IP that iptables should have seen, and the problems described earlier in the thread should not have happened.

[alienjon]

[Hu]

The default mode of routers is to preserve the source IP information. Mangling it as you see is only done when NAT is used. You should investigate the rules on the router to determine why it is NATing traffic in the wrong direction. If it were a general purpose Linux system, I would say post the output of iptables-save -c. I do not know if you can get that output from a DD-WRT system.

[alienjon]

[Hu]

That is very strange. iptables-restore is of limited value without iptables-save, so it is surprising that they shipped one and not the other. Absent iptables-save, you can use iptables --list-rules on each table (nat, filter, etc.) in turn. The nat table is the most likely to be interesting here.

[alienjon]

[Hu]

No, I mean --list-rules, which works for me with iptables version 1.4.21, and is mentioned and described in the manual page installed with it. Perhaps your router ships an older, less capable, version of iptables which lacks this command. If so, you will need to improvise, since --list has a nasty habit of obscuring important details. If you are stuck using --list, add in --exact --line-numbers --verbose --numeric.

[NeddySeagoon]

alienjon

iptables -L -t <table_name>
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[alienjon]

[Hu]

I concur with your analysis. The first two rules in the POSTROUTING chain look bogus to me. If there are no hidden qualifiers on those rules (you did not use --verbose, so some match qualifiers, such as interface, are hidden; iptables --list-rules or iptables --list --verbose would show these), then I am surprised your network works at all. It looks like all traffic should match the first rule, causing your router's IP to be used for everything. If your ISP is not performing another layer of NAT on your outbound traffic, you would be sending traffic to the world with your router's internal IP (assuming that is what {ROUTER IP} represents), which should not work.

I would use as the sole POSTROUTING rule -o $WAN_INTERFACE -j MASQUERADE. Let traffic that is sent out $LAN_INTERFACE pass without modification. Let the kernel determine the correct IP address to insert on NAT'd traffic.

[alienjon]

Yes, {ROUTER IP} being the subnet gateway address (*.*.*.1). With verbose:

[Hu]

This is an anti-security measure. By changing the source address of the traffic, you give it the appearance that it comes from the router, which may cause hosts that would otherwise distrust it to treat it as safe. You should remove the first rule and the third rule. Let traffic destined to your ISP be rewritten. Let all other traffic pass with its true address. These rewrites have no effect on where the traffic goes, so anyone attempting to attack a host would still hit the host he intended. However, it would appear that the attack originated from the router, which would make forensics more difficult. Hence, anti-security.

[alienjon]

That's a good point and well beyond concerning... I'm tempted to clear out all the iptables rules and put in my own, though as this is the family router I'm also tempted to go with the "if it's not broke, don't fix it". I am looking into a router upgrade at some point soon and might play around with it after that when there's less of a chance of downtime for the rest of the family.

[Hu]

I think you would not break anything by removing only the rules I cited. I cannot comment on your proposed replacement. I have never used it.