It is true that connections to remote X Window servers should be always made over SSH. SSH supports X windows connections. So my task was allow X over ssh but block unprivileged X windows mangers TCP ports.
The first running server (or display) use TCP port 6000. Next server will use 6001 and so on upto 6063 (max 64 X managers are allowed from 6000-6063).
So assuming that you are going to force user to use ssh for remote connections, here are rules for IPTABLES (add to your firewall script):
iptables -A OUTPUT -o eth0 -p tcp --syn --destination-port 6000:6063 -j REJECT
iptables -A INPUT -i eth0 -p tcp --syn --destination-port 6000:6063 -j DROP
a) The first rules blocks outgoing connection attempt to remove X windows manger.
b) The second rule block incoming request for X windows manger. By using –syn flag you are blocking only connection establishments to the server port.
This is the good way to disallow unprivileged X windows mangers – TCP 6000:6063 ports 🙂
A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target’s system. This is a well known type of attack and is generally not effective against modern networks. It works if a server allocates resources after receiving a SYN, but before it has received the ACK.
if Half-open connections bind resources on the server, it may be possible to take up all these resources by flooding the server with SYN messages. Syn flood is common attack and it can be block with following iptables rules:
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j RETURN
All incoming connection are allowed till limit is reached:
- –limit 1/s: Maximum average matching rate in seconds
- –limit-burst 3: Maximum initial number of packets to match
Open our iptables script, add the rules as follows:
# Limit the number of incoming tcp connections
# Interface 0 incoming syn-flood protection
iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -j DROP
#Limiting the incoming icmp ping request:
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j LOG --log-prefix PING-DROP:
iptables -A INPUT -p icmp -j DROP
iptables -A OUTPUT -p icmp -j ACCEPT
First rule will accept ping connections to 1 per second, with an initial burst of 1. If this level crossed it will log the packet with PING-DROP in /var/log/message file. Third rule will drop packet if it tries to cross this limit. Fourth and final rule will allow you to use the continue established ping request of existing connection.
- â€â€limit rate: Maximum average matching rate: specified as a number, with an optional â€˜/secondâ€™, â€˜/minuteâ€™, â€˜/hourâ€™, or â€˜/dayâ€™ suffix; the default is 3/hour.
- â€â€limitâ€burst number: Maximum initial number of packets to match: this number gets recharged by one every time the limit specified above is not reached, up to this number; the default is 5.
You need to adjust the â€“limit-rate and â€“limit-burst according to your network traffic and requirements.
Let us assume that you need to limit incoming connection to ssh server (port 22) no more than 10 connections in a 10 minute:
iptables -I INPUT -p tcp -s 0/0 -d $SERVER_IP --sport 513:65535 --dport 22 -m state --state NEW,ESTABLISHED -m recent --set -j ACCEPT
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 11 -j DROP
iptables -A OUTPUT -p tcp -s $SERVER_IP -d 0/0 --sport 22 --dport 513:65535 -m state --state ESTABLISHED -j ACCEPT
More information on recent patch can be found here