Re: kern/22065: Patch to add support to ipfw for per rule overriding of dynamic keep-state rule expiration lifetimes
Looks like this proposed patch (PR 22065) is still open. I suppose that means no one has decided whether it is useful or not, or (far more likely) folks are extremely busy doing other fun and useful stuff for FreeBSD. The patch in the PR is still mostly valid for FreeBSD 4.2-STABLE with a few line offset changes. I've got an updated version of the patch against 4.2-STABLE as of 17 FEB 2001 at the following web address: http://www.aarongifford.com/computers/ipfwpatch.html I have been using the patch successfully on several moderate-traffic hosts with no noticable problems. I do still have two questions that no one has yet answered. Still, it would be nice to know the following (with regard to the patch): 1. Am I safe using the union fw_un in the ip_fw structure (in ip_fw.h) to store the dynamic rule's lifetime setting or will this overlap with one of the other uses of that union and thus require that I modify the patch to create a new structure member for storing the setting? 2. Am I correct in assuming that in ip_fw.c at roughly line 800 where UDP and TCP matches to the dynamic rule extend the rule expiration by the dyn_syn_lifetime amount that this should instead only extend TCP matches by dyn_syn_lifetime and should extend UDP matches by dyn_short_lifetime instead? I believe this to be the case. The snippet of code from ip_fw.c in question looks like (beginning at line 800 of ip_fw.c as of FreeBSD 4.2-STABLE on 17 FEB 2001): } bzero (r, sizeof (*r) ); if (mask) r->mask = *mask ; r->id = *id ; r->expire = time_second + dyn_syn_lifetime ; /*<type = ((struct ip_fw_ext *)chain->rule)->dyn_type ; r->bucket = i ; r->next = ipfw_dyn_v[i] ; ipfw_dyn_v[i] = r ; dyn_count++ ; DEB(printf("-- add entry 0x%08x %d -> 0x%08x %d, %d left\n", (r->id.src_ip), (r->id.src_port), (r->id.dst_ip), (r->id.dst_port), dyn_count ); ) } I assume that the line above (flagged above with "< id.proto == IPPROTO_TCP ? dyn_syn_lifetime : dyn_short_lifetime) ; My patch assumes that this is the case and modifies the behavior so that non-TCP rule match expiration lifetimes are incremented by the dyn_short_lifetime sysctl setting (if no per-rule lifetime is specified). I would appreciate any answers to the two above questions, question #1 in particular, as well as any other commentary or suggestions. Thanks, Aaron out. -- InfoWest, Inc. * 596 E. Tabernacle * St. George, UT 84790 Voice: 435-674-0165 * FAX: 435-674-9654 Web: www.infowest.com * E-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IP fragment DOS attack on FreeBSD question
The recent FreeBSD advisory regarding IP fragment denial-of-service attacks didn't mention whether or not an IP filter (ipfw or ipf) that drops all fragments is an adequate temporary work-around or not. Does anyone who is familiar with the problem and attack know if something like the following would be a useful temporary work-around? ipfw add 1 deny ip from any to any fragment Does the above drop the fragment and prevent reassembly buffer starvation? Of course dropping ALL fragments like that will limit the connectivity of the host to hosts and networks where fragmentation occurs. But, if the above DOES prevent the DOS, it may be a useful tradeoff to use it as a temporary work-around until kernels are patched (kernels with ipfw already enabled). Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Timeouts on dynamic ipfw rules
Sebastien Petit ([EMAIL PROTECTED]) was heard to say: >I found your patches for 5.0-CURRENT, I will update it for 4.4 and 4.5, >thank you Crist. >Will this patch be commited in 5.0-RELEASE or perhaps 4.6 ? I think >this is a good functionnality imho. > >-- >Sebastien Petit >[EMAIL PROTECTED] >The HUT Project >http://www.bsdshell.net/ > I wrote an ipfw patch set available for 4.4-RELEASE through 4.5-STABLE, and even a very few versions of -CURRENT that addes a "lifetime " feature to ipfw. By default, it overrides the dyn_ack_lifetime timeout for TCP rules, the dyn_udp_lifetime for UDP rules, and dyn_short_lifetime for all other IP rules that use it (keepstate rules, that is). The patch set includes a man page patch explaining the addition. The latest versions of the set are available at: http://www.aarongifford.com/computers/ipfwpatch.html I have used this functionality on MANY of the FreeBSD systems I admin. since June of 2000 when I first created the patches and posted them (see the freebsd-net archive for the archaic versions thereof). The above web page has versions of the patch set for 4.4-RELEASE, 4.5-RELEASE, several different 4.X-STABLE versions, and even 1 or 2 -CURRENT versions (though those are getting old). There are two open PRs (Oops! There should be only one - someone can freely merge these if they want.) in hopes of getting this (or similar) functionality included in the source tree: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/28713 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/22065 Memory wise, the patches only increase memory use in the dynamic rules (a single unsigned short), using a union to store the information in the main ruleset since for keep-state rules the union in question was not in use (or so I believe - no one has told me otherwise, I can't see a problem, and I haven't yet heard of any trouble - if there ever was trouble, it would be easy to move the field out of the union). >On 2002.01.26 02:53 Crist J. Clark wrote: >> On Fri, Jan 25, 2002 at 11:39:29AM -0800, Luigi Rizzo wrote: >> > there were patches floating around for something similar. >> > >> > cheers >> > luigi >> > >> > On Fri, Jan 25, 2002 at 05:28:38PM +0100, Sebastien Petit wrote: >> > > Hi, >> > > >> > > Is there a way to set per keep-state rule timeout ? >> > > I want to have a little ack timeout for connection to mysql database tcp 3306 but a long ack timeout for other rules. >> > > if not perhaps this syntax can be implemented on ipfw code, for example: >> > > ipfw add ... keepstate setup timeout-ack 3600 >> > > or >> > > ipfw add ... keepstate setup timeout-syn 50 Now that's an intriguing idea, adding per-rule options that are a bit more specific than just modifying dyn_ack_lifetime for TCP, dyn_udp_lifetime for UDP, and dyn_short_lifetime for others. Your syntax (or a variation thereof) could be used to give even tighter control over per-rule timeouts (at the small expense of more memory used to store those per-rule timeouts). >> > > >> > > Perhaps I can do this stuff if there are no objections ? >> >> I've got CURRENT patches to do this at the site in the .sig. My STABLE >> ones bitrotted (the CURRENT ones might be pass the sell-by date >> too). But I could redo them if there is interest. >> -- >> Crist J. Clark | [EMAIL PROTECTED] >>| [EMAIL PROTECTED] >> http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] >> with "unsubscribe freebsd-net" in the body of the message >> I too would love to see per-rule expiration control added to FreeBSD's excellent ipfw filter. Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Timeouts on dynamic ipfw rules
I recently was heard to elocute: >Memory wise, the patches only increase memory use in the dynamic rules (a >single unsigned short), using a union to store the information in the main >ruleset since for keep-state rules the union in question was not in use (or >so I believe - no one has told me otherwise, I can't see a problem, and I >haven't yet heard of any trouble - if there ever was trouble, it would be >easy to move the field out of the union). Oops. s/unsigned short/unsigned long/g; Scratch that "unsigned short" and make it an "unsigned long" (or "u_int32_t") instead in the above paragraph. Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
I use stateful rules and natd together without any trouble. You just have to think through VERY carefully exactly what is happening to each and every packet during it's journey and write your rules accordingly. Let's look at your example ruleset, Michael: Michael Sierchio ([EMAIL PROTECTED]) wrote: >$on = external net = X.Y.Z/24 >$in = internal net = A.B.C/24 (192.168.1.0/24) > >the external IP is X.Y.Z.23 >the internal IP is A.B.C.1 > >firewall rules: > >[some static rules...] > >$fw add divert natd ip from any to any via $external_interface > >$fw add check-state > >$fw add allow tcp from $in to any setup keep-state >$fw add allow udp from $in to any keep-state > >$fw add allow tcp from $on to any setup keep-state >$fw add allow udp from $on to any keep-state > >An ssh connection from A.B.C.4 to X.Y.Z.44 causes the following dynamic rules >to appear: > >02400 15 3197 (T 16, slot 760) <-> tcp, X.Y.Z.23 1549<-> X.Y.Z.44 22 >02200 45 9151 (T 296, slot 913) <-> tcp, A.B.C.4 1549<-> X.Y.Z.44 22 After carefully reading your above rules, I can assure you that you're NOT seeing a bug at all, and what you see is what I expect SHOULD be happening. Let's follow a SYN, SYN-ACK, ACK three-way TCP handshake through your ruleset: Your SYN packet from INSIDE to OUTSIDE first traverses your ruleset IN VIA your internal interface. It MATCHES your rule: "$fw add allow tcp from $in to any setup keep-state" This adds the dynamic rule you see as "A.B.C.4 1549<-> X.Y.Z.44 22". Next, your packet goes through the list again, this time OUT VIA your external interface. It matches your NAT divert rule, the source address of the SYN packet gets changed from A.B.C.4 to A.B.C.1. This now modified packet does NOT MATCH the check-state because the source address differs. So this same SYN packet now matches this rule: "$fw add allow tcp from $on to any setup keep-state" That's the other dynamic rule you see as "X.Y.Z.23 1549<-> X.Y.Z.44 22" Now let's trace the SYN-ACK packet from X.Y.Z.44 port 22 back to your inside machine. It enters IPFW as a packet IN VIA your external interface, so this packet immediately matches your NAT divert rule and is rewritten with a DESTINATION address of "A.B.C.D 1549". This reply packet will NEVER hit your check-state, and that's why the dynamic rule "X.Y.Z.23 1549<-> X.Y.Z.44 22" stays in the SYN state until it times out. Continuing on, the now translated SYN/ACK now hits the check-state and MATCHES the dynamic rule "A.B.C.4 1549<-> X.Y.Z.44 22" and that rule's timeout is updated just fine. Now you your inside source sends an ACK packet back to complete the 3-way handshake. This ACK enters as an IN VIA internal interface packet. It doesn't match the NAT divert, but it DOES match the "A.B.C.4 1549<-> X.Y.Z.44 22" check-state rule, and updates the dynamic rule's timeout. Next it enters your ruleset OUT VIA your external interface, hits the NAT divert, and gets translated. It then continues through the rules. When it hits check-state, while it DOES match the "X.Y.Z.23 1549<-> X.Y.Z.44 22" dynamic rule in principal, it FAILS to match because the dynamic rule is expecting to see a SYN-ACK response from the remote host FIRST (remember, the SYN-ACK never matched this particular dynamic rule). Thus this dynamic rule STILL sits, expecting SYN-ACK. Since no further rules match, if you default to deny, your ACK packet gets dropped/denied. Is this the behavior you are seeing? If anyone is interested, I'd be happy to post my ipfw rules I use at home. I have a single Internet visible IP and a few hosts translated sitting behind it on a broadband connection. Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
"Rogier R. Mulhuijzen" ([EMAIL PROTECTED]) was heard to say: >>>the reply was that keep-state and natd are very hard to use >>>together, and besides it is rather useless because natd is stateful >>>by itself. >>natd is stateful, but provides no protection for inbound IP traffic >>that is destined for the filtering host itself. > >I have personally looked at natd & stateful ipfw rules, and have concluded >that it logically impossible to get it to work. > >Thus I made a ipfw rulelist that utilizes the statefulness of natd. I hope >this helps you in making your own rulelist. > Actually you CAN use both together, but there's really no reason to do so. One would be duplicating things, since NAT is effectively a stateful filter of sorts. One just has to think things through very carefully, following the flow of packets through the ruleset. My own ruleset I use at home shares some similarities with your set, Rogier. For NAT traffic, I don't use stateful rules -- I let NAT track the state, but for traffic to/from my gateway host, I still use stateful rules. But, the way my ruleset is written, I could drop stateful rules in for the NAT traffic without a hitch. But it would be wasted duplication of effort for the most part. Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
On Friday 15 February 2002 05:00 pm, Michael Sierchio <[EMAIL PROTECTED]>
wrote:
> Aaron D. Gifford wrote:
> > When it hits check-state, while it DOES match the "X.Y.Z.23 1549<->
> > X.Y.Z.44 22" dynamic rule in principal, it FAILS to match because the
> > dynamic rule is expecting to see a SYN-ACK response from the remote host
> > FIRST (remember, the SYN-ACK never matched this particular dynamic rule).
> > Thus this dynamic rule STILL sits, expecting SYN-ACK.
> >
> > Since no further rules match, if you default to deny, your ACK packet
> > gets dropped/denied.
> >
> > Is this the behavior you are seeing?
>
> The packet is never dropped, it's just that -- as Crist previously
> pointed out -- it matches an earlier rule, so it never changes
> the state of the dynamic rule in question. It's sometimes useful to
> use 'add count' rules before and after 'divert natd' to see what's
> happening.
>
Okay, I understand now. You're saying that the last packet of the three-way
TCP handshake (the SYN+ACK from the INSIDE to the OUTSIDE) is NOT dropped,
but passed by the "X.Y.Z.23 1549<-> X.Y.Z.44 22" rule WITHOUT that rule being
updated. That indeed is a bug.
Reading the code in /usr/src/sys/netinet/ip_fw.c (on my 4.5-STABLE box), I
see where the problem is. Around line 780, there is a switch()/case:
statement that handles normal TCP states.
Because of your ruleset, you have created a dynamic rule that only sees the
INSIDE-to-OUTSIDE packets but will NEVER see the reverse packets (the other
dynamic rule your original post mentions will behave normally, seeing the
packets in BOTH directions).
The current ip_fw.c code there, in this case will PASS the matched packet,
and update the timeout using dyn_rst_lifetime because it falls through the
switch() statement to the default: section.
I don't know what the correct "fix" is. My gut instinct is that ifpw's
default: seciton (line 798) should just reject/drop the packet (return NULL)
instead of what it does today, passing the packet with a very short timeout.
If there are valid states that are not yet handled, they should be added and
handled.
Perhaps a useful solution to the bug that might have helped warn you in your
specific situation would be to detect such half-seen behavior in the default
case, and log a warning, since this is likely to be a common problem with
anyone using ipfw stateful rules and natd.
Something like:
default:
if (q->state == TH_SYN | TH_ACK)
/*
* Both forward SYN and SYN+ACK packets have been seen,
* without a reverse SYN+ACK packet in between, due to a
* buggy rule set, or bogus traffic from the originating host.
*/
if (fw_verbose) {
log(LOG_SECURITY | LOG_NOTICE,
"ipfw: Invalid stateful TCP rule (from %d): Middle packet "
"missing from three-way TCP handshake.",
q->parent->fw_number);
return NULL; /* Drop the packet as if not matched */
}
If you'd seen such a warning right away, without it passing your packets, you
would have known it was a ruleset problem, or else asked someone on the list
about the error message in the logs.
Thoughts?
Aaron out.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
On Friday 15 February 2002 06:15 pm, I was heard to blurt out without
thinking:
> default:
> if (q->state == TH_SYN | TH_ACK)
> /*
> * Both forward SYN and SYN+ACK packets have been seen,
> * without a reverse SYN+ACK packet in between, due to a
> * buggy rule set, or bogus traffic from the originating host.
> */
> if (fw_verbose) {
> log(LOG_SECURITY | LOG_NOTICE,
> "ipfw: Invalid stateful TCP rule (from %d): Middle packet "
> "missing from three-way TCP handshake.",
> q->parent->fw_number);
> return NULL;/* Drop the packet as if not matched */
> }
Heh, I MEANT to say:
default:
if (q->state == (TH_SYN | TH_ACK)) {
/*
* Both forward SYN and ACK packets have been seen, without
* a reverse SYN+ACK packet in between, likely due to either
* a buggy rule set, or bogus traffic.
*/
if (fw_verbose) {
log(LOG_SECURITY | LOG_NOTICE,
"ipfw: Invalid stateful TCP rule (from %d): Middle "
"packet missing from three-way TCP handshake.",
q->rule->fw_number);
return NULL;/* Drop it as if not matched */
}
}
There. I don't know why I was calling the third packet a SYN+ACK in the
comments. The original also was missing some parenthesis, and used an
incorrect field name (q->parent->fw_number instead of q-.rule->fw_number).
Sorry. Comes from leaping before looking, I supppose.
Aaron out.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: wi0: wi_cmd: busy bit won't clear.
Andrew ([EMAIL PROTECTED]) wrote: >Hi, > >I have a Linksys WMP11 802.11b card running in hostap mode. Every now >and then my wireless network dissappears. If I ssh into the box over a >different interface everything looks OK. To get things going I run >ifconfig wi0 down. The whole machines seems to lock up - it doesn't >even respond to pings on other interfaces. If I wait long enough (30 >secs approx) everything comes back. I find emitted from the kernel: > >wi0: wi_cmd: busy bit won't clear. > >multiple times. > >Anyone seen this? Any ideas? > >I'm running 4.7-STABLE as of a few days ago. > >Thanks, > >Andrew I see almost the exact same thing here. I'm running probably the same card. My hardware is detected during boot thus: wi0: mem 0xffbeb000-0xffbebfff irq 10 at device 16.0 on pci0 wi0: 802.11 address: de:ad:be:ef:fa:fa wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary 1.01.00, Station 1.04.02 The card is set up during boot thus: ifconfig wi0 inet 10.0.1.1/24 ssid my_ssid station my_station channel 7 wepmode on wepkey my_key mediaopt ibss Every now and then, the network will disappear, then return anywhere from 30 seconds to three minutes later. On the console and in the logs are entries much like Andrews: Dec 5 13:15:29 mybox /kernel: wi0: timeout in wi_cmd 0x010b; event status 0x8000 Dec 5 13:15:29 mybox /kernel: wi0: xmit failed Dec 5 13:17:51 mybox /kernel: wi0: watchdog timeout Dec 5 13:17:51 mybox /kernel: wi0: timeout in wi_cmd 0x0002; event status 0x8000 Dec 5 13:17:51 mybox /kernel: wi0: wi_cmd: busy bit won't clear. Dec 5 13:17:51 mybox last message repeated 2 times Dec 5 13:17:51 mybox /kernel: wi0: init failed Dec 5 13:17:51 mybox /kernel: wi0: wi_cmd: busy bit won't clear. Dec 5 13:17:51 mybox last message repeated 22 times Dec 5 13:17:51 mybox /kernel: wi0: failed to allocate 1594 bytes on NIC Dec 5 13:17:51 mybox /kernel: wi0: tx buffer allocation failed Dec 5 13:17:51 mybox /kernel: wi0: wi_cmd: busy bit won't clear. Dec 5 13:17:51 mybox /kernel: wi0: failed to allocate 1594 bytes on NIC Dec 5 13:17:51 mybox /kernel: wi0: mgmt. buffer allocation failed Dec 5 13:17:51 mybox /kernel: wi0: timeout in wi_seek to 0/0; last status 4000 Dec 5 13:17:51 mybox /kernel: wi0: timeout in wi_seek to 0/44; last status 4044 Dec 5 13:17:56 mybox /kernel: wi0: watchdog timeout The logs are very similar during each "event" and the host becomes unreachable whether via the wireless network or wired network. I haven't been able to get to the console quickly enough to check if the console is also unresponsive, but I wouldn't be surprised. It seems these "outages" occur more often during heavier traffic. They also have increased in frequency since WEP was enabled on the network. Any ideas, anyone? Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
