Difference between revisions of "IPTables"
(→Iptables Filtering) |
(→Iptables Filtering) |
||
| Line 84: | Line 84: | ||
# services SMTP HTTP HTTPS | # services SMTP HTTP HTTPS | ||
| − | # iptables -A INPUT -p tcp -j ACCEPT --dport 25 -m conntrack --ctstate NEW | + | # iptables -A INPUT -p tcp -j ACCEPT --dport 25 -m conntrack --ctstate NEW |
iptables -A INPUT -p tcp -j ACCEPT --dport 80 -m conntrack --ctstate NEW | iptables -A INPUT -p tcp -j ACCEPT --dport 80 -m conntrack --ctstate NEW | ||
| − | # iptables -A INPUT -p tcp -j ACCEPT --dport 143 -m conntrack --ctstate NEW | + | # iptables -A INPUT -p tcp -j ACCEPT --dport 143 -m conntrack --ctstate NEW |
iptables -A INPUT -p tcp -j ACCEPT --dport 443 -m conntrack --ctstate NEW | iptables -A INPUT -p tcp -j ACCEPT --dport 443 -m conntrack --ctstate NEW | ||
Revision as of 13:20, 26 March 2026
Packet filtering affords opening access only to these services you have decided to open. The TCP or UDP packets include a piece of information called the port number, that is used to identify the type of service. Secure ports were defined as SSL counterparts of the native ports but were superseded by TLS and are now deprecated due to security weaknesses in the SSL protocol. SSL should not be used any longer. Instead, use TLS. Current version is v1.2.
| Protocol | Port # | Secure Protocol | Secure Port # | Service |
|---|---|---|---|---|
| SMTP | 25 | SMTPS | 465 | Mail exchange |
| HTTP | 80 | HTTPS | 443 | Web browsing |
| POP3 | 110 | POP3S | 995 | Mail retrieval |
| NTTP | 119 | NTTPS | 563 | News exchange |
| IMAP | 143 | IMAPS | 993 | Mail retrieval |
| LDAP | 389 | LDAPS | 636 | Ldap Directory |
On server side, the services are provided by applications that may have vulnerabilities and be attacked. Examples of attacks are buffer overflow or format string attacks, that afford getting full access on the target machine by crafting special strings sent to it. An attacker could then obtain any information present there or modify or destroy the system.
To reduce the number of possible attacks, the number of services authorized, or who can access the system, must be restricted. This is known as packet filtering. It is only an aspect of security (obviously, the applications on the server side must also be secured ...), but it is important. Never *** ever *** connect to the network a computer not protected by a packet filter !
To illustrate, let's configure our two-interfaces computer to be its own firewall. eth0 is the Internet interface, it uses network 192.168.0.x, the gateway is an ADSL router/switch at 192.168.0.254. eth1 is the (Intranet) interface to the internal network 192.168.1.x.
Iptables Filtering
Since Linux 2.4, packet filtering is effected inside the kernel, and configuration effected by the iptables user-space program. In addition to rules for incoming and outgoing packets, iptables affords defining rules for routing between the interfaces. The iptables command affords entering the rules one by one. Using a script affords entering all the rules. iptable -L -v affords viewing the current rules.
For more information, see the netfilter official site. This site has links to various documents, including a simple introduction to packet filtering in this HOWTO.
In Slackware, the script used is /etc/rc.d/rc.firewall. It is called automatically when the system starts or stops, using commands ./rc.firewall start or ./rc.firewall stop.
#! /bin/sh
#
# startup script for local packet filter
#
fw_start () {
echo "Loading packet filter rules"
The flush command affords deleting all the active nat and filtering rules:
# flush old rules iptables -t nat --flush iptables -flush
The -P option affords defining the default policy. A good practise is to forbid by default everything not authorized. This is done here for packets incoming, outgoing, and routed between the interfaces:
# drop by default iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP
Connections already established are authorized to continue:
# accept packets that are part of previously OK'ed sessions iptables -A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED iptables -A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED iptables -A FORWARD -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
The -A option affords adding a rule. Here all the packets on the loopback interface are accepted:
# INBOUND POLICY # pass all traffic for network 127.0.0.0/8 on loopback interface iptables -A INPUT -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
Addresses of RFC 1918 private networks are not routable on the Internet. So packets with such addresses are not expected on the internal network. However as anti-spoofing is ensured by Internet box we do not need to introduce anti-spoofing rules here:
# anti-spoofing done by Internet box so not needed here # iptables -A INPUT -s 10.0.0.0/8 -j LOG --log-prefix "INPUT spoofed IP " # iptables -A INPUT -s 10.0.0.0/8 -j DROP # . . .
The protocols corresponding to services offered or used externally are accepted:
# services SMTP HTTP HTTPS # iptables -A INPUT -p tcp -j ACCEPT --dport 25 -m conntrack --ctstate NEW iptables -A INPUT -p tcp -j ACCEPT --dport 80 -m conntrack --ctstate NEW # iptables -A INPUT -p tcp -j ACCEPT --dport 143 -m conntrack --ctstate NEW iptables -A INPUT -p tcp -j ACCEPT --dport 443 -m conntrack --ctstate NEW
The protocols corresponding to services offered on the local network are accepted:
# services on local network FTP DNS BOOTP NNTP SUBMIT VNC SIP RTP iptables -A INPUT -p tcp -j ACCEPT --dport 20 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 21 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p udp -j ACCEPT --dport 53 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 53 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p udp -j ACCEPT --dport 69 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 119 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 587 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 5900:5912 -m conntrack --ctstate NEW -s 192.168.53.0/24
We accept X-Window traffic on the local network:
# SSH-tunnelled X-Window output appears as input on interface lo iptables -A INPUT -p udp -j ACCEPT --dport 177 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 6000:6063 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -i lo -p tcp -j ACCEPT --dport 6000:6063 -m conntrack --ctstate NEW -s 192.168.53.0/24
We accept NFS on the local network and fix the NFS ports:
# NFS ports iptables -A INPUT -p udp -j ACCEPT --dport 111 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 111 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p udp -j ACCEPT --dport 2049 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 2049 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p udp -j ACCEPT --dport 32764:32769 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 32764:32769 -m conntrack --ctstate NEW -s 192.168.53.0/24
We accept samba traffic on the local network:
# samba ports iptables -A INPUT -p udp -j ACCEPT --dport 135 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 135 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p udp -j ACCEPT --dport 137 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 137 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p udp -j ACCEPT --dport 138 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 139 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p udp -j ACCEPT --dport 445 -m conntrack --ctstate NEW -s 192.168.53.0/24 iptables -A INPUT -p tcp -j ACCEPT --dport 445 -m conntrack --ctstate NEW -s 192.168.53.0/24
Broadcast traffic is also OK:
# broadcast traffic iptables -A INPUT -p udp -s 0.0.0.0 -sport 67:68 -d 255.255.255.255 -j ACCEPT
We accept pings on the local network:
# accept some icmp packets iptables -A INPUT -p icmp --icmp-type echo-request -s 192.168.53.0/24 -j ACCEPT iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
We could log anything not accepted above:
# log anything not accepted above # iptables -A INPUT -j LOG --log-prefix "INPUT bad traffic "
We accept all outbound packets, which would for example afford using a network scanner. In a production environment, there would be a stricter policy:
# OUTBOUND POLICY # accept all outbound packets iptables -A OUTPUT -j ACCEPT }
After the fw_start() function ends, the fw_stop() function is defined to authorize everything:
fw_stop () {
echo "Unloading all packet filter rules"
iptables -t nat --flush
iptables -flush
# accept by default
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
}
case "$1" in
‘start’)
fw_start
;;
’stop’)
fw_stop
;;
’restart’)
fw_start
;;
*)
echo "usage $0 start | stop | restart"
Testing the firewall
Use nmap -sU hostname (UDP) and nmap -sT hostname (TCP) to make sure what ports are visible locally and do the same from the outside.
Download example
| Configuration files | Main Page | X11 configuration |