LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 05-02-2004, 02:10 PM   #1
-Nw- neX
Member
 
Registered: Apr 2004
Distribution: Gentoo, RHL, CentOS, Ubuntu, FreeBSD,
Posts: 88

Rep: Reputation: 15
quick and dirty iptables firewalls


ive seen alot of posts on here about getting firewalls working, or tools to make firewall design easier. thought i would post the method i use for my home boxes. most distributions offer some way of setting up and controlling the firewall on your system but doesnt offer alot of insight as to what is being done. what follows is a 'quick and dirty' method of getting a working firewall up on your system. i use this method simply because its portable between systems, so its write once, run anywhere with minimal adjustment. keep in mind that these scripts are designed for a system with a single network interface, no routing or IP masqurading, and not really meant for a production environment [but are easily adaptable to work in such an environment ].

first off, i think that firestarter is a great tool. BUT to get a true understanding of how iptables works, you really have to take a look at the scripts that firestarter generates. they are normally found in /etc. ignore all the variables and take a look at the commented [#] lines and the lines that start with 'iptables'. the comments will give you info about what is being done, and the iptables lines are the actual rulesets that are being implemented. iptables is not all that difficult when you get your head bent around how the policies and rulesets work.

so, here is what i generally do. the majority of this will work on just about any distro. ive tested it on slackware 9 and redhat 7/8 with excellent results. the entire process is fairly simple, here we go.

---------------------------

login or su to root and create a directory in roots home [usually /root] called 'bin'.

Code:
$ su 
Password:
# whoami
root 
# cd /root
# mkdir ./bin
add a line to your .bash_profile [.bashrc on some distros] to add /root/bin to your path. use your favorite text editor to do this [vi/vim, pico/nano, emacs, joe, ed].

Code:
# vi .bash_profile
the line you want to add will be the following:

Code:
PATH=$PATH:/root/bin:
if you have already made adjustments to your PATH, just tack the :/root/bin: onto the end of the line. this will add your new ./bin directory to the default PATH for root. saves you from typeing absolute values for commands, and gives you a directory where you can run your own homemade scripts and commands from.

next, open up a new file in /root/bin called fire.up.

Code:
# cd ./bin
# vi fire.up
and start typing all this in:

Code:
#! /bin/sh
# this script brings up the firewall.

# point to the actual firewall rule file. this file is the one that the firewall rules are read from.
/root/bin/firewall

# print out some stuff to tell us that things are being done
echo ' ' 
echo '---- FIREWALL IS NOW ACTIVE ----'
echo ' ' 

# print out the actual rulesets and polices to look at.
iptables --list
save the file, and quit your editor.

heres what all this does. the #! [called a bang line, or a shebang] basically tells your shell what to use to execute the rest of the file. in most cases, you are normally pretty safe using /bin/sh or /bin/bash. on most systems bash is the default shell. the lines beginning with 'echo' bascially outputs a bit of info to the console, telling you that something has been done. the 'iptables --list' line outputs the current rules of your firewall [not that we have any yet].

next file. open up your editor to a file called fire.down.

Code:
#! /bin/sh

# flush chain rules.
iptables -F

# reset default policy to accept, flush does not take care of this.
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

# give us the new rules. all INPUT and OUTPUT should have been set
# to ACCEPT. make the output numeric. 
iptables --list -n

# tell us that firewall is now down.
echo ' '
echo '---- FIREWALL IS DOWN ----'
echo ' '
the comments here are fairly self-explainatory. save the file and close your editor.


ok. one more file. the actual firewall rules that will be read by your fire.up script. keep in mind this is just an example. your firewall rules are based on what you need access to. and will have to be modified to fit your needs. this is just something to get you started. open up your text editor to a new file called [surpisingly] firewall. this is the file that fire.up will read to get all of its rules from.

Code:
# this file should be located in /root/bin.
# if root has no /bin directory, then simply create one and mv this file.

iptables -F											# start clean, flush the chains if there are any
# iptables -X											# cleans any user defined chains. not using any right now.

# set default policies, input to drop. 
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

# entering default accept for 'lo' just in case things break
iptables -A INPUT -i lo -j ACCEPT

# make spesific accepts for what we are running. 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT        #Allow child connections of existing connections, do not delete.
iptables -A INPUT -p tcp -s 0/0 --dport 80:81 -j ACCEPT			#www
iptables -A INPUT -p tcp -s 0/0 --dport 22 -j ACCEPT			#ssh
iptables -A INPUT -p icmp -s 0/0 -j ACCEPT				#PING! so we can tell the box is up remotely.

# some spesific drop IPs just for troublemakers.
# the xxx just represents some ip that i made up
iptables -A INPUT -p ALL -s 24.xxx.xxx.xxx -j DROP				# sending us short UDP packtes.
iptables -A INPUT -p ALL -s 211.xxx.xxx.xxx -j DROP				# more short UDP fun. from xxx this time. xxx.com
iptables -A INPUT -p ALL -s  202.xxx.xxx.xxx -j DROP				# more xxx UDP joy.


# entering some logging facilities. this has to be at the bottom 
# to get dropped packets only. putting it at the top will get you
# all the packets coming through the interface. we are going to log
# all dropped tcp and udp packets. all entries will be dumped into /var/log/messages.
iptables -A INPUT -p tcp -j LOG --log-level info --log-prefix 'IPTABLES-INPUT-TCP-DROP: ' --log-ip-options --log-tcp-options
iptables -A INPUT -p udp -j LOG --log-level info --log-prefix 'IPTABLES-INPUT-UDP-DROP: '
save the file and exit your text editor.

so now we have a ruleset that our fire.up script can read. the last step is to make both fire.up and fire.down executable.

[code]# chmod +x fire.up
# chmod +x fire.down[/code}

all done. you can now bring your firewall up using fire.up, clear the firewall using fire.down, and adjust your firewall settings in the firewall file.

now for some explaination as to what the various things in the iptable lines in our rulesets do for us.

-P -- Policy. there are three default policies for iptables. each policy has a chain of rules associated with it. the default policy for INPUT [incoming connections], OUTPUT [outgoing connections], and FORWARD [NAT/ip masqurading] are all set to ACCEPT. its always best to reset the default policy for INPUT to DROP. this will drop all packets and only allow connections that are known. [you can use REJECT as well. but DROP doesnt give any feedback if someone is using hping or scans your ports]
-A -- Append. add a new rule to the specified policy.
-p -- Protocol. there are only three protos that we really care about; tcp, udp and icmp.
-m -- Match. checks for the current state of connections. combining this with --state ESTABLISHED,RELATED -j ACCEPT will allow any connections that your box establishes from inside the firewall [i.e. any outgoing connections that you make on any port are allowed] to continue to work. remember, in order to get reqeusts back, there is a connection that comes in from outside your firewall.
-s -- Source [port]. a source IP address or network. so either something like 192.168.1.125 for a spesific ip, 192.168.0.0/24 for an entire network, or 0/0 for all ips and all networks.
--dport -- Destionation Port. the port or ports you want to work with. you can specifiy a range of ports using the : [colon] in the form: N:X, where Nis the beginning of your range, X is the end of your range. the statement is inclusive.
-j -- Jump [to rule]. well, what it really means is 'job' or 'do this' when an incoming packet matches the ruleset. so either ACCEPT or DROP the packet, or LOG the packet under logging rules.
-n -- Numeric. show numeric output only, dont resolve ip to hostname.
-L or --list -- list the iptables rules. usually done from a command line.
-i -- interface. we didnt use this, but you can if you have multiple NICs. the form is simple: -i ethX, where X is the interface number.
-h -- Help. the ever useful help output. from the command line, gives you the basics of iptables.
--log-level -- Log Level. according to syslog, what level you want traffic logged at. there are several settings here, but info is the most useful. this will dump all of your logged packets into /var/log/messages. you will need to look at the man pages for syslogd and syslog.conf to get spesific firewall logs.
--log-prefix -- Log Prefix. when the packet is written to the log, it will get the stated prefix.
--log-ip-options -- Option Logging. enters further IP information into your log from the packet headers.
--log-tcp-options -- Option Logging. enters further TCP information into your log from the packet headers.

---------------------------

some of the more advanced users may think that this is pretty basic. this is actually intentional for a number of reasons.

1. Security -- all files are in /root [that should be permissioned to 700]. so they are not easily accessed by anyone who does not have root access to the system. i dont like users reading my firewall settings, so i keep them in a directroy that is only accessable by privalaged users. since the majority of attacks come from inside a network as opposed to from the outside, this seemed to be a good way to go about things.
2. Ease of Use -- all the scripts are easy to understand. in the case you are no longer admining a box, another admin can come in and make any nessasary changes with very little hassle. the scripts are portable across systems, as mentioned in the intro, so less config work involved. [lets face it, im lazy.]

if anyone notices a problem in here somewhere, or has an improvement to implement. please post! im always looking to make things better [like spesific logging for example]. hope this helps some people out.
 
Old 05-08-2004, 04:36 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600Reputation: 3600
A few notes if I may.
- IMNSHO whatever is in root's home should be left alone as much as possible. No system scripts should live in root's home. They should go under /etc. If you have problems with accessability, dump them for instance in /etc/rc.d and chmod 0700 that cuz only the system needs that dir.
- The firewall script should be run before any interface are up. This is another reason for tying it in with other system scripts.
- While using custom commands to start the firewall are good if you only administer one system, it'll be a PITA when you've got more systems to control. Use std Sys-V or BSD commands will make it easier for ppl to figure out.

Other than that your fw script is "good" wrt defaulting to DROP policy, but still it would be good to incorporate std bad packet flags, DoS, u/mcasts, denied LAN ranges, logging and limiting rules for flexibility. If you've got the time, please check out the links in the LQ FAQ: Security references.


Thanks for your post, it is a nice explanation.
 
Old 05-08-2004, 09:43 AM   #3
-Nw- neX
Member
 
Registered: Apr 2004
Distribution: Gentoo, RHL, CentOS, Ubuntu, FreeBSD,
Posts: 88

Original Poster
Rep: Reputation: 15
thanks for the input!

im going to look into some of the stuff that you have mentioned.
 
Old 06-04-2004, 10:18 PM   #4
cassiusclay
LQ Newbie
 
Registered: Jun 2004
Location: Atlanta, GA
Distribution: Slackware and OpenBSD
Posts: 22

Rep: Reputation: 15
thanks - good iptables howto for guys like me with short attention spans
i put my firewall script it in /etc/rc.d because this time around im not doing anything as root cept thru su
but it was quick to get to the port range format ####:#### and other options - but now i have to read some more to create a separate firewall log
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
DISCUSSION: Quick and Dirty Backups jeremy LinuxAnswers Discussion 2 03-10-2006 10:56 AM
KDE 3.5 is out! Quick 'n Dirty Upgrade Shade Slackware 19 12-25-2005 04:06 AM
Quick and dirty tutorial on networking? neocookie Linux - Networking 2 08-27-2004 07:22 AM
Two Quick and Dirty Ones! gsibble Linux - Newbie 9 08-14-2003 03:40 AM
quick and dirty! Smerk Debian 4 07-03-2003 08:33 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 12:20 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration