-1

I just want to prevent nmap and packets that are considered harmful to my VPS (Setup : Debian - Nginx webserver). After applying these rules and disconnecting from ssh I couldn't reconnect anymore.

So I contacted the provider and asked them to flush the rules from backend. Can someone tell me which rules are wrong, or bad configured ? Is there any unnecessary rules in there which is not needed ?

I gathered these form a question named "Iptabled tips and tricks" and I thought it would neglect any kind of packet attack.

iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 127.0.0.0/8 -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -d 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP
iptables -A INPUT -d 240.0.0.0/5 -j DROP
iptables -A INPUT -s 0.0.0.0/8 -j DROP
iptables -A INPUT -d 0.0.0.0/8 -j DROP
iptables -A INPUT -d 239.255.255.0/24 -j DROP
iptables -A INPUT -d 255.255.255.255 -j DROP
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
iptables -A INPUT -p tcp --syn -m limit --limit 7/s -m recent --name blacklist --set -j DROP
iptables -A INPUT -m recent --rcheck --nam blacklist -j DROP
iptables -A INPUT -p tcp -i eth0 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 10 -j DROP
iptables -A FORWARD -p tcp -i eth0 -m state --state NEW -m recent --set
iptables -A FORWARD -p tcp -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 10
3
  • 1
    implementing tons of iptables rules in one shot can be tricky. Also there are better tools to protect against nmap scans - portsentry comes to mind. I'd suggest to do one at the time. You must be blocking your IP somewhere there. May 11, 2012 at 9:21
  • remove "iptables -A INPUT -s 127.0.0.0/8 -j DROP" or add on the top. iptables -A INPUT -p tcp --dport 22 -s YOURIP/32 -j ACCEPT.
    – chocripple
    May 11, 2012 at 10:05
  • @Rikih That didn't work. I did a few test myself to check which line is culprit, It seems to be these 2 line which prevents connection applying : iptables -A INPUT -p tcp --syn -m limit --limit 7/s -m recent --name blacklist --set -j DROP and iptables -A INPUT -m recent --rcheck --nam blacklist -j DROP
    – Hassan
    May 11, 2012 at 11:56

1 Answer 1

0

Checked every line and the problem which caused ssh disconnect. These are two lines :

iptables -A INPUT -p tcp --syn -m limit --limit 7/s -m recent --name blacklist --set -j DROP
iptables -A INPUT -m recent --rcheck --nam blacklist -j DROP

Btw, I found another way to do all these security measures without manually applying iptables when you don't have knowledge (like myself). Just check csf. A very easy and simple application with tons of features.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .