LinuxQuestions.org - appending iptables rules interrupts sshd

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - appending iptables rules interrupts sshd (https://www.linuxquestions.org/questions/linux-networking-3/appending-iptables-rules-interrupts-sshd-4175428797/)

appending iptables rules interrupts sshd

If I log into remote machine over SSH, execute screen(1) and start following commands:

Code:

root@s1:~# iptables -t filter -A INPUT -s 10.10.10.0/24 -i eth1 -j ACCEPT; iptables -t filter -A INPUT -i eth1 -j DROP; iptables-save; sleep 30; iptables -t filter -F INPUT

# Generated by iptables-save v1.4.12.2 on Mon Sep 24 10:46:46 2012

*nat

:PREROUTING ACCEPT [896:73953]

:INPUT ACCEPT [358:24932]

:OUTPUT ACCEPT [382:25732]

:POSTROUTING ACCEPT [382:25732]

COMMIT

# Completed on Mon Sep 24 10:46:46 2012

# Generated by iptables-save v1.4.12.2 on Mon Sep 24 10:46:46 2012

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -s 10.10.10.0/24 -i eth1 -j ACCEPT

-A INPUT -i eth1 -j DROP

COMMIT

# Completed on Mon Sep 24 10:46:46 2012

root@s1:~#

..my current SSH session from 10.10.10.0/24 network hangs for 30 seconds and I'm not able to start new SSH sessions to "s1" server from 10.10.10.0/24 network. On the other hand, I'm able to ping "s1" server from 10.10.10.0/24 and "nmap -PN -sT --reason -p22 s1" reports, that port 22 is open:

Code:

PORT  STATE SERVICE REASON

22/tcp open  ssh    syn-ack

If I execute "ssh -v root@s1" from 10.10.10.0/24 network during this 30s window before flushing the INOUT filter rules, last debug messages are:

Code:

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

Has anyone seen such behavior where appending iptables rules affects sshd behavior? Or am I doing something wrong?

Quote:

Originally Posted by m4rtin (Post 4788059)

Or am I doing something wrong?

Well to start with your rule set is incomplete to the point where adding any -j ACCEPT rules is pointless. With a filter table default chain policy set to DROP you're supposed to add -j ACCEPT rules and conversely -j DROP rules when using a default ACCEPT policy...

Quote:

Originally Posted by unSpawn (Post 4788084)

ok, but in case of such rules:

Code:

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -s 10.10.10.0/24 -i eth1 -j ACCEPT

-A INPUT -i eth1 -j DROP

COMMIT

..I should be able to access "s1" over SSH from 10.10.10.0/24, shouldn't I? In addition, as I said, for example I'm able to telnet to port 22 or confirm with nmap, that it's open :rolleyes:

Well you executed "ssh -v root@s1", never mind you logging in as root (for now), so if you want to read the other part of the story, next to 'ssh -vvv' you should also execute 'sshd -ddd'.