Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
.
- Original Message - From: Norm Vilmer
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 16, 2004 11:57 PM
Subject: Too many dynamic rules, sorry
If I repeatedly nmap my FreeBSD 4.10 machine configured with ipfirewall,
I get the message Too many dynamic rules, sorry. Doing a sysctl -a
|grep ip.fw I can see the the net.inet.ip.fw.dyn_count has reached the
max value of 8192 that I set. The net.inet.ip.fw.dyn_ack_lifetime is set
to 300, so the dynamic rule count starts going down after about 5
minutes after the simulated attack.
Questions:
When this happens, if my firewall still fully operational, in other
words can I safely ignore this message?
Is there a way to fix this?
The error Too many dynamic rules, sorry will cause the system to drop
any packets that are covered by a keep-state entry. So, the firewall,
while operational, is in a dead lock down state for any outbound traffic
until the dynamic rules clear out. I'm hoping that you're checking the
system with nmap from behind it, because if your outside the firewall,
then you're keeping state in inbound traffic and that's bad. You only
want keep-state from traffic leaving that system, not to it.
--
Micheal Patterson
TSG Network Administration
405-917-0600
Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
[EMAIL PROTECTED]
Thanks for your help.
I was running nmap against my public or outside interface. This is my
first FreeBSD firewall, so I am sure my rules are not optimal, however,
the firewall appears to be doing what I want. I gathered these rules
from a number of how-to's and postings on the web with only a partial
understanding of what they actually do (yes, I know, problem # 1).
Here are the rules that I have that keep-state on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53 keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123 keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip} keep-state
Do you think these are causing the problem?
Norm Vilmer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
.
- Original Message -
From: Norm Vilmer [EMAIL PROTECTED]
To: Micheal Patterson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 17, 2004 9:41 AM
Subject: Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
.
- Original Message - From: Norm Vilmer
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 16, 2004 11:57 PM
Subject: Too many dynamic rules, sorry
If I repeatedly nmap my FreeBSD 4.10 machine configured with
ipfirewall,
I get the message Too many dynamic rules, sorry. Doing a sysctl -a
|grep ip.fw I can see the the net.inet.ip.fw.dyn_count has reached the
max value of 8192 that I set. The net.inet.ip.fw.dyn_ack_lifetime is
set
to 300, so the dynamic rule count starts going down after about 5
minutes after the simulated attack.
Questions:
When this happens, if my firewall still fully operational, in other
words can I safely ignore this message?
Is there a way to fix this?
The error Too many dynamic rules, sorry will cause the system to drop
any packets that are covered by a keep-state entry. So, the firewall,
while operational, is in a dead lock down state for any outbound traffic
until the dynamic rules clear out. I'm hoping that you're checking the
system with nmap from behind it, because if your outside the firewall,
then you're keeping state in inbound traffic and that's bad. You only
want keep-state from traffic leaving that system, not to it.
--
Micheal Patterson
TSG Network Administration
405-917-0600
Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
[EMAIL PROTECTED]
Thanks for your help.
I was running nmap against my public or outside interface. This is my
first FreeBSD firewall, so I am sure my rules are not optimal, however,
the firewall appears to be doing what I want. I gathered these rules
from a number of how-to's and postings on the web with only a partial
understanding of what they actually do (yes, I know, problem # 1).
Here are the rules that I have that keep-state on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53 keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123 keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip} keep-state
Do you think these are causing the problem?
Norm Vilmer
I don't recall if you're running ipfilter or ipfw on that system. I don't
know ipfilter well enough to assist yet, but with ipfw, if you have a
check-state entry above your keep-states, that may reduce the amount of
dynamic rule entries that you'll have. What the check-state does, is to
check the dynamic list, if an entry already exists, it stops processing
rules there.
--
Micheal Patterson
TSG Network Administration
405-917-0600
Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
Norm Vilmer wrote:
Here are the rules that I have that keep-state on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53 keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123 keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip} keep-state
Do you think these are causing the problem?
Aren't udp and icmp state-less protocols?
In that case, keep-state would not make much sense.
I use 'keep-state' only for tcp rules.
I may be wrong, moreover, I haven't followed the full thread :).
Rob.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
.
- Original Message -
From: Norm Vilmer [EMAIL PROTECTED]
To: Micheal Patterson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 17, 2004 9:41 AM
Subject: Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
.
- Original Message - From: Norm Vilmer
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 16, 2004 11:57 PM
Subject: Too many dynamic rules, sorry
If I repeatedly nmap my FreeBSD 4.10 machine configured with
ipfirewall,
I get the message Too many dynamic rules, sorry. Doing a sysctl -a
|grep ip.fw I can see the the net.inet.ip.fw.dyn_count has reached the
max value of 8192 that I set. The net.inet.ip.fw.dyn_ack_lifetime is
set
to 300, so the dynamic rule count starts going down after about 5
minutes after the simulated attack.
Questions:
When this happens, if my firewall still fully operational, in other
words can I safely ignore this message?
Is there a way to fix this?
The error Too many dynamic rules, sorry will cause the system to drop
any packets that are covered by a keep-state entry. So, the firewall,
while operational, is in a dead lock down state for any outbound traffic
until the dynamic rules clear out. I'm hoping that you're checking the
system with nmap from behind it, because if your outside the firewall,
then you're keeping state in inbound traffic and that's bad. You only
want keep-state from traffic leaving that system, not to it.
--
Micheal Patterson
TSG Network Administration
405-917-0600
Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
[EMAIL PROTECTED]
Thanks for your help.
I was running nmap against my public or outside interface. This is my
first FreeBSD firewall, so I am sure my rules are not optimal, however,
the firewall appears to be doing what I want. I gathered these rules
from a number of how-to's and postings on the web with only a partial
understanding of what they actually do (yes, I know, problem # 1).
Here are the rules that I have that keep-state on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53 keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123 keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip} keep-state
Do you think these are causing the problem?
Norm Vilmer
I don't recall if you're running ipfilter or ipfw on that system. I don't
know ipfilter well enough to assist yet, but with ipfw, if you have a
check-state entry above your keep-states, that may reduce the amount of
dynamic rule entries that you'll have. What the check-state does, is to
check the dynamic list, if an entry already exists, it stops processing
rules there.
--
Micheal Patterson
TSG Network Administration
405-917-0600
Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
I do have a check-state rule
add 00200 check-state
Norm Vilmer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
Rob [EMAIL PROTECTED] wrote:
Norm Vilmer wrote:
Here are the rules that I have that keep-state on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53 keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123 keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip} keep-state
Do you think these are causing the problem?
Aren't udp and icmp state-less protocols?
In that case, keep-state would not make much sense.
I use 'keep-state' only for tcp rules.
I may be wrong, moreover, I haven't followed the full thread :).
You'll generally need to keep state on UDP when you play online games.
If you're smart, you don't allow arbitrary UDP packets from the outside
world into your network, but if you're playing Unreal or something, then
all communication is via UDP, and you won't be able to play.
The best solution is to allow all UDP traffic to _leave_, while keeping
state. the keep-state remembers the ip/port information on the outgoing
packets, and thus allows return packets to get back in (by matching the
ip/port pair).
Now, when you know the port, it doesn't really make sense to use
keep-state, and all you're really doing is spamming your state tables.
If you look in the /etc/rc.firewall that ships with FreeBSD, you'll see
these rules (designed to handle running a DNS server):
# Allow access to our DNS
${fwcmd} add pass tcp from any to ${oip} 53 setup
${fwcmd} add pass udp from any to ${oip} 53
${fwcmd} add pass udp from ${oip} 53 to any
Granted, it's three rules instead of 1, but it does not use your state
tables unnecessarily (sp?)
HTH.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
- Original Message - From: Norm Vilmer [EMAIL PROTECTED] To: Micheal Patterson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 17, 2004 10:30 AM Subject: Re: Too many dynamic rules, sorry snip I do have a check-state rule add 00200 check-state Norm Vilmer Ok. Then right above the check-state entry, place an allow ip from 123.123.123/24 to 123.123.123./24 Replace the ip's with the appropriate network/metric for your lan and that will allow lan traffic to go to itself unhindered by any stateful checks. -- Micheal Patterson TSG Network Administration 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
You'll generally need to keep state on UDP when you
play online games.
If you're smart, you don't allow arbitrary UDP
packets from the outside
world into your network, but if you're playing
Unreal or something, then
all communication is via UDP, and you won't be able
to play.
The best solution is to allow all UDP traffic to
_leave_, while keeping
state. the keep-state remembers the ip/port
information on the outgoing
packets, and thus allows return packets to get back
in (by matching the
ip/port pair).
Now, when you know the port, it doesn't really make
sense to use
keep-state, and all you're really doing is spamming
your state tables.
If you look in the /etc/rc.firewall that ships with
FreeBSD, you'll see
these rules (designed to handle running a DNS
server):
# Allow access to our DNS
${fwcmd} add pass tcp from any to ${oip} 53
setup
${fwcmd} add pass udp from any to ${oip} 53
${fwcmd} add pass udp from ${oip} 53 to any
Granted, it's three rules instead of 1, but it does
not use your state
tables unnecessarily (sp?)
Unless you have above the #Allow access to our DNS
rules-
${fwcmd} add pass udp from ${oip} to any keep-state
to allow all UDP to leave.
the first incoming packet to port 53 will match the
stateless rule
${fwcmd} add pass udp from any to ${oip} 53
but the reply will create a dynamic rule
because first match is
${fwcmd} add pass udp from ${oip} to any keep-state
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
--- Bill Moran [EMAIL PROTECTED] wrote:
Rob [EMAIL PROTECTED] wrote:
Norm Vilmer wrote:
Here are the rules that I have that keep-state
on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53
keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123
keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip}
keep-state
Do you think these are causing the problem?
Aren't udp and icmp state-less protocols?
In that case, keep-state would not make much
sense.
I use 'keep-state' only for tcp rules.
I may be wrong, moreover, I haven't followed the
full thread :).
You'll generally need to keep state on UDP when you
play online games.
If you're smart, you don't allow arbitrary UDP
packets from the outside
world into your network, but if you're playing
Unreal or something, then
all communication is via UDP, and you won't be able
to play.
The best solution is to allow all UDP traffic to
_leave_, while keeping
state. the keep-state remembers the ip/port
information on the outgoing
packets, and thus allows return packets to get back
in (by matching the
ip/port pair).
Now, when you know the port, it doesn't really make
sense to use
keep-state, and all you're really doing is spamming
your state tables.
If you look in the /etc/rc.firewall that ships with
FreeBSD, you'll see
these rules (designed to handle running a DNS
server):
# Allow access to our DNS
${fwcmd} add pass tcp from any to ${oip} 53
setup
${fwcmd} add pass udp from any to ${oip} 53
${fwcmd} add pass udp from ${oip} 53 to any
Granted, it's three rules instead of 1, but it does
not use your state
tables unnecessarily (sp?)
HTH.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
[EMAIL PROTECTED]
__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
--- Bill Moran [EMAIL PROTECTED] wrote:
Rob [EMAIL PROTECTED] wrote:
Norm Vilmer wrote:
Here are the rules that I have that keep-state
on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53
keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123
keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip}
keep-state
Do you think these are causing the problem?
Aren't udp and icmp state-less protocols?
In that case, keep-state would not make much
sense.
I use 'keep-state' only for tcp rules.
I may be wrong, moreover, I haven't followed the
full thread :).
You'll generally need to keep state on UDP when you
play online games.
If you're smart, you don't allow arbitrary UDP
packets from the outside
world into your network, but if you're playing
Unreal or something, then
all communication is via UDP, and you won't be able
to play.
The best solution is to allow all UDP traffic to
_leave_, while keeping
state. the keep-state remembers the ip/port
information on the outgoing
packets, and thus allows return packets to get back
in (by matching the
ip/port pair).
Now, when you know the port, it doesn't really make
sense to use
keep-state, and all you're really doing is spamming
your state tables.
If you look in the /etc/rc.firewall that ships with
FreeBSD, you'll see
these rules (designed to handle running a DNS
server):
# Allow access to our DNS
${fwcmd} add pass tcp from any to ${oip} 53
setup
${fwcmd} add pass udp from any to ${oip} 53
${fwcmd} add pass udp from ${oip} 53 to any
Granted, it's three rules instead of 1, but it does
not use your state
tables unnecessarily (sp?)
HTH.
Sorry, wasn't done with last message.
Look at your dynamic table, if you are getting DoS'd,
try using the limit option instead of keep-state or
tweak the net.inet.ip.fw.dyn_(*)_lifetime to a level
that suits your needs.
Or, rewrite your rules removing the keep-state options.
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
- Original Message -
From: Norm Vilmer [EMAIL PROTECTED]
To: Micheal Patterson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 17, 2004 10:30 AM
Subject: Re: Too many dynamic rules, sorry
snip
I do have a check-state rule
add 00200 check-state
Norm Vilmer
Ok. Then right above the check-state entry, place an
allow ip from 123.123.123/24 to 123.123.123./24
Replace the ip's with the appropriate network/metric for your lan and that
will allow lan traffic to go to itself unhindered by any stateful checks.
--
Micheal Patterson
TSG Network Administration
405-917-0600
Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
would this be the same?
add 00200 allow all from any to any via ${iif} keep-state
add 00210 check-state
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
Bill Moran wrote:
Rob [EMAIL PROTECTED] wrote:
Norm Vilmer wrote:
Here are the rules that I have that keep-state on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53 keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123 keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip} keep-state
Do you think these are causing the problem?
Aren't udp and icmp state-less protocols?
In that case, keep-state would not make much sense.
I use 'keep-state' only for tcp rules.
I may be wrong, moreover, I haven't followed the full thread :).
You'll generally need to keep state on UDP when you play online games.
If you're smart, you don't allow arbitrary UDP packets from the outside
world into your network, but if you're playing Unreal or something, then
all communication is via UDP, and you won't be able to play.
The best solution is to allow all UDP traffic to _leave_, while keeping
state. the keep-state remembers the ip/port information on the outgoing
packets, and thus allows return packets to get back in (by matching the
ip/port pair).
Now, when you know the port, it doesn't really make sense to use
keep-state, and all you're really doing is spamming your state tables.
If you look in the /etc/rc.firewall that ships with FreeBSD, you'll see
these rules (designed to handle running a DNS server):
# Allow access to our DNS
${fwcmd} add pass tcp from any to ${oip} 53 setup
${fwcmd} add pass udp from any to ${oip} 53
${fwcmd} add pass udp from ${oip} 53 to any
Granted, it's three rules instead of 1, but it does not use your state
tables unnecessarily (sp?)
HTH.
I'm not sure why, but using the above rules from the supplied
rc.firewall causes nslookup to fail on all my machines inside the
firewall. I am sure it must have something to do with the order.
Also, I am not running a DNS, so I really only need the outbound
rule (I think).
I changed my rule to
add 01300 pass udp from ${oip} to any 53
this seems to be working. So I also removed the keep state from
the ICMP and NTP rules. I had thought that you needed the keep-state
rule for ICMP if you wanted trace route to work correctly, but it
behaves the same regardless.
add 01400 pass udp from ${oip} to any 123
add 01600 pass icmp from any to any via ${oip}
I left the keep state on the gre rule, well, because, I am afraid it
may cause weirdness in the VPN connection.
Norm Vilmer
Norm
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
Dave McCammon wrote:
--- Bill Moran [EMAIL PROTECTED] wrote:
Rob [EMAIL PROTECTED] wrote:
Norm Vilmer wrote:
Here are the rules that I have that keep-state
on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53
keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123
keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip}
keep-state
Do you think these are causing the problem?
Aren't udp and icmp state-less protocols?
In that case, keep-state would not make much
sense.
I use 'keep-state' only for tcp rules.
I may be wrong, moreover, I haven't followed the
full thread :).
You'll generally need to keep state on UDP when you
play online games.
If you're smart, you don't allow arbitrary UDP
packets from the outside
world into your network, but if you're playing
Unreal or something, then
all communication is via UDP, and you won't be able
to play.
The best solution is to allow all UDP traffic to
_leave_, while keeping
state. the keep-state remembers the ip/port
information on the outgoing
packets, and thus allows return packets to get back
in (by matching the
ip/port pair).
Now, when you know the port, it doesn't really make
sense to use
keep-state, and all you're really doing is spamming
your state tables.
If you look in the /etc/rc.firewall that ships with
FreeBSD, you'll see
these rules (designed to handle running a DNS
server):
# Allow access to our DNS
${fwcmd} add pass tcp from any to ${oip} 53
setup
${fwcmd} add pass udp from any to ${oip} 53
${fwcmd} add pass udp from ${oip} 53 to any
Granted, it's three rules instead of 1, but it does
not use your state
tables unnecessarily (sp?)
HTH.
Sorry, wasn't done with last message.
Look at your dynamic table, if you are getting DoS'd,
try using the limit option instead of keep-state or
tweak the net.inet.ip.fw.dyn_(*)_lifetime to a level
that suits your needs.
Or, rewrite your rules removing the keep-state options.
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
I think I follow you. I am going to have to play around with the
DNS rules supplied with rc.firewall to see if I can get them to
work. Just putting them in as given, my machines inside the firewall
can not do nslookup's.
I am a little afraid to play with the net.inet.ip.fw.dyn_(*)_lifetime
level, I have seen a number of posting where people increase the value,
mine is set to 300 (default). I did remove keep-state from all my rules
excpet the gre rule. I also set the net.inet.ip.fw.dyn_max to 8192 which
helps.
Maybe I need a good book on the subject. Any suggestions?
Norm Vilmer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
- Original Message -
From: Norm Vilmer [EMAIL PROTECTED]
To: Micheal Patterson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 17, 2004 11:47 AM
Subject: Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
- Original Message -
From: Norm Vilmer [EMAIL PROTECTED]
To: Micheal Patterson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 17, 2004 10:30 AM
Subject: Re: Too many dynamic rules, sorry
snip
I do have a check-state rule
add 00200 check-state
Norm Vilmer
Ok. Then right above the check-state entry, place an
allow ip from 123.123.123/24 to 123.123.123./24
Replace the ip's with the appropriate network/metric for your lan and
that
will allow lan traffic to go to itself unhindered by any stateful
checks.
--
Micheal Patterson
TSG Network Administration
405-917-0600
would this be the same?
add 00200 allow all from any to any via ${iif} keep-state
add 00210 check-state
The goal is to not use dynamic rules for your local lan, only the traffic
from the lan to the net. Otherwise, you're wasting dynamic state table space
for rules that aren't necessary.
A very basic stateful ruleset:
ipfw add 100 allow ip from 1.1.1.0/24 to 1.1.1.0/24
ipfw add 500 check-state
ipfw add 600 allow ip from 1.1.1.0/24 to any keep-state
ipfw add 65000 deny log ip from any to any
That type of ruleset, will allow local traffic without using state table,
and the entry at 1000 will catch everything else outbound and use state
tables for it. If it's not originating from your network, and there's no
state entry, it's blocked by 65000.
--
Micheal Patterson
TSG Network Administration
405-917-0600
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
- Original Message -
From: Norm Vilmer [EMAIL PROTECTED]
To: Micheal Patterson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 17, 2004 11:47 AM
Subject: Re: Too many dynamic rules, sorry
Micheal Patterson wrote:
- Original Message -
From: Norm Vilmer [EMAIL PROTECTED]
To: Micheal Patterson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 17, 2004 10:30 AM
Subject: Re: Too many dynamic rules, sorry
snip
I do have a check-state rule
add 00200 check-state
Norm Vilmer
Ok. Then right above the check-state entry, place an
allow ip from 123.123.123/24 to 123.123.123./24
Replace the ip's with the appropriate network/metric for your lan and
that
will allow lan traffic to go to itself unhindered by any stateful
checks.
--
Micheal Patterson
TSG Network Administration
405-917-0600
would this be the same?
add 00200 allow all from any to any via ${iif} keep-state
add 00210 check-state
The goal is to not use dynamic rules for your local lan, only the traffic
from the lan to the net. Otherwise, you're wasting dynamic state table space
for rules that aren't necessary.
A very basic stateful ruleset:
ipfw add 100 allow ip from 1.1.1.0/24 to 1.1.1.0/24
ipfw add 500 check-state
ipfw add 600 allow ip from 1.1.1.0/24 to any keep-state
ipfw add 65000 deny log ip from any to any
That type of ruleset, will allow local traffic without using state table,
and the entry at 1000 will catch everything else outbound and use state
tables for it. If it's not originating from your network, and there's no
state entry, it's blocked by 65000.
--
Micheal Patterson
TSG Network Administration
405-917-0600
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
I tried your suggestion and got the same results and I think I
understand why. If I have this right, it's putting keep-state on
a rule that cause dynamic rules to be created. Well, I have
removed all the keep-state's except for the one you specified.
I launched the nmap attack against my public ip, however, the
machine I launched it from is on the same network segment as the
firewalls internal interface. So the traffic is going out the firewall
then coming back in. If I am correct, this is a major Doh! on my part.
Of course the net.inet.ip.fw.dyn_count is climbing, the
ipfw add 600 allow ip from 1.1.1.0/24 to any keep-state
rule is the culprit due to the outbound traffic.
So I really need to nmap my firewall from another location
to complete my test.
Hmmm, does this mean that I can mess up my firewall by running
nmap on a machine inside my firewall. It appears so.
Do you know what the maximum value for net.inet.ip.fw.dyn_max is?
I thought I read 8192
Norm Vilmer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
--- Norm Vilmer [EMAIL PROTECTED] wrote:
Dave McCammon wrote:
--- Bill Moran [EMAIL PROTECTED] wrote:
Rob [EMAIL PROTECTED] wrote:
Norm Vilmer wrote:
Here are the rules that I have that keep-state
on the outside interface:
#For DNS
add 01300 pass udp from ${oip} to any 53
keep-state
# For NTP
add 01400 pass udp from ${oip} to any 123
keep-state
# For VPN
add 01500 pass gre from any to any keep-state
# For ICMP
add 01600 pass icmp from any to any via ${oip}
keep-state
Do you think these are causing the problem?
Aren't udp and icmp state-less protocols?
In that case, keep-state would not make much
sense.
I use 'keep-state' only for tcp rules.
I may be wrong, moreover, I haven't followed the
full thread :).
You'll generally need to keep state on UDP when
you
play online games.
If you're smart, you don't allow arbitrary UDP
packets from the outside
world into your network, but if you're playing
Unreal or something, then
all communication is via UDP, and you won't be
able
to play.
The best solution is to allow all UDP traffic to
_leave_, while keeping
state. the keep-state remembers the ip/port
information on the outgoing
packets, and thus allows return packets to get
back
in (by matching the
ip/port pair).
Now, when you know the port, it doesn't really
make
sense to use
keep-state, and all you're really doing is
spamming
your state tables.
If you look in the /etc/rc.firewall that ships
with
FreeBSD, you'll see
these rules (designed to handle running a DNS
server):
# Allow access to our DNS
${fwcmd} add pass tcp from any to ${oip}
53
setup
${fwcmd} add pass udp from any to ${oip}
53
${fwcmd} add pass udp from ${oip} 53 to
any
Granted, it's three rules instead of 1, but it
does
not use your state
tables unnecessarily (sp?)
HTH.
Sorry, wasn't done with last message.
Look at your dynamic table, if you are getting
DoS'd,
try using the limit option instead of keep-state
or
tweak the net.inet.ip.fw.dyn_(*)_lifetime to a
level
that suits your needs.
Or, rewrite your rules removing the keep-state
options.
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
[EMAIL PROTECTED]
I think I follow you. I am going to have to play
around with the
DNS rules supplied with rc.firewall to see if I can
get them to
work. Just putting them in as given, my machines
inside the firewall
can not do nslookup's.
I am a little afraid to play with the
net.inet.ip.fw.dyn_(*)_lifetime
level, I have seen a number of posting where people
increase the value,
mine is set to 300 (default). I did remove
keep-state from all my rules
excpet the gre rule. I also set the
net.inet.ip.fw.dyn_max to 8192 which
helps.
Maybe I need a good book on the subject. Any
suggestions?
Norm Vilmer
What you may you may want to do is lower the
net.inet.ip.fw.dyn_ack_lifetime.
This will help the dynamic rules to be cleared faster
on connections that don't get completed with the FIN
or RST.
Besides, I believe the UDP dynamic rules are
controlled by net.inet.ip.fw.dyn_udp_lifetime.
On my bridging-firewall, it is set to 10 but in the
man page for ipfw it shows default as 5 (unless the 5
is just an example not the default).
Here is some links that I have bookmarked
http://www.kgb.ro/Ipfw-HOWTO
http://freebsd.amazingdev.com/blog/archives/000112.html
http://www.toad-one.org/howto/FreeBSD/Ipfw-Advanced-Supplement-HOWTO.txt
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too many dynamic rules, sorry
. - Original Message - From: Norm Vilmer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 16, 2004 11:57 PM Subject: Too many dynamic rules, sorry If I repeatedly nmap my FreeBSD 4.10 machine configured with ipfirewall, I get the message Too many dynamic rules, sorry. Doing a sysctl -a |grep ip.fw I can see the the net.inet.ip.fw.dyn_count has reached the max value of 8192 that I set. The net.inet.ip.fw.dyn_ack_lifetime is set to 300, so the dynamic rule count starts going down after about 5 minutes after the simulated attack. Questions: When this happens, if my firewall still fully operational, in other words can I safely ignore this message? Is there a way to fix this? The error Too many dynamic rules, sorry will cause the system to drop any packets that are covered by a keep-state entry. So, the firewall, while operational, is in a dead lock down state for any outbound traffic until the dynamic rules clear out. I'm hoping that you're checking the system with nmap from behind it, because if your outside the firewall, then you're keeping state in inbound traffic and that's bad. You only want keep-state from traffic leaving that system, not to it. -- Micheal Patterson TSG Network Administration 405-917-0600 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
