pf: Does pf have the ability to src-track created/established connections?

[gen2ly]

I'm having a bit of a trouble with my firewall, an attacker has been able to spoof my address and is attacking my lan computer. I have antispoof rules in my pf.conf but they have gotten around them. So I'm thinking if I can't stop them, at least I can limit them. I have stateful tracking options on ssh, and apache but the attacker is using an already established connection (like that created by a web browser [<my.ip.address>:54535]) and doing unicode point attacks. My stateful tracking options are such:

WAN_STO="(max 5, source-track rule, max-src-states 5, max-src-conn 10, max-src-nodes 10, max-src-conn-rate 5/30, overload <blockedip> flush global)"

Is there a way to apply these to all connections?

[jggimi]

What do you mean by "spoof my address"?

Excerpted from http://openbsd.rt.fm/faq/pf/filter.html#antispoof

Example:

antispoof for fxp0 inet

When a ruleset is loaded, any occurrences of the antispoof keyword are expanded into two filter rules. Assuming that interface fxp0 has IP address 10.0.0.1 and a subnet mask of 255.255.255.0 (i.e., a /24), the above antispoof rule would expand to:

block in on ! fxp0 inet from 10.0.0.0/24 to any
block in inet from 10.0.0.1 to any

These rules accomplish two things:

• Blocks all traffic coming from the 10.0.0.0/24 network that does not pass in through fxp0. Since the 10.0.0.0/24 network is on the fxp0 interface, packets with a source address in that network block should never be seen coming in on any other interface.
• Blocks all incoming traffic from 10.0.0.1, the IP address on fxp0. The host machine should never send packets to itself through an external interface, so any incoming packets with a source address belonging to the machine can be considered malicious.

Stateful tracking is by individual pass rule.

If you describe the attack, as you understand it, someone might be able to help you.

[gen2ly]

Appreciate the quick response jggimi. I've got the antispoof rules up like you suggested and have tried several other variants but I have yet to find one that will be able to antispoof an established connection. These spoofs are from connections established from the web browser. Someone has been able to get a hold of my ip and port of established web connections and inject attacks. An example:

 (http_inspect) DOUBLE DECODING ATTACK 	 2009-02-27 07:59:07 	 192.168.xxx.yy:52493 	 208.43.92.218:80

The ip's are getting nat'd that's why the a 192.168.xxx.yy:52493 and are getting sent directly to the LAN computer. So (I'm guessing), to firewall it looks like an ordinary packet on an established connection. Here's the antispoof rules I'm using:

antispoof log for { lo0 $WAN_NIC $LAN_NIC }
block out log quick on $WAN_NIC from ! $WAN_NIC to any

So I thought I might have to take a new route with stateful tracking. ? Any thoughts on how I might be able to antispoof these ips? If not I'd really like to be able to slow them down.

[jggimi]

If I understand what you've posted, there is an attack vector from your webserver on softlayer.com's network block, into your private network. Do I understand that correctly?

If so, I'm astonished you would bother to obfuscate an RFC 1918 address, but not redact the IP address of your hacked or misconfigured webserver. That would be the address to remove from a public forum.

I don't necessarily understand why you are allowing the webserver to have unrestricted access to your private LAN. You should be able to limit it's access to necessary back end systems, such as DB servers, and limit it to specific ports, as well.

State table management will not help you at all with existing states, as you've discovered. Nor will antispoofing, since there is no address spoofing, there is an attack coming from your webserver. If I understand your problem, of course.

Best practice is to place Internet-facing servers in a DMZ between two firewalls. Forgive this ASCII diagram:

{internet} [FW1] -- Webservers, etc -- [FW2] -- {private network}

This allows for a fairly open set of rules for FW1, and a very restrictive set of rules for FW2. Access to the private network from the DMZ can be limited to necessary and valid connections from the DMZ servers -- such as a backend database -- which may eliminate the DMZ as a general attack vector into a private network, in the event of a misconfigured webserver, administrator ignorance, or other problems that enable an attack.