firewall script ( iptables, hosts, arp, ip6tables, portsentry, and tripwire)

mrmnemo · 12-06-2009, 01:04 PM

ok so i am new to setting up a firewall. i have seen many scripts on the net for taking care of things for me...I WANT TO DO IT. firstly, can i have a script in bash that will handle the needed portsentry and tripwire conf's and commands? secondly, can anyone tell me a location to check services and port RANGES ( i.e.: ftp,torrent,traceroute, etc..)

I have started the iptables and module loading portion of the script and can post it if aanyone is interested in helping out. Also, would it be better to do this in perl?

GrapefruiTgirl · 12-06-2009, 01:24 PM

Quote:

Originally Posted by mrmnemo

can i have a script in bash that will handle the needed portsentry and tripwire conf's and commands?

You are making the script -- therefore, you can make it handle whatever you like. But to clarify, what exactly do you mean by "handle the needed portsentry and tripwire conf's and commands"? Please explain further.

Quote:

can anyone tell me a location to check services and port RANGES ( i.e.: ftp,torrent,traceroute, etc..)

Do you want a place to check whether or not these ports are OPEN? Try grc.com among many others.

OR -- do you want a list of all the possible protocols and their ports, so you know what you're doing? If this is the case, try iana.org.

Quote:

Also, would it be better to do this in perl?

Depends what you mean by better. I don't know much (about) perl, except that it is surely capable of doing the job. But so is bash or sh. My opinion on this is: use what you're comfortable with.

I am nearly ready to release my own firewall for testing and general use, and it's entirely written in bash script, so I can at least attest to the fact that bash is perfectly capable of doing the job.

Sasha

salasi · 12-06-2009, 04:30 PM

Quote:

Originally Posted by mrmnemo

ok so i am new to setting up a firewall. i have seen many scripts on the net for taking care of things for me...I WANT TO DO IT.

not clear whether you mean that you want to use an existing script and 'hack' (in a good way) it, or start from scratch, but

Quote:

firstly, can i have a script in bash that will handle the needed portsentry and tripwire conf's and commands?

well, yes, sort of. The script and/or iptables handles protocols and port ranges rather than commands to utilities...as you seem to know..

Quote:

can anyone tell me a location to check services and port RANGES ( i.e.: ftp,torrent,traceroute, etc..)

Oh, yes. You can do this several ways:

Look in the man pages or other documentation for the utility (tutorial or maybe its documented in the conf file, which you probably have to look at anyway). This is time consuming and will only work for some.
look in /etc/services. This will work for what is known as 'well known ports' so may fail for some obscure utilities, but should work for most.
Open the app and look which ports they grab with something like netstat. This should work, but does mean that you have to at least open the ports on a trial basis before you have the firewall fully ready. Pulling out the network cable may well obviate security concerns with this approach.

Quote:

Also, would it be better to do this in perl?

No. (In my case, the equivalent question was 'would it be better done in python', but the reasoning is the same.) There are very few reasons why bash might not run, and most of those are 'something is so seriously wrong that all bets are off', but there are a few that an interpreted language may not, or not be the version that you were expecting and have tested, and for something that you need to just run every time that you boot, you just want it to do the same stuff that it did when you tested it.

Additionally, what you want out of this is something that can do a simple bit of arithmetic with ip addresses and a few bits of conditional testing and bash can do all that stuff without breaking a sweat, so you don't really get much advantage out of using something more 'powerful'.

mrmnemo · 12-06-2009, 07:16 PM

Quote:

Originally Posted by salasi

well, yes, sort of. The script and/or iptables handles protocols and port ranges rather than commands to utilities...as you seem to know..

i DO understand that iptables is just sending the same commands i would have to enter by hand. however, what i am try to figure out is this: A bash script can or cant ( via piped ) edit the confs for the other utils to be used in a firewall solution; which as i have been told, includes more than just iptables.

by the way....Thanks for responding. My end goal is to put something together that will make the initial securing of a DESKTOP / HOME NETWORK box really straight forward for someone ( like myself) who is still green behind the ears. I enjoy trying to figure this stuff out; however, the family members that i have gotten to switch over are more....Well thanks for the response.

in your firewall are you making load mods and set up arp filtering? arp filtering requires editing its conf which seems more than bash can deal with. also, hosts(allow, deny, equiv) need to be edited out side of the bash script which is what i am trying to get around. in MS i have made interactive scripts for malware removal in the past. bash scripts can be interactive as well? less verbosity?

once again,

thanks for tha help

GrapefruiTgirl · 12-06-2009, 09:22 PM

The stuff you mention above: editing of other conf files, verbosity (more or less), interactivity, and whatever else is needed to do firewalling, can all be done with bash. Module loading, restarting of other network tools or programs, or sending them signals.. No problem.

To edit other files (or any files for that matter) using bash, can be done using a combination of one or more unix commands (tools) called by the bash script; these would include tools like sed & gawk & tr & cat & read & line (maybe read is built-in), and bash built-ins like the simple `echo` command (of which there's a stand-alone too).

Sasha

mrmnemo · 12-06-2009, 09:41 PM

removed older version of script. see later post below.8)

thanks for showing interest

john

GrapefruiTgirl · 12-06-2009, 11:46 PM

Here's just some random thoughts on things:

A default policy of DROP ALL or LOG,DROP is of course the most secure policy. Starting with that as the default, is a good starting point.

Something to consider: How do you plan on allowing Joe User to configure his/her network, using your script? Remember, Joe user doesn't have a clue about editing iptables commands or bash scripts, so you either need lots of documentation, or some way of translating simple, understandable rulesets, into iptables commands.

Dealing with SYN flooding and other types of DOS attacks, as well as port-scanning tools, is done by limiting the number of certain types of packets that are allowed in a given time, from a given connection, and/or for example by limiting the total number of unanswered SYN-ACKs floating around.
But, if you need to have a port open for any sort of incoming traffic, the port is open; there's no two ways around that. BUT, you can have rules that only reply to incoming connections from a certain address, and drop or reject traffic from elsewhere. You can also run services on weird ports, and forward incoming traffic transparently to that port. This is often done for incoming SSH connections, because brute-force SSH attacks on listening SSH ports is common (just check your firewall logs; chances are, you'll see some sometime).

There are also some items in /proc which are helpful in building a firewall. TCP-Syn-cookies is one that helps with the SYN situation. To name a few others: Reverse-path filtering, Accept-source-route, icmp-echo-ignore-all, IP-forwarding, logging of martian packets (packets originating from an external source, but claiming to be from an internal (C-Class for example) network. Example: the 192.168.x.x address range is reserved for internal networks only; therefore, if you receive packets from OUTSIDE your external interface (the internet in other words) with an IP in this range, you know they are spoofed.

Connection-tracking is required for a stateful firewall. Stateful means that the firewall is capable of determining which traffic is justifiably established, and maintaining that connection; so, if you want a stateful firewall (yes, you do) then you need conn-tracking. That said, it's pretty irrelevant whether it slows the machine down. But all in all, I'd say no, it doesn't slow the whole machine down, but it DOES require some small amount of kernel-time, and does eat a small % of net bandwidth. The difference for the average machine or network is negligible.

You'll want to consider a way for Joe User to input information to the script. For example, your INT_INET is set statically; unless Joe is to edit the script, you'll want to ask him (or have a config file) what address that should be. And, on the subject of config files: if you don't want Joe to have to answer the same questions every time he starts the firewall, you'll probably want to save the configuration by some means. For this, you will almost certainly find iptables-save and iptables-restore to be helpful.

On my firewall, I have the OUTPUT policy default set to DROP as well. I make my rules on an as-needed basis, including for outbound traffic. One single reason for doing this, is let's say your Linux box, (or more likely a Windows machine in your network), gets rootkitted somehow, and turned into a SPAM robot; what you DON'T want, is for thousands of spam emails to have originated from YOUR NETWORK before you discover that it's been compromised. If you have a very tight outgoung policy to match the incoming policy, you have the upper hand in this case.

Anyhow, that's just some thoughts on stuff. Remember, there are lots of existing scripts that you can refer to, and this link is very good too for iptables instruction: http://www.bec.at/support/iptables-tutorial/index.html

The very best,
Sasha

GrapefruiTgirl · 12-06-2009, 11:46 PM

Sorry -- duplicate post :/

mrmnemo · 12-07-2009, 01:39 AM

Quote:

Originally Posted by GrapefruiTgirl

Something to consider: How do you plan on allowing Joe User to configure his/her network, using your script?

i thought about that today. I am currently putting some stuff in the script ( see code) that you may think would be helpful. its like 3 am or something so i wil finish later. I got the info on the bashing part from >> http://tille.garrels.be/training/bash/

Code:

#!/bin/sh
IPT=/usr/sbin/iptables
MODPROBE=/usr/sbin/modprobe
INT_NET=192.168.1.0/24
### This is my first attempt at making an interactive script in BASH. I thought using a 
### firewall script would be a good place to start. So, if some of this seems redundant
### or just plain stupid....its just for learning. I hope that this script may help 
### someone else sort out iptables and BASHing 8)
### john_teasley@att.net

### The user input portion. SEE: http://www.linux.org/lessons/advanced/x1110.html or 
### http://tille.garrels.be/training/bash/ for a great tutorial on this section!!
echo "Hi $UID! This script was put together by john_teasley@att.net"
echo "with lots of help from linuxquestions.org!"
Pause()
{
    key=""
    echo -n "[+]Hit any key to continue...."
    stty -icanon
    key=`dd count=1 2>/dev/null`
    stty icanon
}

### Check to see if this a slacky box ;] Still not sure if i need or even should do this.??>

#if [ -f etc/slackware-version ]
#  then
#    echo "You appear to be running slackware"
#fi

#Pause()
#{
    


#}



###cleaning up the tables
echo "[+]Flushing exsisting rule sets on $HOSTNAME..."
 $IPT -F
 $IPT -F -t nat
 $IPT -X
 $IPT -P INPUT DROP
 $IPT -P OUTPUT DROP
 $IPT -P FORWARD DROP

### load up connection-tracking:> can this slow down the pc?
echo "[+]Loading needed modules to " 
 $MODPROBE ip_conntrack
 $MODPROBE iptable_nat
 $MODPROBE ip_conntrack_ftp
 $MODPROBE ip_nat_ftp

### INPUT (incomming connections)
echo "[+]Applying INPUT chain rules"

### state based rules
 $IPT -A INPUT -m state --state INVALID -j LOG --log-prefix "DROP INVALID" --log-ip-options --log-tcp-options
 $IPT -A INPUT -m state --state INVALID -j DROP
 $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

### Anti-spoofing rules.
### TODO: Use mac filters for SOHO or ARP (static)? need some input please
 $IPT -A INPUT - wlan0 -s ! $INT_NET -j LOG --log-prefix "SPOOFED PKT"
 $IPT -A INPUT -i wlan0 -s ! $INT_NET -j DROP

### Externally initiated connections to intranet
### Uncomment the rules below that are needed

### SSH
# $IPT -A INPUT -m state --state NEW -j LOG --log-prefix "ACCEPTED REMOTE SSH" --log 
# $IPT -A INPUT -wlan0 -p tcp -s $INT_NET --dport 22 --syn -m sate --state NEW -j ACCEPT

### ICMP
# $IPT -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

### DEfault INPUT LOG rule
$IPT -A INPUT -i ! lo -j LOG --log-prefix "DROP" --log-ip-options --log-tcp-options

### OUTPUT (outgoing connections)
echo "[+]!!!DEFAULT IS TO ALLOW ALL OUT GOING. CHECK RULES TO CHANGE!!!"
echo "[+]!!!DEFAULT IS TO ALLOW ALL OUT GOING. CHECK RULES TO CHANGE!!!"
echo "[+]Applying OUTPUT chains"

### Check OUTPUT pkt state for match
### Is NEW implied when allowing for OUTPUT
### I set output for ALLOW ALL. Could use some input here for some standard file share stuff needing to open connections
 
 $IPT -A OUTPUT 
 $IPT -P OUTPUT ACCEPT 
# $IPT -A OUTPUT -m state --state INVALID -j LOG --log-prefix "DROPED OUTPUT INVALID" --log-ip-options --log-tcp-options
# $IPT -A OUTPUT -m state --state INVALID -j DROP
# $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
### TODO : ALLOWED OUTBOUND NEW {ranges>established}plug to portsentry?

also, thanks sasha very very much for your help. It is greatly appreciated.

salasi · 12-07-2009, 07:03 AM

Quote:

Originally Posted by mrmnemo

...edit the confs for the other utils to be used in a firewall solution; which as i have been told, includes more than just iptables.

I haven't got a need to edit the 'confs for other utils'. If you can explain in detail what you are trying to achieve with this, maybe there is a better way (eg, using bash to swap configs rather than edit them). Even if you do want to edit confs, you can do this with sed/awk/etc called from bash, as explained earlier (although I don't think it is necessary for many people).

Quote:

in your firewall are you making load mods and set up arp filtering?

No. I would venture that most people don't (from what I've seen), so, if you can give further details of what advantage you feel this gives you, there may be a better way of achieving your aims.

Quote:

bash scripts can be interactive as well?

You have to achieve a good level of protection even if the user does not respond, or takes an undue amount of time, or if the response given is erroneous, so interactivity does not seem like a good feature in this context, unless you have an unusual aim.

PS: the code in yellow is a bad idea (almost unreadable), but:

Code:

### load up connection-tracking:> can this slow down the pc?
echo "[+]Loading needed modules to " 
 $MODPROBE ip_conntrack
 $MODPROBE iptable_nat
 $MODPROBE ip_conntrack_ftp
 $MODPROBE ip_nat_ftp

Loading the contrack modules doesn't appreciably slow the pc down (well, unless you are short of memory and the extra memory usage is an issue); using them might, depending on how much traffic they have to process.

Code:

### Anti-spoofing rules.
### TODO: Use mac filters for SOHO or ARP (static)? need some input please
 $IPT -A INPUT - wlan0 -s ! $INT_NET -j LOG --log-prefix "SPOOFED PKT"
 $IPT -A INPUT -i wlan0 -s ! $INT_NET -j DROP

mac address filtering, while quite powerful, always seems like building a predictable maintenance problem into your script, and so should be avoided (imho) unless, to achieve the functionality that you need, there is no sensible alternative.

Code:

### SSH
# $IPT -A INPUT -m state --state NEW -j LOG --log-prefix "ACCEPTED REMOTE SSH" --log 
# $IPT -A INPUT -wlan0 -p tcp -s $INT_NET --dport 22 --syn -m sate --state NEW -j ACCEPT

To be blunt; I'd regard this as inadequate. Currently there seem to be a lot of 'brute force' ssh attack attempts about. Most of the individual attack attempts fail, but when someone can make many individual attempts, essentially for free, the attackers can just 'repeat 'till successful'.

It is my opinion that there is a need to do something about this.

Possibilities:

don't install or run ssh; this will not be tolerable for everyone
run on an unconventional port; may work if people don't snoop your traffic and detect your replacement port (or get lucky)
use something like port knocking, for some extra security
use whitelist/blacklists to reduce the chance of repeated attacks

(I am currently using the first and am considering an automated approach to the last when the first proves intolerable for me. Without an automated approach, the whitelist/blacklist approach can be a bit of a pain.)

Code:

### DEfault INPUT LOG rule
$IPT -A INPUT -i ! lo -j LOG --log-prefix "DROP" --log-ip-options --log-tcp-options

That might be a lot of logging; not only is a lot of logging going to give you a lot of log files to look through (and if never look through the log files, because they are too long, what is the point?) but it raises the possibility of a denial of service attack by overloading the logging mechanism. Maybe look at rate limiting here and just silently drop packets if an easily feasible rate is exceeded.

GrapefruiTgirl · 12-07-2009, 02:29 PM

@ mrmnemo -- please consider not using those terrible colors in code postings

or choosing colors that are in high contrast to the background; the yellow is nearly impossible to read!

Sasha

PS :

Quote:

Originally Posted by salasi

- mac address filtering, while quite powerful, always seems like building a predictable maintenance problem into your script, and so should be avoided (imho) unless, to achieve the functionality that you need, there is no sensible alternative.

Indeed, a powerfull tool is mac address filtering. I'm curious @ salasi, what the "predictable maintenance problem" means?
I have mac address filtering in my firewall, and actually used it regularly; when using our firewall box to masquerade for the LAN, I made the outgoing connection rules match the source machine by MAC+IP; the main reason was in case somebody managed to hijack a wireless connection from our wireless router on the LAN, and use our internet. With MAC+IP matching, a machine that managed to get into our wireless, would not be able to get to the internet.

I know it works well, because when the roommate occasionally switched wireless NICs, she could no longer get to the net until I added rules for the new NIC (maybe this is the predictable maintenance?)

Cheers

Sasha

mrmnemo · 12-07-2009, 03:14 PM

so after what you guys said i thought i would try to make things a little more interactive. as far as i can tell : user input=function call:: so then i thought i would try to look for basic distro sigs(starting with slack) see code

Code:

{
echo "1. slackware"
echo "2. Exit"

echo "Enter your distro choice: "
read choice

case $choice in
    1) function slacky     
       ;;
    2) exit
       ;;
esac
}

function slacky{
if [ -f etc/slackware-version ]
  then
    echo "You appear to be running slackware"
    echo "Creating firewall in /etc/rc.d/rc.firewall..."
    sleep 2
    $mkdir /etc/rc.d/rc.firewall     
 
}

i will pipe using sed to rc.firewall after setting some user defined services ( i think). but i keep getting an error that command slaky cant be found!! according to all the googlein and stuff i have set my function up correctly. i have seen 2 examples of creating a function 1> actually calls function then says name of( as in the above code) the other is function name followed by { function commands}. it just keeps breaking.

Funny...all i wanted was a firewall script which seems to have turned into a scripting slash bash prompt slash iptables slash lesson in social entropy

GrapefruiTgirl · 12-07-2009, 04:45 PM

For a function, do like:

Code:

some_name () {

..code here.

.. more code..
}

The two () are needed, but you can't put anything in them.

As for identifying a distribution (which is not always cut & dried) try looking for /etc/*version or /etc/*release and grabbing the distro name out of that. Doing this is fine, but if you plan on making the script do different things depending on what distro is being used, that adds a bunch of extra code. It might be easier to include instructions with your script, telling users of XXX distro, what to do with your script.

Sasha

PS - any function must be DEFINED, before it is called. Try to define all your functions nearer to the top of the script; this way, when the code below actually needs to call it, bash knows what you're telling it do to. A script is run line by line, rather than all read in, interpreted, then executed.

salasi · 12-07-2009, 05:37 PM

Quote:

Originally Posted by GrapefruiTgirl

Indeed, a powerfull tool is mac address filtering. I'm curious @ salasi, what the "predictable maintenance problem" means?

Every time the mac address of something changes, you'll have to go back into your script and fix it (or spoof the mac address, I suppose...although I wonder whether anyone who frequently spoofs mac addresses will have that much confidence in this as a security feature). Now with a couple of laptops, where no one is going to change the network card, you may be happy to do that. If you have machines coming in and out, or the network cards get swapped, this will rapidly become a pain and you'll wish that you had done something else.

And, I suspect, even if you only swap machines infrequently, you'll forget about the problem, swap machines, have the problem with the new machine, and swear a bit when you realise what has happened and wonder why you didn't anticipate that this would happen.

Sorry, I consider all that predictable, but whether you consider it a big problem or just one of life's little irritations is up to you.

salasi · 12-07-2009, 05:45 PM

Quote:

Originally Posted by mrmnemo

so then i thought i would try to look for basic distro sigs(starting with slack)

Sorry, it is entirely up to you, but I don't see the point in this bit of code: you select a distro (with grub, or something) and run it. when whichever distro runs, you run through its startup files and those start the appropriate firewall config. Job done?

Quote:

Funny...all i wanted was a firewall script which seems to have turned into a scripting slash bash prompt slash iptables slash lesson in social entropy

Don't get me wrong; I have sympathy and apologise for anything I've done that has made matters worse.