# Critique my firewall setup and some questions.

## Antimatter

Okay here's the script to setup my firewall, but once its setup I usually use iptable save and restore because this server is on an static IP connection right now, thus the IP address can be static in the firewall rule set itself.

Anyway I'm trying to provide as tight of a firewall as possible, it controls what is allowed in and what is allowed out.  At the moment the only thing that is allowed in is SSH port, and I'll sooner/later setup a port knocking daemon to open up SSH port only to that machine that initialized the port knocking.  Anyway my question is all of my logging and packet filtering really needed.  I'm thinking it maybe better off to just flat out Deny everything coming in that isn't related with something that is outgoing.  And then setup port knocking to open up the SSH port to that machine only.

```

# TODO: Implement portknocking, and DoS/SYN flooding protection on the firewall, while allowing

# important interial services to be accessable on the outside or the inside being able to access

# the outside services even being DoS/SYN flooded, Also need to analyize the difference between 

# "--tcp-flags SYN,RST,ACK SYN" and "--syn" to make sure that it will be the same results

#!/bin/bash

##############################################################

#

# Configation Options

#

##############################################################

# External interface

EXTIF='eth0'

# Loop device/localhost

LPDIF=lo

LPDIP=127.0.0.1

LPDMSK=255.0.0.0

LPDNET="$LPDIP/$LPDMSK"

# Text tools variables

IPT='/sbin/iptables'

IFC='/sbin/ifconfig'

G='/bin/grep'

SED='/bin/sed'

# Setting up external interface environment variables - DHCP

#EXTIP="`$IFC $EXTIF|$G addr:|$SED 's/.*addr:\([^ ]*\) .*/\1/'`"

#EXTBC="`$IFC $EXTIF|$G Bcast:|$SED 's/.*Bcast:\([^ ]*\) .*/\1/'`"

#EXTMSK="`$IFC $EXTIF|$G Mask:|$SED 's/.*Mask:\([^ ]*\)/\1/'`"

#EXTNET="$EXTIP/$EXTMSK"

#echo "EXTIP=$EXTIP EXTBC=$EXTBC EXTMSK=$EXTMSK EXTNET=$EXTNET"

# Setting up external interface environment variables - STATIC IP

EXTIP="192.168.1.10"

EXTBC="192.168.1.255"

EXTMSK="255.255.255.0"

EXTNET="$EXTIP/$EXTMSK"

echo "EXTIP=$EXTIP EXTBC=$EXTBC EXTMSK=$EXTMSK EXTNET=$EXTNET"

# Allowed services  - For exterial users to access this machine with

TCPIN="ssh"

UDPIN=""

ICMPIN="8"  # Unreachable resource = 3, Ping = 8, TTL is zero during transit/reassembly = 11

# Allowed services - For interial users to acess the net with

TCPOUT="rsync http https ftp ftp-data"

UDPOUT="ntp domain"

ICMPOUT="3 8 11"  # Unreachable resource = 3, Ping = 8, TTL is zero during transit/reassembly = 11

##############################################################

#

# Rules Setup

#

##############################################################

#

# Default Policies - Drop then accept

#

$IPT -P INPUT    DROP

$IPT -P OUTPUT   DROP

$IPT -P FORWARD  DROP

#

# Flush all existing chains and erase personal chains

#

CHAINS=`cat /proc/net/ip_tables_names 2>/dev/null`

for i in $CHAINS;

do

    $IPT -t $i -F

done

                                                                               

for i in $CHAINS;

do

    $IPT -t $i -X

done

##############################################################

#

# Create userdefined chains

#

##############################################################

#

# Create a log then drop chain

#

$IPT -N DROP_l 2> /dev/null

$IPT -A DROP_l -m limit --limit 5/minute -j LOG --log-level notice --log-prefix 'DROP-LOG:'

$IPT -A DROP_l -j DROP

#

# Create a log then reject chain

#

$IPT -N REJECT_l 2> /dev/null

$IPT -A REJECT_l -m limit --limit 5/minute -j LOG --log-level info --log-prefix 'REJECT-LOG:'

$IPT -A REJECT_l -j REJECT --reject-with icmp-host-prohibited

#

# Create a log then drop chain - customized for portscan

#

$IPT -N PORTSCAN_l 2> /dev/null

$IPT -A PORTSCAN_l -m limit --limit 5/minute -j LOG --log-level warning --log-prefix 'PORTSCAN-LOG:'

$IPT -A PORTSCAN_l -j DROP

###########################

# Bad TCP Filtering chains

###########################

#

# Bad TCP Connection chain - for filtering/logging bad tcp connection

#

$IPT -N BTC 2> /dev/null

$IPT -A BTC -p tcp -m state --state INVALID -j DROP_l

# Stops "new connection" without the "SYN" flag set

#$IPT -A BTC -p tcp ! --syn -m state --state NEW -j DROP_l

$IPT -A BTC -p tcp ! --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j DROP_l

# Stops the middleman attack, where a machine somehow knocks this machine out and use

# its ip address/sequence number in an attack on another host, however by sending a

# TCP RST packet to that other host it will shutdown the middleman attack

$IPT -A BTC -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -m limit --limit 5/minute -j LOG --log-level warning --log-prefix 'MIDMAN:'

$IPT -A BTC -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset

#

# Bad TCP Flag chain - for filtering/log bad flag combitation on an TCP packet,

#              usualy a sign of someone portscanning this machine

#

$IPT -N BTF 2> /dev/null

# Null scan (nmap -sN)

$IPT -A BTF -p tcp --tcp-flags ALL NONE -j PORTSCAN_l

# Xmas scan

$IPT -A BTF -p tcp --tcp-flags ALL ALL -j PORTSCAN_l

# Nmap-xmas scan (nmap -sX)

$IPT -A BTF -p tcp --tcp-flags ALL FIN,URG,PSH -j PORTSCAN_l

# Nmap-xmas-psh scan

$IPT -A BTF -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j PORTSCAN_l

# SYN-RST scan

$IPT -A BTF -p tcp --tcp-flags SYN,RST SYN,RST -j PORTSCAN_l

# SYN-FIN scan

$IPT -A BTF -p tcp --tcp-flags SYN,FIN SYN,FIN -j PORTSCAN_l

# FIN scan (nmap -sF)

$IPT -A BTF -p tcp --tcp-flags FIN,ACK FIN -j PORTSCAN_l

# Invaild combation

$IPT -A BTF -p tcp --tcp-flags ACK,URG ACK,URG -j PORTSCAN_l

###############################################

# Inbound Connections - Per service/port basis

###############################################

#

# Allowed TCP Connection Inbound - TCP connection that are allowed that are inbound

#

echo -n "FW: Allowing outside systems to use service (TCP):"

$IPT -N TCPIN 2> /dev/null

for i in $TCPIN;

do   echo -n "$i "

   $IPT -A TCPIN -p tcp --dport $i -m state --state NEW -j ACCEPT

done

echo ""

#

# Allowed UDP Connection Inbound - UDP connection that are allowed that are inbound

#

echo -n "FW: Allowing outside systems to use service (UDP):"

$IPT -N UDPIN 2> /dev/null

for i in $UDPIN;

do

   echo -n "$i "

   $IPT -A UDPIN -p udp --dport $i -m state --state NEW -j ACCEPT

done

echo ""

#

# Allowed ICMP Connection Inbound - ICMP connection that are allowed that are inbound

#

echo -n "FW: Allowing outside systems to use service (ICMP):"

$IPT -N ICMPIN 2> /dev/null

for i in $ICMPIN;

do

   echo -n "$i "

   $IPT -A ICMPIN -p icmp --icmp-type $i -m state --state NEW -j ACCEPT

done

echo ""

################################################

# Outbound Connections - Per service/port basis

################################################

#

# Allowed TCP Connection Outbound - TCP connection that are allowed that are outbound

#

echo -n "FW: Allowing iuside systems to use service (TCP):"

$IPT -N TCPOUT 2> /dev/null

for i in $TCPOUT;

do

   echo -n "$i "

   $IPT -A TCPOUT -p tcp --dport $i -m state --state NEW -j ACCEPT

done

echo ""

#

# Allowed UDP Connection Outbound - UDP connection that are allowed that are outbound

#

echo -n "FW: Allowing inside systems to use service (UDP):"

$IPT -N UDPOUT 2> /dev/null

for i in $UDPOUT;

do

   echo -n "$i "

   $IPT -A UDPOUT -p udp --dport $i -m state --state NEW -j ACCEPT

done

echo ""

#

# Allowed ICMP Connection Outbound - ICMP connection that are allowed that are outbound

#

echo -n "FW: Allowing inside systems to use service (ICMP):"

$IPT -N ICMPOUT 2> /dev/null

for i in $ICMPOUT;

do

   echo -n "$i "

   $IPT -A ICMPOUT -p icmp --icmp-type $i -m state --state NEW -j ACCEPT

done

echo ""

##########################################################################

# Inbound Acceptance - Setup the order of tests and filters to be applied

#             on an inbound connection

##########################################################################

#

# Setup TCP Inbound Acceptance chain

#

$IPT -N TIA 2> /dev/null

# Bad TCP Flag check

$IPT -A TIA -p tcp -j BTF 

# Bad TCP Connection check

$IPT -A TIA -p tcp -j BTC

# Accept Established and Related TCP connection

$IPT -A TIA -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept Outside's inbound new connections

$IPT -A TIA -p tcp -j TCPIN

#

# Setup UDP Inbound Acceptance chain

#

$IPT -N UIA 2> /dev/null

# Bad UDP Connection check

$IPT -A UIA -p udp -m state --state INVALID -j DROP_l

# Accept Established and Related UDP connection

$IPT -A UIA -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept Outside's inbound new connections

$IPT -A UIA -p udp -j UDPIN

#

# Setup ICMP Inbound Acceptance chain

#

$IPT -N IIA 2> /dev/null

# Bad ICMP Connection check

$IPT -A IIA -p icmp -m state --state INVALID -j DROP_l

# Accept Established and Related UDP connection

$IPT -A IIA -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept Outside's inbound new connections

$IPT -A IIA -p icmp -j ICMPIN

###########################################################################

# Outbound Acceptance - Setup the order of tests and filters to be applied

#              on an outbound connection

###########################################################################

#

# Setup TCP Outbound Acceptance chain

#

$IPT -N TOA 2> /dev/null

# Bad TCP Flag check

$IPT -A TOA -p tcp -j BTF 

# Bad TCP Connection check

$IPT -A TOA -p tcp -j BTC

# Accept Established and Related TCP connection

$IPT -A TOA -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept Outside's inbound new connections

$IPT -A TOA -p tcp -j TCPOUT

#

# Setup UDP Outbound Acceptance chain

#

$IPT -N UOA 2> /dev/null

# Bad UDP Connection check

$IPT -A UOA -p udp -m state --state INVALID -j REJECT_l

# Accept Established and Related UDP connection

$IPT -A UOA -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept Outside's inbound new connections

$IPT -A UOA -p udp -j UDPOUT

#

# Setup ICMP Outbound Acceptance chain

#

$IPT -N IOA 2> /dev/null

# Bad ICMP Connection check

$IPT -A IOA -p icmp -m state --state INVALID -j REJECT_l

# Accept Established and Related UDP connection

$IPT -A IOA -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept Outside's inbound new connections

$IPT -A IOA -p icmp -j ICMPOUT

##############################################################

#

# Apply Userdefined Chain - Apply the user defined chains 

#             above to the main INPUT, OUTPUT, 

#             etc... firewall chain

#

##############################################################

#

# Setup the Inbound Firewall Ruleset Chain

#

# Block WAN access to inside network

# Designed to help prevent spoofing attempts

$IPT -A INPUT -i $EXTIF -d ! $EXTIP -j DROP_l

# Block Inbound Broadcasting

$IPT -A INPUT -i $EXTIF -d $EXTBC -j DROP

# Accept all traffice from loopback device - only if IP matches our interfaces

$IPT -A INPUT -i $LPDIF -s $LPDIP -j ACCEPT

$IPT -A INPUT -i $LPDIF -s $EXTIP -j ACCEPT

# Setup the TCP, UDP, ICMP Inbound connections

$IPT -A INPUT -i $EXTIF -d $EXTIP -j TIA

$IPT -A INPUT -i $EXTIF -d $EXTIP -j UIA

$IPT -A INPUT -i $EXTIF -d $EXTIP -j IIA

# Block and log whatever else we may have forgotten

$IPT -A INPUT -j DROP_l

#

# Setup the Outbound Firewall Ruleset Chain

#

# Egress check

$IPT -A OUTPUT -o $EXTIF -s ! $EXTNET -j DROP

# Block Outbound Broadcasting

$IPT -A OUTPUT -o $EXTIF -s $EXTBC -j DROP

# Setup the TCP, UDP, ICMP Inbound connections

$IPT -A OUTPUT -o $EXTIF -s $EXTIP -j TOA

$IPT -A OUTPUT -o $EXTIF -s $EXTIP -j UOA

$IPT -A OUTPUT -o $EXTIF -s $EXTIP -j IOA

# Block and log whatever else we may have forgotten

$IPT -A OUTPUT -j REJECT_l # maybe change to drop later

#

# Setup the Forward Firewall Ruleset Chain

#

$IPT -A FORWARD -j DROP_l

```

----------

## Antimatter

*bump* If anyone want to go ahead and use/modify this firewall source, they're more than free to.  But do so at your own risk, because I have been struggling to try to make an complete testing suit to test the firewall to see if its actually doing its job or not.  The port scan log/drop rules seems to slow down nmap a lots, and cause it to lose quite a bit of packet but it doesn't eliminate it 100% but it did help drop the accuracity of the nmap classifyation.

Anyway I'm not sure what other tests and what other stuff I outta to perform on this firewall, such as testing throughput, but then again its primary for one to five users at max, and it'll be installed on an ancient 233 mhz laptop.  But if it proves to be usable I wouldn't mind constructing a gateway out of this firewall script and add in some additional rules.  It probably will end up installed on an embedded device with 32-64 MB of ram, and 233mhz or higher processors.

----------

## Antimatter

If someone else knows a better forum/website to post my firewall question, point me in that direction? Thanks

----------

## Antimatter

*bump* I guess no one is interested in the firewall script, and no one is interested in directing me to an better forum for these sort of questions,  I've already done google search and checking out usenet on google group and didn't find much other forums for those kind of information.

----------

## magic919

It may sound harsh but ...  Who can be bothered to wade through a lengthy script to work out what the resultant firewall would be?  And what's to be gained by doing so?  There's 101 scripts on the web to produce overly complex firewalls.  I switched off when I saw the script and didn't bother reading on.

If you have a problem with a firewall and some application then I'm sure this is the place.  Stick the output of iptables -L -n -v and people will queue up to help.

----------

## pteppic

He's right, no ones gonna sift through and work out what your variables mean, just post the iptables-save output.

----------

## mgbowman

Or give Shorewall a shot.  It's a much higher-level interface to iptables and I have found it to be way more efficient for maintenance than a simple firewall shell script (even those created by all the various UIs).  If you really want to lock your system down, you better start reading and not expect other people to do it for you.

----------

## chrisruwe

Why bother with a firewall - close the ports which you do not need, those which you will need should't be filtered by your firewall anyway. And most programs using tcp/ip as communication protocol offer configs which addresses to allow and which to deny.

Iy you want your computer tested, try http://webscan.security-check.ch/, use Quick-Scan

----------

## mgbowman

 *chrisruwe wrote:*   

> Why bother with a firewall - close the ports which you do not need, those which you will need should't be filtered by your firewall anyway.

 

Correct me if I am wrong, but don't you close ports via a firewall?  As long as there are no services running on a specific port, then theoretically it is a "closed" port. Without a firewall, most systems are configured to respond with an ICMP port unreachable.  This takes more processing to pass the packet up the stack that if it was filtered at the lower layer by the firewall (i.e. drop all port 22 traffic).  Why would you want you system to attempt to deliver a packet to an active process listening on port 22 (assuming you don't have one running).  Preempt the packet at the lower layer by using the kernel firewall and send no ICMP port unreachable.  Seems more efficient to me.

----------

## Antimatter

magi919:  That's true, didn't think of that.  Now about those 101 scripts out there on the web, how do you know they're written by professional who knows what they are doing, granted some such as shorewall probably knows their stuff better than I do, but some of the other scripts out there I'm not so sure.  But one of my biggest problem with shorewall and other firewall scripts is its needed to learn another pseudo-scripting language and have more dependencies installed on the system, this is going to be an router/gateway/server sort of system.

I guess my main question, is a firewall of this complexity even needed?  Am I going overboard by setting up chains to inspect all of the flags of incoming/outbound tcp/ip packets and log them in case of suspected port scans.  Also I have multiple chains, chained into each others, is this a benefit or disadvantage.  I did some reading and the reading that I did pointed out that iptables is an linear firewall as in that it evaluates rules on a linear basis until it finds one that matches, and that long chains hurts performance.  So I was thinking a few shorter chain that evaluates what they need to and get out ASAP would be better for performance.

pteppic: if there still is any sort of interest i can go ahead and put up the result iptables-save output?

mgbowman: I avoid those sort of interface, because I would have to learn another pseudo-language, and would have to emerge more dependencies onto the router/gateway/server system, and from a lots of the security document it has been hammered to death that you absolutely wants the minimum running on those sort of system to lessen the amount of code available for someone who is using it and/or broke in to use to wreck havoc with the machine.

And I have been doing a lots of reading, but 99% of the stuff I've found are little bit too basic, mainly on the firewall side, I haven't found any real good source explaining what is good and what is not good to implement into the firewall, I did find some great sources explaining iptables commands, and what it can/cannot do and so forth.  But I'm still struggling with finding good document on good standards to test the firewall on, and what is considered a good/bad firewall. Also I acknowledge that the firewall isn't the only line of defense, but its one of the first, so I want to make it as solid as possible before the enemy can actually get though and test the other lines of defense, such as hardened toolchain, and other security features.

chrisruwe:  I think it would be faster to drop/reject the packets that are inbound/outbound than to let it work its way though the network stack, and possibly export an flaw/error in the stack to break the system.  And about testing the computer, I'm building this router/gateway/server on an vmware machine which is behind an router. I'm doing it this way to take advantage of this system's greater processing power for compiling stuff and local access in case of things screwing up, when its done I'll pack it up and export/load it onto the router/gateway/server machine which is an old 233 mhz Pentium II.

mgbowman: It does seem more effective to me and lessen the chance of an stack export wrecking havoc with the system.

----------

## mgbowman

 *Antimatter wrote:*   

> mgbowman: I avoid those sort of interface, because I would have to learn another pseudo-language, and would have to emerge more dependencies onto the router/gateway/server system, and from a lots of the security document it has been hammered to death that you absolutely wants the minimum running on those sort of system to lessen the amount of code available for someone who is using it and/or broke in to use to wreck havoc with the machine.

 

You must understand that Shorewall is simply a much more powerful interface to iptables than a simple shell script.  Shorewall is not a dameon, but yet an executable that simply takes the set of configuration files and generates iptables rules.  The problem with most firewall building UIs is they have a limited set of ways to define rules.  Shorewall is very powerful and highly extensible.

I once had your attitude about psuedo-language/additional dependencies, but iptables has a lot of redundancy as far as the command-line interface is concerned.  The UIs that are available are nothing more than a "point-and-click" shell script which can be a nightmare when scaling a firewall.  I highly recommend you give Shorewall a fair chance and you might be surprised with its advance feature set and ease-of-use.

Just remember, RTFM.

----------

## Antimatter

mgbowman:  Hmm, point taken, but btw I'm making this firewall rule set by hand, I haven't touched any GUI or scripting for firewall, they just feel too limited to me.  But about shorewall I'm right now reading the document, and it does look pretty nice  :Smile:   So thanks for the suggestion, I may give it a shot after I finish reading some of the example scripts for shorewall out there and so forth to see how it appears to handle things. Currently RTFMing as you say  :Smile: 

Thanks, but I still have a question, is it even needed to filter the tcp flags, and filter the bad connection and stuff, is it actually useful and a benefit, or is it an liability in that it slows down the machine too much?  Would it be better to just default reject everything and setup a simple "state RELATED,ESTABLISHED" for the inbound chain, than to filter the inbound/outbound chain for bad tcp flags, bad connection, and so forth.

----------

## mgbowman

 *Quote:*   

> Would it be better to just default reject everything and setup a simple "state RELATED,ESTABLISHED" for the inbound chain, than to filter the inbound/outbound chain for bad tcp flags, bad connection, and so forth.
> 
> 

 

Keep reading through the Shorewall documentation and you'll find the answer  :Smile: .  Make sure you completely understand it and if you have questions I'd be happy to help.  I did as you are doing now and read, and re-read every example I could find.  At the same time, give a look through the configuration files.  They are 99% documentation.  I hope you find the use of Shorewall beneficial.

----------

## magic919

I should say that I wasn't trying to recommend _any_ of the (101) scripts for firewalls and I'd say steer clear.  I like to try to keep the firewall simple and well-structured.  This guy taught me what I use on my servers http://www.pettingers.org/code/firewall.html

I leave off his 'optional' bits on the malformed packets as my machines are generally behind a router anyway.  I'm with you on not emerging further packages to look after iptables for me.

----------

