Advertisement
     
 
 
Search:
General | Linux Hacking | Linux Networking | Linux Security | Windows Hacking
       
Practical Guide for Using ipchains PDF Print E-mail
Written by LE Webmaster   
Wednesday, 26 January 2005

Like you can see in the title, this will be a practical guide, so those ultra technical thoughts will be left aside. My goal on writing this is to give enough knowledge to an ordinary person who doesn't have a clue on how to setup ipchains to firewall it's box or LAN. Grab something to eat and something with caffeine and start going down the hill, uh..text. Let's start reading something useful shall we? Basics needed to mentioned


Network Policy

The first thing you have to start thinking if you want to firewall
your box, or network, is what policy will you use. What do I mean with
this? Well there's two kinds of policies Accept policy and Deny policy.
In the accept policy everything that is not said to be denied will
be accepted, otherwise in the Deny policy everything will be denied
except what you have told not to.
In my opinion the best policy is the deny policy, since you just have
to add the services that you want to give, and everything else that
shouldn't be given will be just nicely denied by default. The accept
policy may need tons of filtering rules, since you will need to say
everything that you won't to block.


Chains & Rules

If you don't understand for what each stands you'll have
problems to understand how ipchains works.

Chains

There are 4 types of chains, let's first focus on the first 3 so
you can understand what a chain is. When a packet is trying to enter the
network interface it will pass by the input chain; if the packet is
trying to leave the network interface it will pass by the output chain; if
the packet is trying to "jump" from one interface to another it will
pass by the forward chain. So what I'm trying to say is that:

- When a packet tries to access our network it will have to pass
by the input chain.
- When a packet tries to leave our network it will have to go
through the output chain.
- When a packet tries to jump from one interface to another (if
you are not getting this part, imagine ip forward, it's done in this
chain) it will go through the forward chain
The 4th chain is the user defined chains, were you can make
your own chains.

In each of this chains you'll have to define what policy you'll
use in it. There are 3 possible policies:

To use the accept policy you'll use the ACCEPT policy.
To use the deny policy you can use to policies:

- DENY
- REJECT

What's the difference you ask, both deny packages.
If you use the DENY policy packages that are not allowed will be
discarded by kernel, without reporting to the remote host that the
packet has been discarded. This is cool, because it doesn't eat resources
of your system, and will leave the remote host without knowing that the
package as just been denied, which is good if it was someone trying to
hack your system.
If you use the REJECT policy, packages that are not allowed will
also be discarded but a ICMP error will be generated by the kernel and
sent to the remote host. This will eat system resources, which sucks
big time.
My advice is to use DENY policy instead of REJECT policy. There
will be an exception but we will talk about it later.


Rules

We have talked about chains, but chains by itself don't filter
packages, chains just have policies. Rules control the flow of the packages
through the chains. We can see a rule as a group of conditions and a
target. The group of conditions is used to match with just a type of
packages, the target will define what will happen to the packages that
will match the group of conditions.
In rules you can also apply the ACCEPT, REJECT and DENY. Which will
just accept, reject or deny the packages that matches the conditions on
those rules, in this case the policy of the chain won't influence
nothing since there's a rule for those packages. If there is no rule for a
package then, the policy of the chain will be applied to it.
My advice is also to use always DENY, because it's doesn't eat so
many system resources as REJECT does. But remember if you are connecting
to SMTP do yourself a favour, add a rule of REJECT packages in port 113
(auth). Why? Well, because when you connect to the SMTP server, it will
try to connect to your auth pport to know who are you, if you have DENY
the packet will be discard "silently" so the SMTP server will wait
until the timeout to proceed the connection, this can be a 1 to 2 minutes
waiting period. So if you set a REJECT rule at port 113 when STMP tried
to connect receives an error and it will proceed without any waiting.
Isn't that better?
The last thing you should know about rules is that the first one
that matches is taken, and the process will stop there for that package.
For the one who code you can see the rule analysis as a if {} else
if{}. This means that if you first say to block all ports from 10 to 100
and the rule after you allow connection to port 22, the second rule will
never be effective because the 22 is between port 10 and 100 so the
first one will be taken.

We will now talk about the last thing in this section and then will
start with ipchains commands and building our own firewall. Nice isn't
it?
And the last thing we will talk is....(drums here)....


Ip and Masking

Why masking? Well because masking can be really helpful in rules.
If some of you asked why masking, others may have asked what's
masking?

Since masking could give an entire text, or even book about the
subject here it goes a ultra resume which will be enough for you to
understand how it works.
An ip is constructed with 4 bytes each one separated from each other
with a dot. Example:

ip: 193.34.13.15 this ip can also written like
11000001.00100010.00001101.00001110

In an ip some of this bytes represent the network mask and the rest
of it represents the host mask.
What masking does is telling how many bits, not bytes but bits (1
byte = 8bits) are fixed, and how many bits aren't. This means that
0.0.0.0/0 can match any ip address, and 134.34.12.12/32 can match just with
134.34.12.12 but 134.34.12.0/24 can match with ips from 134.34.12.0 to
134.24.12.255.

The secret to understand this is thinking in ips in binary notation
and not in decimal.



Well I think you guys are prepared to start with ipchains. What do you
say, let's rock?





Ipchains: Finally


I think the best way to talk about ipchains syntax and
configurations is write a ipchains script first. There will be two scripts one for a
standalone box and another for a firewall that will be masquerading an
entire network. Comments will be there so you can understand.


---- Script Starts below ---

#!/bin/bash

# ipchains script written by Ghost_Rider
# to be used as an example in
# Practical Guide for using ipchains


IPCHAINS ="/sbin/ipchains"


# First thing we'll flush all rules. This will give us 100% that
# old rules that might be there aren't used anymore.

$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F forward


# Now let's set policies.
# Deny policy for input and forwarding (this will be a standalone box)
# Access policy for output.
# Note: policy needs to be all in capital letters otherwise won't work

$IPCHAINS -P input DENY
$IPCHAINS -P output ACCEPT
$IPCHAINS -P forward DENY


# All localhost traffic will be accepted
# so we add the following line

$IPCHAINS -A input -i lo -j ACCEPT

# What each thing mean:
# -A: add another rule to the chain told, in this case input chain
# -i: tells what interface to filter, in this case lo (loopback), this
means localhost traffic
# -j: tells what to do with the package (policy of the rule)


# Let's allow packages with established connections to proceed.
# What it does is check if the package doesn't come with the
# syn flag on, that's why we have the ! -y which stands for the
negation of -y
# But hey this request can be faked. It's not that hard to build our
own packages

$IPCHAINS -A input -i ppp0 -p tcp ! -y -j ACCEPT


# ppp0: it's the ppp connection interface
# -p : selects the protocol for that rule, in this case tcp
# -y: check if the packages has the syn flag or not.
# !: negates the switch, in this case -y


# Let's accept DNS replies

$IPCHAINS -A input -i ppp0 -p tcp -sport 53 -j ACCEPT
$IPCHAINS -A input -i ppp0 -p udp -sport 53 -j ACCEPT

# Let's allow connection to ssh

$IPCHAINS -A input -i ppp0 -p tcp --dport 22 -j ACCEPT


# --dport: tells what destination port is, in this case 22
# you can also use --sport for source port (port from the
# remote machine)

# Let's reject the auth connection
# If you dunnow why we are doing this read again the rule section.

$IPCHAINS -A input -i ppp0 -p tcp --dport 113 -j REJECT


# Let's allow certain ICMP type.
# type 0 which is echo reply (so you can receive the reply from pings
you sent)
# type 3 which is Destination Unreachable (so you don't have to wait
for timeouts)
# type 11 which is Time Exceed (used for trace route)


$IPCHAINS -A input -i ppp0 -p icmp --dport 0 -j ACCEPT
$IPCHAINS -A input -i ppp0 -p icmp --dport 3 -j ACCEPT
$IPCHAINS -A input -i ppp0 -p icmp --dport 11 -j ACCEPT

# NOTE: you probably are thinking "what the.... this guys is giving
# destination ports to icmp, but icmp doesn't have destination ports"
# Well if you look closer, the --dport is actually the icmp type.
# Yep...In ipchains the --dport when the protocol is icmp tells
# the icmp type. Don't Forget this.


# Now let's see everything else that is striking us
# and let's log it.

$IPCHAINS -A input -j DENY -l

# As you read in the rule section the first one that matches
# "wins" and the analysis of the other rules won't be done.
# So what we do here is that if the packet that has reached us
# hasn't been accepted on the other rules, it's because it's
# something we just want to deny but it's better to log it
# that's why we use the -l switch.
# If you don't wanna log this packages you didn't need to put
# this rule, since the policy of input chain is deny so the
# packet would just be denied and discard, but not logged.


--- Script Ended here -----


Now let's see a script of a firewall that would be a also a ip
masquerading machine.
Some of the rules won't have the detailed comments as on the first
script since you already have them.
Doing this I'm supposing that the firewall has 2 interfaces the ppp0
that connects it to the internet and the eth0 that connects it with the
LAN.

---- Script Starts below ----


# Ipchains script written by Ghost_Rider
# to be used as an example in
# Practical Guide for using ipchains


IPCHAINS = "/sbin/ipchains"

# Let's flush all rules

$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F forward


# Let's set policy
# input will use DENY
# output and forward will use ACCEPT

$IPCHAINS -P input DENY
$IPCHAINS -P output ACCEPT
$IPCHAINS -P forward ACCEPT


# Allow local traffic


$IPCHAINS -A input -i lo -j ACCEPT
$IPCHAINS -A input -i eth0 -j ACCEPT


# eth0 stands for the interface
# with the 1st ethernet card


# Now let's block the private ip addresses
# that should come in by ppp0

$IPCHAINS -A input -i ppp0 -s 10.0.0.0/8 -j DENY
$IPCHAINS -A input -i ppp0 -s 172.16.0.0/12 -j DENY
$IPCHAINS -A input -i ppp0 -s 192.168.0.0/16 -j DENY

# Not getting why we are blocking this ip addresses?
# Well this 3 network addresses are restricted ips
# Which are just used for internal purposes
# This means that no host in the internet may have this ips
# So isn't it a little strange if they are coming from ppp0
# Looks like someone trying to spoof and hack our network
# So we just deny it.... got it?:)


# Let's allow DNS replies, but just
# our ISP primary and secondary DNS servers
# note: 194.13.20.19 and 194.13.20.20 are
# our ISP's DNS servers

$IPCHAINS -A input -i ppp0 -p tcp -s 194.13.20.19 53 -j ACCEPT
$IPCHAINS -A input -i ppp0 -p tcp -s 194.13.20.20 53 -j ACCEPT
$IPCHAINS -A input -i ppp0 -p udp -s 194.13.20.19 53 -j ACCEPT
$IPCHAINS -A input -i ppp0 -p udp -s 194.13.20.20 53 -j ACCEPT


# Let's allow ssh
# we do not need to allow the -i eth0 to -dport 22
# because we are already accepting everything from eth0
# check when we are accepting loopback and ethernet packages

$IPCHAINS -A input -i ppp0 --dport 22 -j ACCEPT

# We will now reject packages for port 113

$IPCHAINS -A input -i ppp0 -p tcp --dport 113 -j REJECT


# allow the those 3 ICMP type

$IPCHAINS -A input -i ppp0 -p icmp --dport 0 -j ACCEPT
$IPCHAINS -A input -i ppp0 -p icmp --dport 3 -j ACCEPT
$IPCHAINS -A input -i ppp0 -p icmp --dport 11 -j ACCEPT


# Log everything else

$IPCHAINS -A input -j DENY -l


# Let's now block just some address that we don't
# want people from our LAN to access
# like www.porno.com and www.rival.company.com
# let's supposed that ips addresses were
# 202.120.12.3 and 120.10.0.34

$IPCHAINS -A output -i eth0 -d 202.120.12.3 -j DENY
$IPCHAINS -A output -i ppp0 -d 120.10.0.34 -j DENY


# And finally we will add the masq rule

$IPCHAINS -A forward -j MASQ -s 192.68.1.0/24 -d ! 192.168.1.0/24

# Our network is 192.68.1.0/24
# -d ! 192.168.1.0/24 stands for if destination is not from our network
# In other words...If source if our network and destination isn't
# our network the firewall has to use MASQ.
# Now remember that just with this ipchain rule you can't
# forward things..Because firewall doesn't route things..That's
# for routing tables.
# So install the port forwarding tool (ipmasadm).



A little info about port forwarding tool:
Let's say you firewall external ip, is 193.45.12.10 and that the host
that is giving http services is 192.168.1.17. So you would type
something like:


ipmasqadm portfw -a -P tcp -L 193.45.12.10 80 -R 192.168.1.17 80


where:

portfw can be called the forwarding chain for ipmasqadm
the -a stands for like in ipchains for add
-P tcp for protocol used, in this case tcp
-L stands for local address, with ip and port
-R for redirecting address, with ip and port


Well and I think that's it all for now.
I hope that it helped you understanding how to use ipchains and how to
set it up.
Have a nice day.
ghostrider@boxnetwork.net
Add as favourites (106)

  Be first to comment this article

Write Comment
  • Please keep the topic of messages relevant to the subject of the article.
  • Personal verbal attacks will be deleted.
  • Please don't use comments to plug your web site. Such material will be removed.
  • Just ensure to *Refresh* your browser for a new security code to be displayed prior to clicking on the 'Send' button.
  • Keep in mind that the above process only applies if you simply entered the wrong security code.
Name:
Comment:

Code:* Code

 
< Prev   Next >
 
© Copyright 2002-2008 - Linux Exposed - Sponsored by ConsultPlanet http://www.consultplanet.nl - Contact Linux Exposed