Reliable PCI wifi cards, and layer 7 filtering

[Boris Kochergin]

On 02/10/11 10:56, Jeremy Chadwick wrote:
> (I was considering cross-posting this to freebsd-pf but decided against
> it, instead starting here first.  Please keep me CC'd as I'm not
> subscribed to freebsd-net)
>
> I'm looking into the possibility of using my home FreeBSD box as my home
> firewall/NAT box, to replace my Linksys E2000 router (which runs Linux,
> specifically the TomatoUSB firmware).
>
> I plan on using pf for the NAT and firewall layer.  ipfw will not be
> used (I have long since moved away from it).  I've got solutions for
> everything except two items:
>
> 1) Wireless hardware support
>     - What consumer PCI cards are known to be reliable and have good
>       support on FreeBSD?  It looks like anything that relies on ath(4)
>       might be a good choice, but I'm not sure what specific chipset is
>       considered decent/worthwhile, or if there's a specific model of
>       card from Vendor X(tm) which works great.

I have a ton of Atheros 5212s deployed as access points. They are solid. 
Some field-tested implementations:

- Netgear WPN311NAR
- D-Link WDA-2320

Plenty of these to be found on eBay.

>     - The card and driver need to support both 802.11b and 802.11g
>       simultaneously.  802.11n (for the future) would also be good.

Simultaneous 802.11b and 802.11g works, but the 5212 chipset does not 
support 802.11n.

>     - Driver or OS needs 128-bit WEP -- this is not a joke, I really do
>       have devices which do not do WPA or WPA2.

This works.

>     - MAC address filtering is needed too, but it looks like that's
>       already available (looking at ifconfig(8) man page).

Indeed.

> 2) Layer 7 filtering
>     - Specifically, the ability to block outbound packets in real-time
>       which contain certain data in the TCP data portion of the packet.
>     - More details: there are some HTTP-based requests which some
>       software I use on XP submits to a server pool to return some ads.
>       Filtering by IP address isn't possible since the A records of
>       the FQDN often change.  The software in question does not honour
>       system proxy settings, so use of a proxy (Apache, squid, etc.)
>       as a solution will not work.
>     - I filter based on GET parameters or the HTTP: Host header.  Thus,
>       the matching mechanism doesn't need regex; simple substring matches
>       (e.g. strcasestr()) would work fine.
>     - Linux has kernel modules called ipt_web and xt_web which can do
>       exactly this.  They return TCP RST to the client which submit the
>       packet, and never forwarding the original packet out the WAN.
>
> Item #2 above seems to be the kicker.  Is there anything in the works
> regarding such a capability?  I'd be more than happy to test out code or
> whatever.

I don't have anything ideal for this, but will mention a series of 
horrible hacks to at least get the conversation started. I am working on 
a general-purpose, modular network-analysis framework in userspace 
(C/C++). One of the things that already works is an HTTP-parsing module. 
The code is totally suitable for taking some kind of action upon seeing 
a certain GET request or Host header. Of course, any action would be a 
race condition with the reply to the GET request. Though it leaves a bad 
taste in everyone's mouth, I think it would be fine in practice, as the 
web server's response would arrive a few milliseconds later due to 
distance, network hops, etc. The final issue is one of where to get the 
TCP state to send a valid RST packet to kill the client's TCP 
connection. The pf "flush" command looks almost like what you want, but 
a cursory glance at it suggests that it drops *all* state associated 
with an IP address. If that is the case, it's too much. The only other 
thing that comes to mind is running something like dsniff on the machine 
and calling tcpkill from the HTTP-parsing module. I may well implement 
TCP sequence number tracking and such in my code someday, but not in the 
timeline you're working with.

Development tarball attached for completeness.

-Boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sensor-2011-02-10.tbz
Type: application/octet-stream
Size: 83520 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20110210/01c61bad/sensor-2011-02-10-0001.obj