DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 8th February 2017
damageG damageG is offline
New User
 
Join Date: Feb 2017
Posts: 6
Default pf Dropped Packets

I have a new firewall that is almost exactly the one show here

https://www.openbsd.org/faq/pf/example1.html

I don't think it should matter but I have a couple of VLAN on em1 so my internal interfaces look like:

int_if="{ em1 vlan101 vlan102 vlan103 }"

As far as I can tell, everything is working. I can see dropped packets coming in from the internet and get out to everything so far.

My LAN is on vlan102 and I'm getting some dropped packets coming from the LAN to the internet on the HTTPS port for services like dropbox. Dropbox seems to be working so I don't think it's a problem but I don't understand why these packets are being dropped when others are not.

Here is an example:
rule 4/(match) block in on vlan102: 10.x.x.x.54738 > 52.207.41.48.443: F 0:0(0) ack 1 win 254 (DF)

The rule

pass in on $int_if inet

allows most everything in on the LAN but not these.

Thanks in advance for any thoughts.
Reply With Quote
  #2   (View Single Post)  
Old 8th February 2017
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,971
Default

Hello, and welcome.

You're misreading your rule numbers. I know this because rule # 4 is a block rule, according to tcpdump(8), it cannot be a pass rule.

Rule numbers start with rule 0, and lists such as you are using are expanded into separate, unique rules.

To learn which rule is actually rule 4, use # pfctl -sr -R 4
Reply With Quote
  #3   (View Single Post)  
Old 8th February 2017
damageG damageG is offline
New User
 
Join Date: Feb 2017
Posts: 6
Default

Thanks, rule 4 is

Quote:
block drop log all
the macro for inf_if expands rule 8 to

Quote:
pass in on vlan102 inet all flags S/SA
And should pass the packet. Rule 8 is passing LAN traffic to the internet for the most part.
Reply With Quote
  #4   (View Single Post)  
Old 8th February 2017
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,971
Default

No, none of the rules after 4 are matching. If I'm reading the tcpdump output correctly, this is an unflagged packet and your rule requires flags.

(I don't use flags in my PF rules.)
Reply With Quote
  #5   (View Single Post)  
Old 8th February 2017
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,971
Default

I've been continuing to think about this. While I don't use the flags option on any of my own rule sets, and never have, flags S/SA keep state is the default for a pass rule.

My guess is this particular blocked packet is a TCP ACK which was received out of sequence, most likely after the TCP state had been torn down. This was an ACK to a remote port 443, so the likely originating application is a browser.

I wouldn't necessarily be concerned about an errant out-of-sequence ACK from a browser originating on a local 10/8 network.

(Yes, there are TCP injection attacks, but this doesn't look like one of them. They would normally originate on an external network, and contain data payloads.)
Reply With Quote
  #6   (View Single Post)  
Old 8th February 2017
damageG damageG is offline
New User
 
Join Date: Feb 2017
Posts: 6
Default

Just to see if I understand it, the line

Quote:
pass in on $int_if inet
Expands to

Quote:
pass in on vlan102 inet all flags S/SA
And a couple other interfaces with the same rules.

Dropbox is trying to use a TCP connection that has expired in the state table so pf sees an ACK and drops it because it's not an S/SA. I'm guessing that when the connection gets dropped, Dropbox opens a new one so it's not an issue.
Reply With Quote
  #7   (View Single Post)  
Old 8th February 2017
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,971
Default

You can show the loaded ruleset with expansions and options by issuing # pfctl -sr. (This doesn't show any anchor rulesets, if they are used. That requires the addition of -a <anchor> as described in the pfctl(8) man page.)

Quote:
Dropbox is trying to use a TCP connection that has expired...
You redacted it in your first post, but the ACK source appears to be a 10/8 RFC1918 address on your network, and not from the external server. This looks much more like a client workstation with a long-delayed response.

TCP is designed to provide end-to-end confirmation of transmissions, and include reassembly of packets that arrive at their destination in the wrong order, or eliminate duplicate packets that have already been confirmed to have arrived.

In this instance, , it appears the local workstation on the local network issued a packet so out-of-order that the TCP session had already ended. The root cause could be many things. A browser, for example.
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
pf : how to ignore TCP RST packets ? jcdenton OpenBSD Security 0 3rd August 2010 04:17 PM
Dropped to grub terminal, stumped. Jack OpenBSD Installation and Upgrading 3 12th December 2008 03:09 PM
Redirecting ESP packets ales OpenBSD Security 2 15th June 2008 09:13 PM
IPF: Packets Out Of Window bram85 FreeBSD Security 9 2nd June 2008 04:09 PM


All times are GMT. The time now is 04:18 AM.


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