DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 27th February 2009
gen2ly gen2ly is offline
New User
 
Join Date: Feb 2009
Posts: 2
Default pf: Does pf have the ability to src-track created/established connections?

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:

Code:
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?
Reply With Quote
  #2   (View Single Post)  
Old 27th February 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

What do you mean by "spoof my address"?

Excerpted from http://openbsd.rt.fm/faq/pf/filter.html#antispoof
Quote:
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.
Reply With Quote
  #3   (View Single Post)  
Old 27th February 2009
gen2ly gen2ly is offline
New User
 
Join Date: Feb 2009
Posts: 2
Default

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:

Code:
 (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:

Code:
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.

Last edited by gen2ly; 27th February 2009 at 02:41 PM.
Reply With Quote
  #4   (View Single Post)  
Old 27th February 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

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.

Last edited by jggimi; 27th February 2009 at 03:14 PM. Reason: clarity
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
track current kernel itti NetBSD Installation and Upgrading 8 11th December 2008 06:09 PM
Serial connections JMJ_coder General software and network 9 25th July 2008 03:28 PM
Problems with multiple ISP connections ebzzry FreeBSD General 2 1st July 2008 11:32 PM
More tcp connections tad1214 FreeBSD General 8 5th June 2008 03:05 PM
OpenVPN - Problem with connections MME General software and network 2 26th May 2008 06:42 PM


All times are GMT. The time now is 02:21 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick