Jason,
Thank you very much for your help. I appreciate the time you have taken to
help me out with my domain problem. I will most definitely check out the
BoingWorld tutorial.
I understand what you are saying about UDP being a connectionless protocol.
That being the case, my rule allowing all established and related connections
through probably fixed a bug with my rules allowing incoming and outgoing TCP
domain packets I did not know I had. Perhaps that was the whole problem all
along.
I had already added the incoming and outgoing TCP rules for domain.
When I typed " iptables -L" it would instantly give me the list, but with IP
numbers not the resolved names. I figure that when iptables tried to resolve
the IP's it received an instant error because the initial UDP packet was being
dropped. When I opened that port up and then tried to list my rules, it did
not get an instant error. Iptables sat there until the DNS request timed out
because my tcp rule was not working for whatever reason.
That said, NONE of my rules are working, (except name resolution). It's
back to the drawing board for me. I will definitely read up on BoingWorld so I
can try and figure out what I'm doing wrong. (I spent a day on creating my
rules and THEN remembered that I had to explictly set -j ACCEPT. Thankfully,
I created them in an executable text file so it was an easy fix.) :) I'm
sure that my whole ssh and ftp problem is that they do not always listen on
port 23, 20, or 21 respectively.
Have you ever noticed that the more you learn, the more you realize how much
you don't know?
Janet Post
[EMAIL PROTECTED]
>>> Jason Healy <[EMAIL PROTECTED]> 04/19 9:37 PM >>>
At 987720434s since epoch (04/19/01 17:47:14 -0400 UTC), Janet Post wrote:
> iptables -I INPUT 1 -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> This allows ALL connections that have been established or are related
> though. In your discription, you describe something much more strict.
> Is it possible to exploit that, or should I close it off more like you
> have in your chain rules?
If I understand correctly, the state tracking code only works with TCP
connections. UDP is a stateless; that is, it has no concept of a
'connection'. The iptables code may do something sneaky to fake a
connection with UDP (I think the BSD ipf code does this), but if it does,
then it's news to me (someone correct me if it does, because that would be
really cool).
So part one of my answer is, that code is not enough, because it doesn't
affect UDP. Again, somebody tell me if I'm wrong, because stateful UDP
filtering would rock.
On to part two: the code allows all accepted or ongoing connections. This
does not open any holes, as it is only allowing your machine to accept
packets that it recognizes. For example, if you telnetted out of your
firewall box to another machine, then the return packets (from the other
machine back to you) would be recognized as belonging to an ongoing
connection and so would be accepted. This is a Good Thing(tm), because you
don't have to open up any ports on your machine for return connections
(compare this to ipchains under 2.2.x where you had to open ports over 1024
to get return packets).
Anyway, that line won't get you in any trouble. Note however that there was
a bug discovered in the iptables code this week that exploits a problem with
the ESTABLISHED,RELATED stuff, so you should patch your kernel!
My rules are more complicated because they also check for inbound
connections (that is, other people initiating a connection to your box). If
you don't run any public services on your box, then you're fine; you need
only accept connections that you have initiated. If you run services that
need to be guarded then the rules get a little more complex. Again, the
BoingWorld tutorial is most definitely your friend.
Best of luck,
Jason
--
Jason Healy | [EMAIL PROTECTED]
LogN Systems | http://www.logn.net/
