Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've been going through my web server, getting rid of some security holes and set up iptables to do port redirects so my server instance does not have to run under root. The port redirects seem to work fine but I just noticed that outgoing SSH connections don't seem to work anymore. When I flush iptables, SSH starts working again. Can someone give some advice for how I'm misconfiguring things?
Here's my iptables configuration. I'm marking all incoming port 3000 and am pushing port 80 to 3000.
Your SSH problem is related to name resolution (DNS). If you run the hostname github.com and nslookup -q=A github.com commands, I'm pretty certain you'll see similar error messages.
Are you running an internal DNS server or do the entries in /etc/resolv.conf point to external servers?
I noticed that your iptables ruleset seems to be missing a loopback rule (which would affect the availability a local DNS service), and that packets matching the RELATED state aren't covered either. Unfortunately, iptables -L does not display all match criteria for each rule. Could you post the output from iptables-save?
Ah, good suggestion. It got me part of the way there. I tried the DNS, loopback (although isn't that already covered by allowing all 127.0.0.1?) and RELATED suggestions you gave. The second two didn't seem to make a difference but adding in a line to allow UDP incoming on port 53 got me a little further on the ssh login than before.
My updated iptables.rules:
Code:
cat /etc/iptables.rules
# Generated by iptables-save v1.4.12 on Sat Apr 12 21:44:10 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m mark --mark 0x29a -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 3000 -j ACCEPT
-A INPUT -i eth0 -p icmp -j ACCEPT
-A INPUT -s 127.0.0.1/32 -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -i eth0 --sport 53 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -j ACCEPT
COMMIT
# Completed on Sat Apr 12 21:44:10 2014
# Generated by iptables-save v1.4.12 on Sat Apr 12 21:44:10 2014
*mangle
:PREROUTING ACCEPT [1513:155297]
:INPUT ACCEPT [1507:154937]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1292:196669]
:POSTROUTING ACCEPT [1292:196669]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 3000 -j MARK --set-xmark 0x29a/0xffffffff
COMMIT
# Completed on Sat Apr 12 21:44:10 2014
# Generated by iptables-save v1.4.12 on Sat Apr 12 21:44:10 2014
*nat
:PREROUTING ACCEPT [25:1470]
:INPUT ACCEPT [16:960]
:OUTPUT ACCEPT [67:4047]
:POSTROUTING ACCEPT [67:4047]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3000
COMMIT
Here's the output from SSH. It was hanging one line earlier until adding the DNS exception. It still hangs though.
Code:
ssh -v git@github.com
OpenSSH_5.9p1 Debian-5ubuntu1.3, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 1: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to github.com [192.30.252.128] port 22.
debug1: connect to address 192.30.252.128 port 22: Connection timed out
ssh: connect to host github.com port 22: Connection timed out
Ah, good suggestion. It got me part of the way there. I tried the DNS, loopback (although isn't that already covered by allowing all 127.0.0.1?) and RELATED suggestions you gave. The second two didn't seem to make a difference but adding in a line to allow UDP incoming on port 53 got me a little further on the ssh login than before.
You should not have to explicitly allow return traffic for each and every service. A general rule for ESTABLISHED traffic is the way to go. Also, a 127.0.0.1/32 rule does not cover localhost traffic; see comment below.
Quote:
Originally Posted by DanHeidel
Code:
cat /etc/iptables.rules
# Generated by iptables-save v1.4.12 on Sat Apr 12 21:44:10 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m mark --mark 0x29a -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
That's not exactly what I meant. You will need a general rule to allow all traffic matching the ESTABLISHED and RELATED states, and that rule should be very near the top of the chain:
Code:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
That's the rule that will allow return traffic of any kind to get through. Without it, reply packets from the SSH daemon at github.com (or anywhere else) will be blocked.
The SSH rule in the INPUT chain should indeed allow only NEW packets to TCP port 22.
Code:
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
Quote:
Originally Posted by DanHeidel
Code:
-A INPUT -s 127.0.0.1/32 -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
The first of these two rules will match exactly nothing at all and should be removed. Apart from the fact that localhost traffic can have source and destination addresses in the entire 127.0.0.0/8 network, no such traffic will ever enter or exit a physical interface like eth0.
The second rule is all you need, and the loopback rule should always be the very first rule in the chain, to keep other rules from interfering with loopback traffic.
Quote:
Originally Posted by DanHeidel
Code:
-A INPUT -p udp -i eth0 --sport 53 -j ACCEPT
Unlesss you run a local DNS server and want the world to be able to access it, this rule should be removed.
Edit: There's an interesting security hole here, as a request from UDP source port 53 will be able to access ANY service. Not recommended.
Thanks Ser, that was very helpful. SSH is now working.
Can you point me towards a good reference for using iptables? Both the faulty localhost and DNs configuration linew were taken from iptables tutorials I found online. I'd like to avoid other bad advice, especially for configurations that will compromise system security.
Here's my final config file, just in case there's any other glaring errors anyone can point out to me:
Code:
# Generated by iptables-save v1.4.12 on Sat Apr 12 21:44:10 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m mark --mark 0x29a -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 3000 -j ACCEPT
-A INPUT -i eth0 -p icmp -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -j ACCEPT
COMMIT
# Completed on Sat Apr 12 21:44:10 2014
# Generated by iptables-save v1.4.12 on Sat Apr 12 21:44:10 2014
*mangle
:PREROUTING ACCEPT [1513:155297]
:INPUT ACCEPT [1507:154937]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1292:196669]
:POSTROUTING ACCEPT [1292:196669]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 3000 -j MARK --set-xmark 0x29a/0xffffffff
COMMIT
# Completed on Sat Apr 12 21:44:10 2014
# Generated by iptables-save v1.4.12 on Sat Apr 12 21:44:10 2014
*nat
:PREROUTING ACCEPT [25:1470]
:INPUT ACCEPT [16:960]
:OUTPUT ACCEPT [67:4047]
:POSTROUTING ACCEPT [67:4047]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3000
COMMIT
The ruleset looks good to me. Took me a few seconds to realize what the fwmark rule in the mangle chain was all about, but once I saw the rule in the nat chain it all became clear.
As for a good iptables reference, I'm afraid I know of no such thing. The problem is that a document about good firewall design with iptables would have to cover a lot of topics, from general security guidelines and "best practices" to the iptables rule syntax. That's easily enough material to fill a few hundred pages.
It's also worth noting that the netfilter engine has just been redesigned (again) and the new system, "nftables", has recently become part of the mainline kernel. An iptables compatibility layer exists (as it did for the previous incarnations of the Linux kernel firewall, ipfwadm and ipchains), but we should expect to see the iptables, ip6tables, arptables and ebtables utilities marked as deprecated in the very near future.
In other words, this may not be the best time to learn about the intricacies of iptables. nftables, here we come.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
