Setting up a local firewall
I locked myself out of my server until I rebooted it. My goal was to lock down everything and allow only SSH connectivity. Can anyone show me where my logic went wrong? Here was the fatal script which I wrote:
/sbin/iptables -F INPUT/sbin/iptables -A INPUT -s 0/0 -j DROP/sbin/iptables -A INPUT -s 0/0 -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j ACCEPT
My guess is that I missed accepting syn packets, but I'm not ready to "try" again.
Thanks in advance,
Bryan
Quoted 2 lines
Subject: Setting up a local firewall
So, what's a remote firewall? :)
scnr
Jan Engelhardt
Quoted 4 lines · Bryan Christ
I locked myself out of my server until I rebooted it. My goal was to lock down everything and allow only SSH connectivity. Can anyone show me where my logic went wrong? Here was the fatal script which I wrote:
/sbin/iptables-F INPUT/sbin/iptables-A INPUT -s 0/0 -j DROP
First, you drop EVERYTHING from EVERYWHERE.
Quoted 1 line
/sbin/iptables-A INPUT -s 0/0 -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j ACCEPT
Then you allow SSH from everywhere else, which is... NOWHERE.
Quoted 1 line
My guess is that I missed accepting syn packets, but I'm not ready to "try" again.
Instead, get familiar with the principle that "order does matter".
Signature · 1 line
Bjørn
Quoted 11 lines · Bryan Christ
I locked myself out of my server until I rebooted it. My goal was to lock down everything and allow only SSH connectivity. Can anyone show me where my logic went wrong? Here was the fatal script which I wrote:
/sbin/iptables-F INPUT/sbin/iptables-A INPUT -s 0/0 -j DROP/sbin/iptables-A INPUT -s 0/0 -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j ACCEPTMy guess is that I missed accepting syn packets, but I'm not ready to "try" again.
No, you didn't miss that. It is in NEW, but this also means, if the first packet of a connection has only ACK set it will also be in state NEW. Your problem is the second rule, which droppes all packets in INPUT, so no SSH packet will ever make it to your ACCEPT rule. Simply delete the second line and set a policy of DROP|REJECT for INPUT.
BTW, you can omitt "-s 0/0" - it is default. If I were you, I would do it this way:
iptables -P INPUT DROP
iptables -A INPUT -p tcp --state ESTABLISHD -j ACCEPT iptables -A INPUT -p tcp --dport 22 --syn -j ACCEPT [Other useful rules]
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
Have a nice time,
Joerg
Quoted 1 line · Bryan Christ
I locked myself out of my server until I rebooted it. My goal was to
BTDT :)
Quoted 6 lines
lock down everything and allow only SSH connectivity. Can anyone show me where my logic went wrong? Here was the fatal script which I wrote:
/sbin/iptables-F INPUT/sbin/iptables-A INPUT -s 0/0 -j DROP/sbin/iptables-A INPUT -s 0/0 -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j ACCEPT
Rules are evaluated in order. Everything matches your first rule. Nothing reaches the second one.
Quoted 1 line
My guess is that I missed accepting syn packets, but I'm not ready to "try" again.
iptables -F INPUT
iptables -P INPUT DROP
# Let in replies to the connections you initiate iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -i lo -j ACCEPT # allow loopback iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Everything else falls on the default policy.
Strictly speaking the loopback line is not needed; it just means that the system will be able to talk to itself. Similarly the --state line is extra; it just means that when you ssh in you can have useful network connectivity. I put that one in its own chain ...
iptables -F ; iptables -X
iptables -N State
iptables -A State -m state --state INVALID -j DROP iptables -A State -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -I INPUT -j State
iptables -I FORWARD -j State
See, that's the first rule in both INPUT and FORWARD. Order is important! That's why we have -A|--append and -I|--insert.
Signature · 2 lines
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header