RE: Source Tracking in PF
Cheers Ryan!
This is a big step towards DDoS proofing OpenBSD!
Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. 07855 805 271
http://www.devitto.com mailto:[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ryan McBride
Sent: Monday, December 15, 2003 12:24 AM
To: [EMAIL PROTECTED]
Subject: Source Tracking in PF
I just committed code which adds support to track stateful connections by
source IP address. This allows a user to:
- Ensure that clients get a consistent IP mapping with load-balanced
translation/routing rules
- Limit the number of simultaneous connections a client can make
- Limit the number of clients which can connect through a rule
As always, the more people who test this and provide feedback, the happier I
am. Read below for details.
-Ryan
SYNTAX:
The 'sticky-address' keyword applies to translation rules; the translation
address will be selected from the list, but once a client makes a
connection, all subsequent connections are translated the same way.
nat on $ext_if from $int_net to any - \
{ 10.1.2.1, 10.1.2.3 } round-robin sticky-address
Similarly in the following case, connections to a server are mapped
randomly, but all connections from a client are mapped the same way.
rdr on $ext_if from any to $ext_if - \
{ 192.168.0.4/30 } random sticky-address
In the case of tracking states per rule, the syntax is slightly different.
The 'source-track' state option is used to enable tracking, limits can also
be set there: 'max-src-states' limits how many states from a single source
can exist simultaneously and 'max-src-nodes'
limits how many source nodes can exist (effectively this is a limit on how
many clients can connect at once).
The following rule allows a maximum of 1000 source ip's to connect to a
webserver, each with a maximum of 3 simultaneous states:
pass in on $ext_if proto tcp to $webserver port www flags S/SA \
keep state (source-track, max-src-states 3, max-src-nodes 10)
By default, the source node is removed when all the states which reference
it are removed. However the timeout 'src.track' regulates how long the
source node is retained after all it's states have died.
set timeout src.track 900
A list of src nodes can be retrived with pfctl -sS, pfctl -vsS; pfctl -vsi
provides statistics on src-node useage (similar to the statistics provided
for states)
Re: Source Tracking in PF
On Sun, Dec 14, 2003 at 07:29:14PM -0800, Peter Hessler wrote: I was wondering if there was a way to use similar rules with ALTQ. E.G. Evenly split a queue for each source-ip on a /24. Allow each to use unused bandwidth, but guarantee each gets a fair percentage (in this example, each ip gets 6k/sec, and can borrow). this is called WFQ and is used inside each CBQ queue always...
fastroute/route-to on enc0 interface
Hi All, I am running 3.2 stable. This is what I am trying to achieve: I have specified say 192.168.1.0/24 network to be on a VPN. But only authenticated users are allowed over VPN, rest all should go clear. Lets say 192.168.1.32 is authenticated and 192.168.1.33 is not. The common part of the rules have: pass out quick on enc0 from 192.168.1.32 to any pass in quick on enc0 from any to 192.168.1.32 I haven't added any block rule yet, but have added the following rule: pass out quick on enc0 fastroute from any to any also I tried this: pass out quick on enc0 route-to (fxp0 172.16.1.1) from any to any (where 172.16.1.1 is the default router) I mostly have NAT rule: nat on fxp0 from !fxp0 to any - fxp0 This works if there is no NAT rules and if the internal address happens to be a routable address. But I cannot imagine so, with NAT the packet from 192.168.1.33 still gets encapsulated and goes over VPN. I hardly know the PF kernel code, but looks like the spd_lookup is successful (which is right, since 192.168.1.33 belongs to the ipgroup 192.168.1.0/24) and it looks like saving some info in the mbuf and then fastroute rule is matched, but its too late, so it encapsulates it. How can I get around this? Or am I doing something wrong? Pls advise. Thank You in advance --Gopu
Re: pf/Linux/Scrub
Per olof Ljungmark wrote: I was reading about OpenVPN in order to make a possible test bed when I came across the following statement: * If run through a firewall using OpenBSDs packet filter PF and the filter rules include a scrub directive, you may get problems talking to Linux hosts over the tunnel, since the scrubbing will kill packets sent from Linux hosts if they are fragmented. This is usually seen as tunnels where small packets and pings get through but large packets and regular traffic don't. Is this a valid comment? I'm not sure I understand what they mean... Are they referring to Linux sending fragmented packets with the don't fragment bit set? http://kerneltrap.org/node/view/579 .joel
