Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
That output is really difficult to read (not your fault, iptables just has horrible syntax), but what I don't see is a rule that allows all RELATED traffic back in. What you should do is allow either a) all outbound traffic (from your host, to the Internet) and keep track of state, or b) if denying outbound by default, allow outbound to tcp, udp to dport 53 and keep track of state. The rule to allow RELATED traffic back in should allow the responses.
I hope someone rewrites iptables to be readable one of these days. It should at least be as good as PIX or ipfw, and preferably natural language like pf. How they could mangle up the syntax and output so baddly with several good examples of useful syntax availble, I don't know.
guys, I am not having any luck with modifying iptables. Here's the current iptables file in /etc/sysconfig (chort, if there is a way to produce a format that is easier to read, let Me know and I'll gladly use that way):
:INPUT ACCEPT [11:2940]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5577:292136]
:RH-Lokkit-0-50-INPUT - [0:0]
-A INPUT -j RH-Lokkit-0-50-INPUT
-A FORWARD -j RH-Lokkit-0-50-INPUT
* this is the line I added to allow related traffic back in
-A RH-Lokkit-0-50-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Lokkit-0-50-INPUT -i lo -j ACCEPT
-A RH-Lokkit-0-50-INPUT -s 192.168.0.1 -p udp -m udp --sport 53 -j ACCEPT
* these 2 lines are supposed to allow DNS traffic from the ethernet port
-A RH-Lokkit-0-50-INPUT -s 192.168.0.111 -p udp -m udp --dport 53 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -s 192.168.0.111 -p tcp -m tcp --dport 53 -j ACCEPT
* these 2 lines are supposed to allow DNS traffic from internal procs (i.e. dig)
-A RH-Lokkit-0-50-INPUT -s 127.0.0.1 -p udp -m udp --dport 53 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -s 127.0.0.1 -p tcp -m tcp --dport 53 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
-A RH-Lokkit-0-50-INPUT -p udp -m udp -j REJECT --reject-with icmp-port-unreachable
in addition to correcting My obvious lack of understanding, I would appreciate any recommendations where an obviously clueless DBA can learn something about iptables
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Well it *looks* right--you're allowing ESTABLISHED,RELATED, and also allowing outbound packets to port 53. Obviously there is some subtle iptables quirk that I'm missing.
Just from a correctness standpoint, I would recommend ditching Lokkit and either rolling your own script from scartch, or using one of the GUI tools (such as Guarddog, fwbuilder, or Firestarter). Lokkit just has a very dumb way of setting up rules that is completely the opposite of how firewalls are supposed to be constructed.
I recommend you check out the netfilter/iptables references in the stickied post over on the Security forum. I think it's called Security References (or maybe Resources). There's a gigantic list of HOW-TOs, etc.
Chort thanks for the info. I guess I'm trying to stay as close to the "out of the box" condition of Red Hat as I can untill I am confident in MY understanding, but it would probably pay in the long run to venture out a bit on this one.
BTW, do you know any way to "trace" a packet through the firewall rules so you can see how each rule affects the way netfilter deals with it ?
Surely the DBA gods are visiting their wrath upon Me for My many sins...
Today I simply tried it all over again, and everything is working. There was one behavioral difference that probably explains it.
Prior to today, /etc/init.d/iptables restart produced only one line of response:
Flushing all current rules and user defined chains: [OK]
Today, after the response above, 2 additional lines appeared:
Clearing all current rules and user defined chains: [OK]
Applying iptables firewall rules: [OK]
so..it appears that iptables was not cleanly restarting and was not in a predictable state. I am unable to account for this change in behavior without references to continental drift, phases of the moon, undocumented alterations in the speed of light, or unexplained perturbations in entropy.
Now dig seems perfectly happy talking to My DNS server, the sun is shining, the air is brisk and cool, and this DBA is, as usual, confused and clueless but noding His head pretending He is completly aware of and in control of all things. That must be My cue to brew some more Chai Tea.