HOWTO Setup iptables: Difference between revisions

From Research
Jump to navigation Jump to search
No edit summary
 
 
(31 intermediate revisions by the same user not shown)
Line 1: Line 1:
#! /bin/sh
==Kernel Configuration==
# /etc/iptables.bak
NOTE This configuration is for basic firewalling only; we don't do NAT/packet-forwarding... so, if you're reading this, and wish to use NAT/forwarding, you will be missing a few key configuration items :-O
    Typical kernel 2.6.25 and higher kernel options for our firewalling:
   
   
  # Let's save typing & confusion with variables
  Networking  ---->
  IPTABLES=/sbin/iptables
  Networking options  ---->
  Network packet filtering framework (Netfilter)--->
    Core Netfilter Configuration ---->
    <*> Netfilter connection tracking support
    <*>  Amanda backup protocol support
    -*- Netfilter Xtables support (required for ip_tables)
    <*>  "limit" match support
    <*>  "multiport" Multiple port match support
    <*>  "state" match support
    IP: Netfilter Configuration --->
    <*> IPv4 connection tracking support (required for NAT)
    <*> IP tables support (required for filtering/masq/NAT)
    <*>  Packet filtering
    <*>    REJECT target support
 
==Iptables Installation==
<font color=red>hostname</font> <font color=blue>~ #</font> '''emerge iptables'''
<font color=red>hostname</font> <font color=blue>~ #</font> '''rc-update add iptables default'''
Usually, when you try to start a new installation of iptables, you get an error, sometimes like this:
  <font color=red>hostname</font> <font color=blue>~ #</font> '''/etc/init.d/iptables start'''
<font color=red>*</font> Not starting iptables.  First create some rules then run:
<font color=red>*</font> /etc/init.d/iptables save
Or, you may see this kind of error:
FATAL: Module ip_tables not found.
iptables v1.3.8: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
Occasionally, there are complaints about "mangle"... it may be that there is some previous ruleset which included NAT/forwarding.  For our application, we do not need mangling-capability!<br>In any of the above startup cases, we will manually start iptables (that is, '''not''' using the init-script), and give it a very-simple command-line rule, just to get iptables going:
  <font color=red>hostname</font> <font color=blue>~ #</font> '''/sbin/iptables -A INPUT -i lo -j ACCEPT'''
This usually (should!) result in very simple, default "all-pass" ruleset, which doesn't actually do anything except keep the init-scripts happy:
<font color=red>hostname</font> <font color=blue>~ #</font> '''iptables -L'''
Chain INPUT (policy ACCEPT)
target    prot opt source              destination
ACCEPT    all  --  anywhere            anywhere
   
   
  # Flush active rules and custom tables
  Chain FORWARD (policy ACCEPT)
  $IPTABLES --flush
  target    prot opt source              destination
$IPTABLES --delete-chain
   
   
  # set the defaults so that by-default incoming packets are dropped, unless explicitly allowed;
  Chain OUTPUT (policy ACCEPT)
  # for a desktop workstation, we'll let lots of (unpredictable) outgoing packets go freely.
target    prot opt source              destination
  $IPTABLES -P INPUT DROP
We then use the init-script to '''save''' our ruleset, which will at least then allow iptables to start properly the next time with the init-scripts:
  $IPTABLES -P FORWARD DROP
<font color=red>hostname</font> <font color=blue>~ #</font> '''/etc/init.d/iptables save'''
  $IPTABLES -P OUTPUT ACCEPT
<font color=lime>*</font> Saving iptables state ...
   
 
  # INBOUND POLICY
===Creating iptables Rulesets===
  # ==============
It's a great starting-point for ruleset development to see what ports are currently in-use, and consider that these may need to be opened through our firewall.  To see what ports are in-use, and by what programs/services:
  # of course, accepting loopback is a good idea
<font color=red>hostname</font> <font color=blue>~ #</font> '''netstat -alnp'''
  $IPTABLES -A INPUT -i lo -j ACCEPT
<br>
   
On a complex server, there can be many unfamiliar ports open, and some may vary with each invocation of the associated program :-(  Google around, and first see if you can identify all the services.  Secondly, see if you can nail down these services to always use a known/specific port.
#  (Applies to packets entering our network interface from the network,
<br>
#  and addressed to this host.)
In a worst-case scenario, you may decide it's too scary to actually begin blocking ports and breaking services to users - this can work OK with fail2ban! You will gain some protection against dictionary-attacks, which is better than you had a moment ago (see Example 1).<br>
<hr>
  $IPTABLES -A INPUT -m state --state INVALID -j DROP
[[example_simple_iptable_ruleset|Example 1 - very-basic /etc/iptables.bak to prevent breaking extensive/weird/complex services]]
  $IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
 
[[example_webserver_iptable_ruleset|Example 2 - /etc/iptables.bak for a web-server with vsftpd upload, also SSH connectivity, and being monitored by nagios]]
# ftp incoming
 
  $IPTABLES -A INPUT -p tcp -m state --state NEW --dport 20 -j ACCEPT
[[example_webserver_nfs_keyserver_iptable_ruleset|Example 3 - /etc/iptables.bak for a web-server with both http and https, nfs-client, amanda-tape-backup-client, SSH connectivity, a Sassafrass keyserver, a flexlm license-server, and monitoring by nagios]]
  $IPTABLES -A INPUT -p tcp -m state --state NEW --dport 21 -j ACCEPT
 
   
[[example_ldap_samba_iptable_ruleset|Example 4 - /etc/iptables.bak for samba-server, LDAP, amanda-tape-backup-client, SSH connectivity, and monitoring by nagios]]
# ssh incoming, including non-standard port (if needed)
 
  $IPTABLES -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
[[example_svnserve_nfsserve_iptable_ruleset|Example 5 - /etc/iptables.bak for SVN-server, NFS-server, amanda-tape-backup-client, SSH connectivity, and monitoring by nagios]]
  #$IPTABLES -A INPUT -p tcp -m state --state NEW --dport 222 -j ACCEPT
<hr>
   
 
# web serving, let's allow it!
==Scripting the Rules==
  $IPTABLES -A INPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT
Once '''''iptables''''' is up-and-running, simply execute one of the scripts above, to implement your choice of working-policies,  Or, use these scripts above as a basis for your own similar-but-custom rulesets, which Google can help you with.  Our standard is to save the ruleset-script as '''''/etc/iptables.bak'''''.  So, once iptables is running (in very-basic-form), invoking the ruleset-script is very simple:
   
<font color=red>hostname</font> <font color=blue>~ #</font> '''sh /etc/iptables.bak'''
  # nagios (5666); monitor time (123), allow snmp (161)
 
  $IPTABLES -A INPUT -p tcp -m state --state NEW --dport 5666 -j ACCEPT
Save the configuration:
  $IPTABLES -A INPUT -p udp -m state --state NEW --dport 123 -j ACCEPT
  <font color=red>hostname</font> <font color=blue>~ #</font> '''etc/init.d/iptables save'''
  $IPTABLES -A INPUT -p udp -m state --state NEW --dport 161 -j ACCEPT
 
   
...then ack up your known-working configuration in case you break something later you can quickly revert:
  <font color=red>hostname</font> <font color=blue>~ #</font> '''cp /var/lib/iptables/rules-save /var/lib/iptables/rules.working'''
# OUTBOUND POLICY
 
# ===============
View and check the active ruleset:
# of course, accepting loopback is a good idea
  <font color=red>hostname</font> <font color=blue>~ #</font> '''iptables -L'''
$IPTABLES -A OUTPUT -o lo -j ACCEPT
 
   
==Manually Working With Rules==
#  (Applies to packets sent to the network interface from local processes)
You may wish to manually block some bad guy who is trying to access your SSH service (in this example). You can add lines like these to '''/etc/iptables.bak''' ''(of course, substitute the bad-guy's IP-address)'':
  # Manually added blocking-rules, often from watching log-output:                                                                                     
$IPTABLES -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  # =============================================================                                                                                     
  #awk '($(NF-7) = /invalid user/){print $(NF-3)}' /var/log/messages | sort | uniq -c | sort                                                           
  iptables -I INPUT -p tcp -s 83.103.96.33 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 41.206.41.90 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 87.139.25.251 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 200.171.229.109 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 217.91.80.206 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 61.74.75.56 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 80.169.105.159 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 62.96.29.34 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 190.146.246.36 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 195.202.52.155 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 80.153.59.28  --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 82.106.226.77 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 194.51.12.238 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 61.74.75.43 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 113.105.82.13 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 211.115.234.143 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 92.79.128.167 --dport ssh -j REJECT --reject-with tcp-reset
  iptables -I INPUT -p tcp -s 58.247.222.163 --dport ssh -j REJECT --reject-with tcp-reset

Latest revision as of 17:11, 29 July 2010

Kernel Configuration

NOTE This configuration is for basic firewalling only; we don't do NAT/packet-forwarding... so, if you're reading this, and wish to use NAT/forwarding, you will be missing a few key configuration items :-O 

   Typical kernel 2.6.25 and higher kernel options for our firewalling:

Networking  ---->
 Networking options  ---->
  Network packet filtering framework (Netfilter)--->
   Core Netfilter Configuration ---->
    <*> Netfilter connection tracking support
    <*>   Amanda backup protocol support
    -*- Netfilter Xtables support (required for ip_tables)
    <*>   "limit" match support
    <*>   "multiport" Multiple port match support
    <*>   "state" match support
   IP: Netfilter Configuration --->
    <*> IPv4 connection tracking support (required for NAT)
    <*> IP tables support (required for filtering/masq/NAT)
    <*>   Packet filtering
    <*>     REJECT target support

Iptables Installation

hostname ~ # emerge iptables
hostname ~ # rc-update add iptables default

Usually, when you try to start a new installation of iptables, you get an error, sometimes like this: 

 hostname ~ # /etc/init.d/iptables start
* Not starting iptables.  First create some rules then run:
* /etc/init.d/iptables save

Or, you may see this kind of error: 

FATAL: Module ip_tables not found.
iptables v1.3.8: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Occasionally, there are complaints about "mangle"... it may be that there is some previous ruleset which included NAT/forwarding. For our application, we do not need mangling-capability!
In any of the above startup cases, we will manually start iptables (that is, not using the init-script), and give it a very-simple command-line rule, just to get iptables going: 

hostname ~ # /sbin/iptables -A INPUT -i lo -j ACCEPT

This usually (should!) result in very simple, default "all-pass" ruleset, which doesn't actually do anything except keep the init-scripts happy: 

hostname ~ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

We then use the init-script to save our ruleset, which will at least then allow iptables to start properly the next time with the init-scripts: 

hostname ~ # /etc/init.d/iptables save
* Saving iptables state ...

Creating iptables Rulesets

It's a great starting-point for ruleset development to see what ports are currently in-use, and consider that these may need to be opened through our firewall. To see what ports are in-use, and by what programs/services: 

hostname ~ # netstat -alnp


On a complex server, there can be many unfamiliar ports open, and some may vary with each invocation of the associated program :-( Google around, and first see if you can identify all the services. Secondly, see if you can nail down these services to always use a known/specific port.
In a worst-case scenario, you may decide it's too scary to actually begin blocking ports and breaking services to users - this can work OK with fail2ban! You will gain some protection against dictionary-attacks, which is better than you had a moment ago (see Example 1).

Example 1 - very-basic /etc/iptables.bak to prevent breaking extensive/weird/complex services

Example 2 - /etc/iptables.bak for a web-server with vsftpd upload, also SSH connectivity, and being monitored by nagios

Example 3 - /etc/iptables.bak for a web-server with both http and https, nfs-client, amanda-tape-backup-client, SSH connectivity, a Sassafrass keyserver, a flexlm license-server, and monitoring by nagios

Example 4 - /etc/iptables.bak for samba-server, LDAP, amanda-tape-backup-client, SSH connectivity, and monitoring by nagios

Example 5 - /etc/iptables.bak for SVN-server, NFS-server, amanda-tape-backup-client, SSH connectivity, and monitoring by nagios

Scripting the Rules

Once iptables is up-and-running, simply execute one of the scripts above, to implement your choice of working-policies, Or, use these scripts above as a basis for your own similar-but-custom rulesets, which Google can help you with. Our standard is to save the ruleset-script as /etc/iptables.bak. So, once iptables is running (in very-basic-form), invoking the ruleset-script is very simple: 

hostname ~ # sh /etc/iptables.bak

Save the configuration: 

hostname ~ # etc/init.d/iptables save

...then ack up your known-working configuration in case you break something later you can quickly revert: 

hostname ~ # cp /var/lib/iptables/rules-save /var/lib/iptables/rules.working

View and check the active ruleset: 

hostname ~ # iptables -L

Manually Working With Rules

You may wish to manually block some bad guy who is trying to access your SSH service (in this example). You can add lines like these to /etc/iptables.bak (of course, substitute the bad-guy's IP-address): 

# Manually added blocking-rules, often from watching log-output:                                                                                       
# =============================================================                                                                                      
#awk '($(NF-7) = /invalid user/){print $(NF-3)}' /var/log/messages | sort | uniq -c | sort                                                             
iptables -I INPUT -p tcp -s 83.103.96.33 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 41.206.41.90 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 87.139.25.251 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 200.171.229.109 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 217.91.80.206 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 61.74.75.56 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 80.169.105.159 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 62.96.29.34 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 190.146.246.36 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 195.202.52.155 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 80.153.59.28  --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 82.106.226.77  --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 194.51.12.238 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 61.74.75.43 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 113.105.82.13 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 211.115.234.143 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 92.79.128.167 --dport ssh -j REJECT --reject-with tcp-reset
iptables -I INPUT -p tcp -s 58.247.222.163 --dport ssh -j REJECT --reject-with tcp-reset
Retrieved from "https://research.iat.sfu.ca/research/index.php?title=HOWTO_Setup_iptables&oldid=5169"