UNIX for Advanced & Expert Users

Hello,

I have implimented a dansguardian system using dansguardian and privoxy. I borrowed a script from Ubuntu CE that makes it where a firewall program like firehol is not needed and it doesn't need a reconfigure of the proxy settings in browsers to be changed. I really like it that way. All is working well from that standpoint. I want to fully understand HOW it works on the iptables rules, though. I have most of it. Included is the code from my /etc/init.d/dansguardian_firewall init routine. Above this, I am going to make comments and ask questions. What I ask is for someone to help me understand fully how it works, esp the postrouting nat and output nat rules that are the business end of sending all web requests to localhost where it can be managed by Dansguardian.

# I understand this flushes any -t filter rules

iptables -F

# This removes any user-created chains in -t filter

iptables -X

# This flushes any -t nat chain rules

iptables -t nat -F

# This removes and user-created -t nat chains

iptables -t nat -X

# This flushes -t mangle

iptables -t mangle -F

# This removes user-created -t mangle chains

iptables -t mangle -X

# This sets the firewall policies on FORWARD to accept, not sure what FORWARD does. Any explaination would be appreciated.

iptables -P FORWARD ACCEPT

# This sets the firewall policy to accept all outbound traffic

iptables -P OUTPUT ACCEPT

# Here is where I start having a lot of trouble. What is the postrouting mean verses prerouting, etc? What is the -t nat doing actually? Is -o because it is being directed to localhost (127.0.0.1). I understand -p tcp that this limits it to the tcp protocol (not UDP or both). --dport is short for -m tcp --dport 8080 to cause it to direct it to port 127.0.0.1:8080 where dansguardian is listening. What is -j SNAT --to 127.0.0.1 exactly doing? How is it directing to localhost in the first place? Why does it go on POSTROUTING instead of OUTPUT?

iptables -A POSTROUTING -t nat -o lo -p tcp --dport 8080 -j SNAT --to 127.0.0.1

# This is saying to make request not by root and not to 127.0.0.1 to route port 80 direct to localhost 8080 where dansguardian is listening, right? Further elaboration is appreciated. If this is so, it would make more sense to me to have this rule before the previous rule. Does it matter? If so, why? Why is it on OUTPUT and not POSTROUTING?

iptables -A OUTPUT -t nat ! -d 127.0.0.1 -p tcp --dport 80 -m owner ! --uid-owner root -j REDIRECT --to-ports 8080

# Sets the policy on incoming connects to DROP (modified by the rules below)

iptables -P INPUT DROP

# This makes inbound request to localhost accepted. Why is this necessary? If this isn't included, then web sites won't load. I'm sure it has to do with dansguardian working over localhost, but please give me a more full understanding.

iptables -A INPUT -i lo -j ACCEPT

# Here is something I really don't undrstand. If this rule isn't included, allowed and blocked web sites won't load. I removed the RELATED, and it still loaded. I removed just the ESTABLISHED, and it wouldn't load. What is it that is established that it is accepting? Much elaboration needed here.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#I wrote many of these rules below and understand why they work. It is looking for new connect attempts to those ports that are needed for various services (I dn't run a web or mail server, so I don't leave those open).

## Open port for ssh server (22), web server (80), and mail server (25)
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
#iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
#iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT

## Uncomment below to open NSF port, edit the port accoring actual setting
iptables -A INPUT -p tcp --dport 111 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 111 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 2049 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 2049 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 4045 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 4045 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 32771 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 32771 -m state --state NEW -j ACCEPT
## Open ports for NSF end

#Accept Ping request
iptables -A INPUT -p icmp -j ACCEPT

## Drop other packets, Logging, and closing firewall.

#What is this rule actually doing?

iptables -A INPUT -d 255.255.255.255/0.0.0.255 -j DROP

#What is this rule actually doing?

iptables -A INPUT -d 224.0.0.1 -j DROP

#What is this rule actually doing?

iptables -A INPUT -j LOG

#What is this rule actually doing?

iptables -A INPUT -j REJECT

Further explaination is much appreciated.

Kind Regards,
Narnie

Code:

#!/bin/bash
### BEGIN INIT INFO
# Provides: dansguardian_firewall
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: firewall
# Description: Start, stop or reload firewall.
### END INIT INFO
#cat /etc/init.d/dansguardian_firewall

set -e

case "$1" in
start)
echo -e "\nStarting Ubuntu CE firewall .....\n"
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A POSTROUTING -t nat -o lo -p tcp --dport 8080 -j SNAT --to 127.0.0.1
iptables -A OUTPUT -t nat ! -d 127.0.0.1 -p tcp --dport 80 -m owner ! --uid-owner root -j REDIRECT --to-ports 8080
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

## Open port for ssh server (22), web server (80), and mail server (25)
iptables -A INPUT -p tcp --dport 50505 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT

## Uncomment below to open NSF port, edit the port accoring actual setting
iptables -A INPUT -p tcp --dport 111 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 111 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 2049 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 2049 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 4045 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 4045 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 32771 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 32771 -m state --state NEW -j ACCEPT
## Open ports for NSF end

#Accept Ping request
iptables -A INPUT -p icmp -j ACCEPT

## Drop other packets, Logging, and closing firewall.
iptables -A INPUT -d 255.255.255.255/0.0.0.255 -j DROP
iptables -A INPUT -d 224.0.0.1 -j DROP
iptables -A INPUT -j LOG
iptables -A INPUT -j REJECT
;;

stop)
echo -e "\nFlushing firewall and setting default policies to ACCEPT\n"
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
;;

status)
echo "FILTER POLICY"
iptables -L
echo ; echo "NAT POLICY"
iptables -t nat -L
;;

restart|force-reload)
$0 stop
$0 start
;;
*)
echo "Usage: /etc/init.d/ubuntu_ce_firewall {start|stop|restart|force-reload|status}"
exit 1
;;
esac

I probably could answer most of your questions, but what you really ought to do is simply read the iptables man pages. It has most of the answers you seek. For instance, concerning ESTABLISHED versus RELATED, it states:

Code:

   state
       This module, when combined with connection tracking, allows access to the connection tracking state for this packet.

       [!] --state state
              Where state is a comma separated list of the connection states to match.  Possible states are INVALID meaning that the packet could not be identi-
              fied for some reason which includes running out of memory and ICMP errors which don't correspond to any known connection, ESTABLISHED meaning that
              the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connection, or
              otherwise  associated  with a connection which has not seen packets in both directions, and RELATED meaning that the packet is starting a new con-
              nection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.

I had read the man pages. I always try to glean what I can out of them and other documentation and googling first. If you will notice my question, I was getting what seemed like odd behaviour. I also didn't know what I didn't know so I didn't have a base to understand many things. Since then, I have devoured reading all kinds of tips and tutorial on TCP/IP, etc. The problem on the RELATED,ESTABLISHED rule was that if I tested without the firewall, I was already connected with a page refresh. Then when I enabled the firewall, it let things go through that it shouldn't have. If I let the connection time out, then it works fine.

The manual doesn't explain things like how and why you want these type of rules:

Code:

-A OUTPUT -d 127.0.0.1 -p tcp --dport 8118 -m owner ! --uid-owner dansguardian -j DROP
-A POSTROUTING -t nat -o lo -p tcp --dport 8080 -j SNAT --to 127.0.0.1
-A OUTPUT -t nat ! -d 127.0.0.1 -p tcp --dport 80 -m owner ! --uid-owner root -j REDIRECT --to-ports 8080

and why you need:

Code:

-A INPUT -d 255.255.255.255/0.0.0.255 -j DROP
-A INPUT -d 224.0.0.1 -j DROP

and why REJECT instead of drop in:

Code:

-A INPUT -j REJECT

I understand why now after a lot of reading and help from more helpful forums who say more than just "read the man page."

I feel that too many people assume that if you are having problems, that it is just because you didn't read the man pages, etc. Sometimes it is just that there are knowledge deficits the prevent the pieces from coming together. What is needed is for people to help fill in the gaps of this knowledge and mentor rather than simply quote the man page.

Regards,
Narnie

I understand your objection to being given a very general answer, but as your post had gone unanswered after 2 weeks, it made little sense to give a very long response in case you had since solved the problem. Also, as I was posting from my iPhone, i couldn't give you more than a general response.

Here's one visual aid but I prefer this one. These should give you a better idea of the distinction between POST/PRE-ROUTING, etc.

Code:

#1
-A OUTPUT -d 127.0.0.1 -p tcp --dport 8118 
       -m owner ! --uid-owner dansguardian -j DROP
#2
-A POSTROUTING -t nat -o lo -p tcp --dport 8080 -j SNAT --to 127.0.0.1
#3
-A OUTPUT -t nat ! -d 127.0.0.1 -p tcp --dport 80 
       -m owner ! --uid-owner root -j REDIRECT --to-ports 8080

#4
-A INPUT -d 255.255.255.255/0.0.0.255 -j DROP
#5
-A INPUT -d 224.0.0.1 -j DROP
#6
-A INPUT -j REJECT

For #1,
I have no idea what dansguardian is doing, but this rule will drop any packet sent to the loopback interface and port 8118 that is not from a process owned by dansguardian.

For #2 / #3, It looks like port 8080 is some sort of proxy server for all outbound "typical HTTP" traffic (unless you're running as root, in which case it's not proxied). #4 instructs to redirect all traffic to the service on port 8080 on the loopback interface, and #3 tells it to spoof the packets as if they were really supposed to go there in the first place. (Otherwise, the listening interface would not see packets for 127.0.0.1 but for their original destination, which it's not listening for.)

For #4
I'm not sure, but anything to 255.255.255.xxx is dropped. Normally that's a broadcast from ill-behaved equipment.

For #5, that's multicast it's dropping.

For #6 REJECT vs DROP - That's just an issue of preference. REJECT will result in an icmp packet sent back to the sender indicating the packet has not been accepted. DROP simply ignores the packet and no further action is taken.

I do appreciate your following up on this.

I have learned a lot since the original post. There still are gaps, however.

#1 above prevents a person from just putting 127.0.0.1:8118 into their browser proxy settings and effectively bypassing dansguardian filtering. Although I didn't know what it was doing before, it was I nice little tip I learned from using dansguardian with firehol.

#2 another forum said that there can be other broadcasts regarding localhost that are NOT from 127.0.0.1 and this rule changes it to the loopback address. My system works without this line, so I'm not 100% sure what this is trying to do. I know WHAT it is doing, but not the rationale why. Perhaps it prevents some kind of circular routing since only 127.0.0.1 traffic is allowed dport 80 traffic all other is redirected to 8080 where dansguardian is listening so it can do the content filtering but there may be some legit lo traffic on another ip#.

#4 is dropping broadcast packets, but I'm not exactly sure where those would come from. #4 and #5 I have found on other sites that on networks with Windows systems on them, there will be a lot of broadcast and multicast packets on them that will hog the logs, so it just drops them. Does this make since? If not, other explainations are welcome. Not sure what Windows is doing here, but it seems to be in some of the "best practices" info on firewall building.

#6 I understand the difference, but wonder why sometimes things are just dropped (and therefore silent) and if everything makes it through the rules to this point, it might be chosen to use are REJECT and thus send back a TCP RST packet alerting them that they got a "live" system. Just curious on this one.

Older versions of MS Messenger spam broadcast messages continuously.

I don't see why the firewall needs to care about this either. That's often why things are DROPped instead of REJECTed, yes.

Some firewalls even have a 'tarpit' sort of thing to dump known-hostile connections into. Tarpitted hosts get just enough response from the server to think they've connected, but they haven't. Tarpitted connections still take the usual ten minutes timeout before dying. I think it's a strategy against DDOS.

Did you look at the flowchart/visuals i linked to?