How iptables directs to localhost in this series of iptable rules
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?
# 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
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:
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:
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:
and why you need:
and why REJECT instead of drop in:
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.
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.
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.
Last edited by otheus; 11-03-2011 at 11:07 AM..
Reason: typo
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.
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.
#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.
Older versions of MS Messenger spam broadcast messages continuously.
I don't see why the firewall needs to care about this either.
Quote:
#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.
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.
Hi, I am relatively new to firewalls and netfilter. I have a Debian Stretch router box running dnsmasq, connected to a VPN. Occasionally dnsmasq polls all of the desired DNS servers to select the fastest. When it does this it responds to replies of the non-selected DNS servers with a icmp type... (0 Replies)
Hello,
I did 2 scripts. The second one is, I hope, more secure.
What do you think?
Basic connection (no server, no router, no DHCP and the Ipv6 is disabled)
#######script one
####################
iptables -F
iptables -X -t filter
iptables -P INPUT DROP
iptables -P FORWARD... (6 Replies)
Hi,
I've been struggling with this all morning and seem to have a blind spot on what the problem is. I'm trying to use iptables to block traffic on a little cluster of raspberry pi's but to allow ssh and ping traffic within it.
The cluster has a firewall server with a wifi card connecting to... (4 Replies)
Hi there,
I have a VPS and am working on a little side project for myself and friend which is a DNS proxy. Everything was great till recently. My VPS IP has been detected by some botnet or something, and I believe SMURF attacks are occuring. The VPS provider keeps shutting down my VPS... (3 Replies)
Hi all,
Exactly like my title says.
I am learning PHP and MySQL and I used to use /var/www/ to host (contain or store) my files (.htm/.php) for testing. I could configure, finally, apache2 to use ~/public_html instead.
Now I when I tried to use $_SERVER it still directs (I used echo to show... (7 Replies)
Hi Champs
i am new in Iptables and trying to write rules for my Samba server.I took some help from internet, created one script and run from rc.local :
#Allow loopback
iptables -I INPUT -i lo -j ACCEPT
# Accept packets from Trusted network
iptables -A INPUT -s my-network/subnet -j... (0 Replies)
Could someone help me with writing rules for iptables?
I need a dos attacks protection for a game server.
port type udp
ports 27015:27030
interface: eth0
Accept all packets from all IPs
Chek if IP sent more than 50 packets per second
Drop all packets from this IP for 5 minutes
I would be... (0 Replies)
Hello,
I was playing around with iptables to setup an isolated system. On a SLES10 system, I ran the below to setup my first draft of rules. I noticed that the rules come into effect immediately and do not require any restart of iptables.
iptables -A INPUT -j ACCEPT
iptables -A OUTPUT -m... (4 Replies)
Hi
I have small home network and I want to block some forums on web
When I use this
iptables -A INPUT -s forum -j DROP
rules is applied but when I restart some of PC rules are not present any more also I tried to save firewall settings
iptables-save > /root/dsl.fw
but how to... (2 Replies)