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?