Amazon iptables Manual & Tutorial

Brand: Amazon

Model: iptables

Category: Software

Type: Manual & Tutorial

An iptables guide & tutorial - iptablesrocks.org

Welcome to Iptablesrocks.org

Welcome to iptablesrocks.org! Iptablesrocks was created to provide a publicly available, easy to understand guide and tutorial for the installation and

configuration of iptables. Iptables is a linux package for managing IPv4 (and optionally IPv6) packet filtering and NAT (Network Address Translation).

Iptables can be configured to function as a firewall, a NAT mechanism, a packet filter or all 3 at once. The diversity of capabilities possible with iptables

makes it a secure, stable and economical alterative to hardware based firewalls and routers or costly 3rd party firewall software. Iptables can also

serve as a rendundant firewall in conjunction with a hardware firewall, providing you with an extra layer of security. Iptablesrocks.org covers the

installation of iptables in a Redhat environment, the syntax and structure associated with iptables and a collection a pre-configured iptables

configurations for a variety of applications. This site is currently under development. Enjoy!

The iptablesrocks.org iptables firewall setup guide Quick links to need specific iptables configurations

An overview of the iptablesrocks firewall

Step 1:

System requirements & Pre-configuration

Step 2: Deploying a safety net.

Step 3: The iptables firewall ruleset

Step 4: Testing functionality

Step 5: Installing Iptables Log Analyzer

Step 6: Maintaining & modifying your firewall and starting it on boot

Step 7: Feedback

general web server firewall

linux gateway w/DSL connection

linux gateway w/Cable connection

sever to server trusted connections

A word of advise: Before you make any changes to your iptables configuration, you should read about

pre-configuration precautions!

2666

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/ [2/13/2004 8:04:42 PM]

Iptablesrocks.org - Syntax & Structure

Syntax & Structure

The iptables manual page is the best resource for learning all of the possible syntax options for iptables:

iptables man page

An iptables syntax quick reference

Taking a look at what you have

iptables -L [chain] - Lists your current iptables configuration

Making modifications

iptables -A [chain] - Append a rule to a desired chain in the current configuration

iptables -D [chain] - Delete a rule from a desired chain in the current configuration

iptables -R [chain] - Replace an existing rule from a desired chain in the current configuration

iptables - I [chain] - (that's a capital I as in Insert) Insert a new rule into a desired chain of the current configuration

iptables -N [chain]

- Create a new chain

iptables -X [chain] - Delete a chain

Getting rid of all rules and starting over

iptable -X - Delete all chains

iptables -F - Flush the table of all contents

Importing & Exporting

iptables-save > filename - exports the current iptables configuration to a flat file.

iptables-restore < filename - imports an iptables configuration from a flat file and overwrites the current configuration.

More syntax & structure information coming soon!

http://www.iptablesrocks.org/syntax/ (1 of 2) [2/13/2004 8:04:43 PM]

Iptablesrocks.org - Syntax & Structure

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/syntax/ (2 of 2) [2/13/2004 8:04:43 PM]

Iptablesrocks.org - Examples

Iptables Ruleset Examples

This page contains already configured examples of several types of iptables configurations for a variety of different purposes. Feel free to use them as

is or make any needed adjustments to suit your particular needs.

A word of caution: Before you make any changes to your iptables configuration, you should read about

pre-configuration precautions!

Example 1 - iptables setup for a full service web server

Summary: A hearty iptables configuration geared for web servers running web services (http and https), mail services, mysql, ftp services

and dns services.

When running a typical web server, you need a firewall that is secure and offers protection, but you also need one that allows all needed traffic to be

able to enter and leave the server so that your server's day to day operations can carry on unimpeded. This particular iptables configuration does the

following:

1. Uses the "mangle" portion of the table to effectively block and/or confuse most port scans. These rules deal address FIN,SYN,RST,PSH,ACK,URG

FIN,PSH and URG methods.

2. Establishes a locked down and secure foundation by initially blocking all incoming, outgoing and forwarded packets COMPLETELY.

3. With all incoming packets dropped by default, it then grants incoming access to a select number of ports. These ports are ports that a typical web

server might allow.

Open inbound ports include: 20 & 21 (ftp), 22 (ssh), 25 (smtp), 53 (dns), 80 (http), 110 (pop), 143 (imap), 443 (https), 993 (imaps)

4. With all outbound packets dropped by default, it then grants outbound access to a select number of ports. These ports are posts that a typical web

server might allow.

Open outbound ports include: 20 & 21 (ftp), 22 (ssh), 25 (smtp), 43 (whois), 53 (dns), 80 (http), 110 (pop), 143 (imap), 443 (https), 993 (imaps)

5. Both inbound and outbound connections are required to be in a "related and established" state. The "related and established" state requirement will

require you to add the "ip_conntrack_ftp" module into your server's configuration. This is typically done with the following command:

insmod ip_conntrack_ftp

6. ICMP packet types 3, 8 and 11 are dropped by default for all inbound traffic. This makes your server unpingable and reduces the chance of ping

ICMP based attacks. Pings are allowed for all outbound traffic.

7. Unauthorized inbound and outbound traffic is logged.

Example 2 - iptables setup for linux gateway on DSL connection

Example 3- iptables setup for linux gateway on a cable internet connection

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/examples/ (1 of 2) [2/13/2004 8:04:44 PM]

Iptablesrocks.org - Examples

http://www.iptablesrocks.org/examples/ (2 of 2) [2/13/2004 8:04:44 PM]

iptablesrocks.org - FAQ

Frequently Asked Questions

● How can I view my current iptables ruleset?

● How do I import an iptables script into my server's iptables ruleset?

● How do I export my server's iptables rulset to flat iptables script?

● How can I open up a port on my firewall?

● How can I close a port on my firewall?

● How can I completely block a host from reaching my server?

● How can I block a host from a specific port on my server, while allowing access to all other ports?

● How can I make mty firewall start up automatically when my server is booted?

● I've installed the iptablesrocks.org firewall and it's working, but now I cannot telnet to my server! What's wrong?

● I've already installed the Qmailrocks.org qmail install on my server. How should my iptables firewall config look?

Q: How can I view my current iptables ruleset?

A: The command "iptables -L" will display your server's current iptables ruleset.

Q: How do I import an iptables script into my server's iptables ruleset?

A: The command "iptables-restore < /path/to/firewall_script" will import a flat file iptables script into the server's ruleset.

Q: How do I export my server's iptables rulset to flat iptables script?

A: The command "iptables-save > /path/to/firewall_script" will export the current iptables ruleset to a flat file called "firewall_script".

Q: I've installed the iptablesrocks.org firewall and it's working, but now I cannot telnet to my server! What's wrong?

A: The iptablesrocks.org firewall does not allow telnet connections on port 23 by default. Whty? Simple. Telnet is dumb and totally insecure. Don't use

it. If you've been using telnet in the past to connect to your server, it's time to grow up and start using SSH instead. However, if you insist on using

telnet, you can simply

add a rule to your firewall script to allow connections on port 23 (telnet).

Q: I've already installed the Qmailrocks.org qmail install on my server. How should my iptables firewall config look?

A: If you've installed qmail according to

qmailrocks.org, the default iptablesrocks firewall configuration should work just fine with one exception. You

will want to

add a rule to open port 783 both on the INPUT and OUTPUT chains so that Spamassassin can work.

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/faq/ [2/13/2004 8:04:44 PM]

Iptablesrocks.org - Contact

Contact Iptablesrocks.org

If you would like to contact me, please fill out the form below and then click "Send It!".

Your name:

Your e-mail:

Comments/Questions:

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/contact/ [2/13/2004 8:04:45 PM]

Iptablesrocks.org - Links

Links

A collection of useful links.

The Netfilter/Iptables Project -

http://www.netfilter.org/

Linuxguruz Iptables Tutorial - http://www.linuxguruz.com/iptables/howto/iptables-HOWTO.html

Qmailrocks.org - My qmail installation guide

Djbdnsrocks.org - My djbdns installation guide

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/links/ [2/13/2004 8:04:45 PM]

iptablesrocks.org - Maintaining, modifying and more...

The iptablesrocks.org iptables firewall setup guide

Maintaining & modifying your firewall and starting it on boot:

Maintenance

Maintaining your iptables firewall is pretty easy. The only thing you will want to keep an eye on is the logs at /var/log/firewall. The logs can let you know

when your server is being probed or when an attack is being attempted, this allowing you to take appropriate action. Once you start viewing your logs,

you are going to notice that almost every hour of every day someone is going to be trying to gain access to your server, find an exploit on your server

or attack your server. This is normal. Attackers simply scan entire networks for vulnerable servers, so don't take scans and attempted intrusions

personally. Every publicly available server out there gets probed and scanned all the time, so don't think you are special and that you need to call the

FBI or something rash like that. The fact is that anytime your see unsuccessful attempts to break into your server or attack it, that's a good thing

because it means that the attackers were not able to succeed. It means your server is secure and your firewall is working. In other words, failures that

are logged are a sign of a secure server.

You may also want to make sure that you have a log rotation schedule set up for the firewall logs. The logs can get quite large, so you will want to

keep them in check by rotating them out on a regular basis.

Modifications

OK, so you've got your firewall up and running. But what if you need to make a change to the rules? What if you need to open up another port? What if

you want to close a certain unused port? What if you want to block someone from your server? Get the answers right here.

What if I want to open another port?

While it is possible to append rules to your live iptables configuration, I find that the best way to make changes is to change the firewall script itself and

then re-import the script back into the iptables configuration. In terms of this site's setup, this means that you will want to edit the /root/primary_firewall

file. Within this config file you can add rules or remove rules and then import the new firewall into the iptables ruleset.

So, let's take an example

Example: I want to allow inbound "tcp" traffic to port 139

To do this you would add the following line to the "INPUT" section of the /root/primary_firewall script:

-A INPUT -p tcp -m tcp --dport 139 -j ACCEPT

Let's go over what this line does...

-A - this tells iptables to "append" the new rule to the current iptables ruleset.

INPUT - The new rule will be appended to the "INPUT" portion of the ruleset, which controls inbound server traffic.

-p - Indicates what protocol the rule applies to. Popular protocols are "tcp", "udp", "icmp" and several others.

-m - Indicates a matching protocal value. Usually, this is set to the same value as the -p flag.

--dport - Specifies the destination port to which the traffic will be directed. In this case, it's port 139.

-j - Instructs the firewall to "jump" to specified state. In this case, request to TCP port 139 "jump" to "ACCEPT" and are threfore accepted and allowed

to pass through the firewall.

ACCEPT - As denoted above, this is the state that the rule "jumps" to. In the example above, any inbound traffic to TCP port 139 will "jump" to an

"ACCEPT" state, and thus will be able to pass through the firewall.

So the breakdown above should tell you that the rule we are adding is going to allow all inbound traffic to TCP port 139. Once you add that line to the

http://www.iptablesrocks.org/guide/maintain.php (1 of 3) [2/13/2004 8:04:47 PM]

iptablesrocks.org - Maintaining, modifying and more...

"INPUT" section of the firewall script, you can then import the new firewall with the following command:

iptables-restore < /root/primary_firewall

Wow, now wasn't that easy?

What if I want to close a port?

The answer to this is similar to the previous question. However, you need to remember that your firewall, as it stands now, automatically blocks ALL

inbound, outbound and fowarded traffic by default. The only way that a port gets opened is if there is a rule telling the firewall to open that port.

Let's take an example...

Example: I was to close TCP port 143 inbound.

In the firewall script that comes with this guide, you will notice the following entry that open up inbound traffic to TCP port 143 (For IMAP). That rule

looks like this:

-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT

Well, if you wanted to close port 143, all you would have to do is edit the firewall script at /root/primary_firewall and remove that line. Once the line is

gone and you've saved the changes, you would activate the change by re-importing the firewall script back into the iptables ruleset like so

:iptables-restore < /root/primary_firewall

Now wasn't that easy?

Now, let's take another example so that I can demonstrate something that you DON'T need to worry about.

Example: I want to block all inbound traffic to TCP port 3389.

Again, let's take the firewall that comes with this guide. All of the sudden you get it in your head that you need to close TCP port 3389. What to do?

Well, if you take a look at the firewall script you will notice that TCP port 3389 is not mentioned anywhere in the script and, to be more specific, it is not

mentioned in the "INPUT" portion of the script. Well, since our firewall is configured to block ALL traffic by default and only open ports on request, 3389

is ALREADY CLOSED. In other words, you don't need to worry about that port because it has been automatically closed by the firewall. The only way

it would be open is if you created a specific rule that rquested that the port be open. Get it?

What if I want to completely block someone from my server?

The procedure for this is just the same as the ones above. Basically, all you're going to do is edit the firewall script, add a rule to block whoever, save

the changes and then re-import the firewall script back into the server's ruleset. Easy as hell.

So let's take an example:

Example: I want to block anyone from the host 1.2.3.4 from accessing my server.

Open the /root/primary_firewall script and add the following line to the INPUT section of the script:

-A INPUT -s 1.2.3.4 -j DROP

Now let's break that down to see what this rule is doing..

-A - this tells iptables to "append" the new rule to the current iptables ruleset.

INPUT - The new rule will be appended to the "INPUT" portion of the ruleset, which controls inbound server traffic.

-s - Specifies the source address of the request. In this case we are specifying 1.2.3.4 as the source.

-j - Instructs the firewall to "jump" to specified state. In this case, request coming from source 1.2.3.4 "jump" to a DENY state, thus blocking anyone

from that addresss from accessing your server at all.

http://www.iptablesrocks.org/guide/maintain.php (2 of 3) [2/13/2004 8:04:47 PM]

iptablesrocks.org - Maintaining, modifying and more...

DROP - As denoted above, this is the state that the rule "jumps" to. In the example above, any traffic to coming from 1.2.3.4 will "jump" to an "DROP"

state, and thus will be blocked.

What if I only want to block someone from accessing a certain port, while allowing them to access all others?

This would just be a more specific version of the above rule. In this case, you would specify the destination port and the protocal type with the "-p", "-

m" and "--dport" flags. If you wanted to block anyone from 1.2.3.4 from accessing port 25 on your server, it would look like this:

-A INPUT -s 1.2.3.4 -p tcp -m tcp --dport 25 -j DROP

Easy enough, right?

The previous questions are only a sampling of the many, many modifications and customizations that can be made to your firewall. Check out the

iptables man page (man iptables) for the whole gamut.

As I said before, always make sure you enable your iptables "safetynet" before you start playing with your firewall setup. You don't want to accdientally

lock yourself out of your server!

Starting your fiewall on boot

The final part of this setup guide will cover the integration of your firewall into the server's boot process. If you would like your firewall to start on boot

and work correctly, you will want to do the following:

cp /root/primary_firewall /etc/sysconfig/iptables

This will cause your iptables config script to be loaded at boot time.The last step is to make sure that the "ip_conntrack_ftp" kernel module

loads on boot as well to ensure correct FTP functionality.

vi /etc/rc.local

add the following line:

/sbin/insmod ip_conntrack_ftp

Save and exit the file.

That's it! You're all done. Enjoy your new firewall! Please take a moment to go to the next page and provide me with some feedback and/or

commentary.

Proceed to the next step

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/guide/maintain.php (3 of 3) [2/13/2004 8:04:47 PM]

iptablesrocks.org - Feedback

The iptablesrocks.org iptables firewall setup guide

Feedback:

Now that you've finished the iptablesrocks.org iptables setup guide, please provide me with some feedback.

What do you think of the setup guide? It stinks! Not very good It was ok Very helpful Excellent

Your Name:

(required)

Your E-mail:

(required)

Any comments/suggestions?

May we post your comments on this website?

Yes No

(your name & e-mail address will not be posted)

A note on privacy: Some people worry about providing their e-mail address on the form. You don't need to worry. The only

reason I require your e-mail address is so that I can personally reply to any questions or comments you may have. I won't put

your e-mail address on any list or anything like that. I'm hate spam just as much as you do. :)

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/guide/feedback.php [2/13/2004 8:04:47 PM]

iptablesrocks.org - safety precautions

iptables pre-configuration safety precautions

Making changes to your server's firewall/routing configuration can be very tricky. One simple mistake can result in your being completely locked out of

your server. If the server you are working on is remotely hosted, this can cause prolonged downtime and a tech support nightmare. In short, it can be a

major pain in the ass.

For this reason, anytime you are making changes to your server's firewall or routing config via iptables, you should first take a few minutes to

implement some "disaster recovery" measures that can be automatically triggered should you accidentally lock yourself out of your server.

Whenver I'm making any major changes to my firewall, I like to implement a "disaster recovery" measure by means of a crontab entry. I do this by

creating a simple crontab entry that runs every 15 minutes or so. This crontab entry runs a command which simply resets my server's iptables

configuration to a completely open setting. That is, it sets my iptables configuration so that the server will accept all incoming, outgoing and forward

requests. In this way, should I screw up at some point and lock myself out of my server, I will only need to wait a maximum of 10 minutes before the

bad firewall rules will be dropped and I'll be able to shell into my server again. If you are a newbie at iptables, or even a seasoned pro, this little safety

measure can be a lifesaver. Everyone makes mistakes every now and then, and this measure will ensure that a mistake made in your firewall

configuration doesn't turn into a nightmare!

So here's how you do it....

Log into your server as the root user.

First, create a iptables import script that, when imported, will reset the iptables configuration to a default "accept all" state:

vi /root/iptables.open

*filter

:INPUT ACCEPT [164:15203]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [147:63028]

COMMIT

*mangle

:PREROUTING ACCEPT [164:15203]

:INPUT ACCEPT [164:15203]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [147:63028]

:POSTROUTING ACCEPT [147:63028]

COMMIT

*nat

:PREROUTING ACCEPT [14:672]

:POSTROUTING ACCEPT [9:684]

:OUTPUT ACCEPT [9:684]

COMMIT

Now save and exit.

Now let's set up a crontab entry that will import the reset configuration every 15 minutes...

crontab -e

*/15 * * * * /sbin/iptables-restore < /root/iptables.open

Save and exit from the crontab editor

Ok. All done.

Now let's review what this is going to do to your server...

Once you enable the crontab, your server is going to reset it's iptables configuration every 15 minutes. This means that every 15 minutes you will lose

http://www.iptablesrocks.org/precautions.php (1 of 2) [2/13/2004 8:04:48 PM]

iptablesrocks.org - safety precautions

any previous settings and you server will be in a "accept all" state where it accepts any incoming, outgoing and forward packet requests. You certainly

do not want to leave this crontab running if you are not actively working on your iptables configuration. The sole of this crontab is to provide a safety

net should you accidentally screw up and lock yourself out of your server while you are implementing or testing new iptables configurations. With this

crontab running, should you lock yourself out you will only have to wait a maximum of 15 minutes before the iptables configuration resets and you are

able to log into your server again.

You should always disable this crontab entry once you are finished modifying your iptables configuration.

Site last modified: February 13, 2004 15:27:51

http://www.iptablesrocks.org/precautions.php (2 of 2) [2/13/2004 8:04:48 PM]

http://www.iptablesrocks.org/examples/scripts/web_server.config

# import this saved configuration into your iptables configuration with the following command:

# iptables-restore < web_server.config

*nat

:PREROUTING ACCEPT [127173:7033011]

:POSTROUTING ACCEPT [31583:2332178]

:OUTPUT ACCEPT [32021:2375633]

COMMIT

*mangle

:PREROUTING ACCEPT [444:43563]

:INPUT ACCEPT [444:43563] :FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [402:144198]

:POSTROUTING ACCEPT [402:144198]

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP