Thanks for the comments Ramin. I should have been more specific.
I do not limit the outgoing connections at all. Just incoming to the
Firewall Machine.
I absolutely agree with your comments about specifying the
Interfaces specifically in the rules. In fact, a number of people that
have helped me along the way have recommended making the
rules as specific as possible. So that nothing slips through because
the rule is to broad. This makes sense to me, and sure helps when
you are troubleshooting your rules with iptables -v -L. Otherwise it
can be really tough to see what the rule is actually doing, and what
rule is responsible for the table entry. I usually include the rate limits
in the body of a specific rule, and that seems to work well.
Tyler:
Tcpdump is your friend as Ramin suggested, it can help you
see where the packets are being lost. Also Netstat in a DOS window
can be illuminating as well. The other thing I did which helped me out
was a log and drop user table for the INPUT, OUTPUT, and FORWARD
chains, so that I could see if packets were unintentionally being dropped.
A sample is listed below, then just clone it as many times as you want.
You could also make it protocol specific as well. The log prefix makes
them easier to pick out in the logs.
#
#Create an Input Drop Chain
#
$IPTABLES -N drop-log-input
$IPTABLES -A drop-log-input -j LOG --log-level info --log-prefix "FW: INPUT
"
$IPTABLES -A drop-log-input -j DROP
I also agree with Ramin about making up your own rules. Again I would start
with a drop policy and build from there. You could also quickly try an
accept
policy with SNAT/MASQ and forwarding enabled to make sure there isn't some
other problem. However, I have found that tcpdump and the log entries can
usually sort it out without compromising security.
Hope that helps.
Stu..............
-----Original Message-----
From: Ramin Alidousti [mailto:[EMAIL PROTECTED]]
Sent: May 9, 2002 5:34 PM
To: Stewart Thompson
Cc: Tyler Kemp; [EMAIL PROTECTED]
Subject: Re: (no subject)
On Thu, May 09, 2002 at 05:08:09PM -0700, Stewart Thompson wrote:
> Tyler:
>
> I think most people on the list would recommend a drop all
> Policy on all chains, and then open up what is required to achieve
> your goals. After all the whole purpose of a firewall is to give your
> system as much as possible.
This would be my suggestion as well. Please note, the chains in the
filter table are what Stewart means, I think.
>
> Ramin:
>
> My version of the syn rule allows 5/s and I think a burst of
> 10 or 20. I didn't check the burst limit. Does that sound reasonable?
Stewart, It all depends on the application and situation. For example
the limit 1/s that Tyler has, IMHO, does not fit with his home network
where he has several MASQ'ed windows machines. Just imagine what happens
if two or more windows machines try to access web pages or receive pop3
(hopefully kerberized or SSL'ized) or send emails all simultanously.
It's always better to specify the direction of a packet with -i and/or -o.
For example he could provide unlimited access from the internal network
to the outside and have a pretty tight limit for the incoming syns.
Of course you can start with a pretty tight limit and fine-tune it as you
experience bottle-necks. The default limit-busrt is 5 (according to the man
page).
One other point to note is that the limit rules below have a target ACCEPT
which is kind of 'duh'.
Tyler, I suggest you read the docs and definitely do not copy&paste
some friend's rule set on a machine which is connected 24*7. But as for
your problem now, try to tcpdump on both internal and external interface
while establishing a connection from one of the windows machines and see
what's broken. For the time being you can simply delete the limit rules
in the FORWARD chain by specifying -D FORWARD instead of -A.
Ramin
>
>
> Stu...........
>
>
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tyler Kemp
> Sent: May 9, 2002 3:52 PM
> To: Ramin Alidousti
> Cc: [EMAIL PROTECTED]
> Subject: RE: (no subject)
>
> >>
> >> #setup NAT
> >> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
> >>
> >>
> >> #forward chain
> >>
> >> #syn flood limiting
> >> iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
> >> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m
> limit --limit
> >> 1/s -j ACCEPT
> >>
> >>
> >> #enable ip forwarding
> >> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> > This is the relevant portion. Except for the fact that the limits
> > are too tight everything else looks good. What is the default
> > policy of the FORWARD chain?
>
> > Ramin
>
> I have no default policy for FORWARD. The friend from whom I recieved
these
> rulesets informs me it isn't needed. He uses a carbon copy of the same
> rules, with no problems.
>
> Tyler
>
>
>
