DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 27th May 2015
JuicyWho JuicyWho is offline
New User
 
Join Date: May 2015
Posts: 5
Default PF proto if not ! and table script question.

After a few days of searching "and utterly failing at it" I figured I would post my question here.

I was wondering if anyone knew if the 'if not' ! option or similar exists for the proto/protocol field. I've tried most of the iterations I could think of with no luck.


I've also been searching for a clean script capable of reading /var/log/pflog and adding any inbound blocks to a table. Thus far I've only seen one and while its brilliant, it seemed overly complex.
I'm a bit of a minimalist and my gut is telling me there's a simpler solution.


Info:
Currently running a minimal install of 5.7 as a perimeter firewall.
0 additional packages installed, the goal is to keep the system 100% clean.
The pf only allows 1 proto, 1 port and traffic to and from the external vpn.

Any info would be greatly appreciated.
Thanks
Reply With Quote
  #2   (View Single Post)  
Old 27th May 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Hello, and welcome!

The protocol field does not have the "!" option. See the GRAMMAR section of pf.conf(5) for details.

I have never used pflog records to programmatically revise tables. Instead, I've either used PF's stateful tracking options or I've used divert(4) to add addresses to tables. Can you describe what you intend? There may be a built-in solution.
Reply With Quote
  #3   (View Single Post)  
Old 27th May 2015
JuicyWho JuicyWho is offline
New User
 
Join Date: May 2015
Posts: 5
Default

Thanks for the fast response and the links m8.

The reason for the script would be to permanently add any inbound connection attempts to a table, run the .sh as a cron frequently and reload pf.

If there's a way to do this without reading the pflog or using proxy state and allowing a handshake any info would be appreciated

I'm running a block all / whitelist setup so a block table really isn't required. But having a <blockedip> table with log off would help quiet things down. -I'm on a noisy network.

Thanks again.
Reply With Quote
  #4   (View Single Post)  
Old 27th May 2015
TronDD TronDD is offline
Spam Deminer
 
Join Date: Sep 2014
Posts: 304
Default

If you don't want the noise of blocked incomming connections in the log, then why are you logging it?

If you have a whitelist of allowed IPs, just add those to a table and log if they are in that table so you can debug connection problems for the whitelisted IPs.

Pf's overload system can probably be made to do what you want, though. Peter's pf presentation talks about it as "bruteforce" protection.
Reply With Quote
  #5   (View Single Post)  
Old 27th May 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

pflog(4) is intended for analysis and debugging. The two other table manipulation methods mentioned -- stateful tracking, and divert(4) -- are designed for dynamic traffic management.
  • A whitelist (in PF terms, block by default) ruleset doesn't require any tracking. Unwanted traffic
    is blocked already.
  • A blacklist (in PF terms, pass all, except block abusers) is best managed by stateful tracking options. These define abuse, add abusers to a blacklist table, and cancel existing states. I use divert(4) with PF's divert-packet when the definition of abuse needs to be managed by userland application, outside of PF. My use-case was discussed here.
A blend of whitelist / blacklist rules are common. Typically, we whitelist our client and internal server connections, and set up blacklists for public, Internet-facing services. The most common method to do that dynamically is stateful tracking.

See Stateful Tracking Options in the PF User's Guide.
---
Reply With Quote
  #6   (View Single Post)  
Old 27th May 2015
JuicyWho JuicyWho is offline
New User
 
Join Date: May 2015
Posts: 5
Default

Quote:
Originally Posted by TronDD View Post
If you don't want the noise of blocked incomming connections in the log, then why are you logging it?
Because logging is helpful and required in this setup.
More often than not the same ip 'usually a bot' frequently rescans the same ports. Filling the logs up with clutter. Using a script to scan the log file for specific things then add them to a non-logged block list would reduce the noise.

Quote:
Originally Posted by TronDD View Post
Pf's overload system can probably be made to do what you want, though. Peter's pf presentation talks about it as "bruteforce" protection.
I'll look into the overload system again. But I was under the impression it required a handshake.

Quote:
Originally Posted by jggimi View Post
pflog(4) is intended for analysis and debugging. The two other table manipulation methods mentioned -- stateful tracking, and divert(4) -- are designed for dynamic traffic management.
  • A whitelist (in PF terms, block by default) ruleset doesn't require any tracking. Unwanted traffic
    is blocked already.
  • A blacklist (in PF terms, pass all, except block abusers) is best managed by stateful tracking options. These define abuse, add abusers to a blacklist table, and cancel existing states. I use divert(4) with PF's divert-packet when the definition of abuse needs to be managed by userland application, outside of PF. My use-case was discussed here.
A blend of whitelist / blacklist rules are common. Typically, we whitelist our client and internal server connections, and set up blacklists for public, Internet-facing services. The most common method to do that dynamically is stateful tracking.

See Stateful Tracking Options in the PF User's Guide.
---
I'm using a stateful setup already.
The divert option would be nice for a webserver type of setup. However normally in that situation I would only allow inbound to the "changed" ssh port from my ip or subnet + with OS options. But as this is a perimeter firewall no inbound is required on the wan.

I'm also not a huge fan of using mass block lists as they are often not updated quickly / become stale. Thus you end up blocking ip's that are no longer assigned to the compromised system. And unfortunately they will never stop anyone that actually wants in, just some bots.

We used to use Suricata for this while running 3 custom rules that dropped/alerted all ipv4/ipv6. Then had any alert created by those rules added to the block list. We then used a simple whitelist so no alerts were made for the wan/lan/vpn ip's. Once the ip was in the block list it was no longer logged by the system firewall. When pen testing this helped a lot in dos situations as logging alone can hit the system hard.

The above system was on pfsense. But I really don't like the direction its heading. Thus I was hoping to replicate such a system running on a pure OpenBSD setup. Why not make use of the godly auditing

-I'll read more about overload and keep hunting around.

Thanks for the links.
Reply With Quote
  #7   (View Single Post)  
Old 27th May 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by JuicyWho View Post
I'll look into the overload system again. But I was under the impression it required a handshake.
It requires a communication which creates state. This can be a TCP handshake but other protocols create state in PF -- these are by timing rather than handshake, and you can adjust timings for state table entries associated with stateless protocols. From the PF User's Guide:
Quote:
Keeping State for UDP

One will sometimes hear it said that, "One can not create state with UDP as UDP is a stateless protocol!" While it is true that a UDP communication session does not have any concept of state (an explicit start and stop of communications), this does not have any impact on PF's ability to create state for a UDP session. In the case of protocols without "start" and "end" packets, PF simply keeps track of how long it has been since a matching packet has gone through. If the timeout is reached, the state is cleared. The timeout values can be set in the options section of the pf.conf file.
Your logging of all incoming packets consumes significantly more resources than a 3-way TCP handshake and a transient state table entry. While you've stated that logging is a requirement, with the information provided so far it appears to be a political requirement rather than a technical one.
Quote:
The divert option would be nice for a webserver type of setup.
It's useful any time stateful processing doesn't address an issue which can be addressed by a programmatic go/no-go decision. I also run public-facing webservers that operate privately, via client certificates for authentication.
Quote:
I'm also not a huge fan of using mass block lists as they are often not updated quickly / become stale. Thus you end up blocking ip's that are no longer assigned to the compromised system. And unfortunately they will never stop anyone that actually wants in, just some bots.
I delete stale entries in my blocking tables via daily(8), as mentioned in the use-case link above. And my public facing systems are protected in a variety of ways which mitigate risk.

At this time, these block lists prevent (or limit) bots, some annoying script kiddies, and some forms of DOS attacks -- real or inadvertent. They reduce resource consumption or protect from certain types of network load impacts.They do not provide any "security" under anyone's definition.
Reply With Quote
  #8   (View Single Post)  
Old 27th May 2015
JuicyWho JuicyWho is offline
New User
 
Join Date: May 2015
Posts: 5
Default

Quote:
Originally Posted by jggimi View Post
While you've stated that logging is a requirement, with the information provided so far it appears to be a political requirement rather than a technical one.
It really shouldn't matter if logging is political or technical. And frankly somethings wrong if it being one or the other changed your response. But FWIT the resulting block file will now be shared with the other web facing local systems. -so technical.

In any case have a functioning script. Thanks.

-Solved
Reply With Quote
  #9   (View Single Post)  
Old 27th May 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

My apologies -- I did not mean to offend you. It was a poor choice of words to state that based on my understanding of the information provided, it did not appear *technically* necessary.

I'm sorry. I used a word which may have negative connotations, but did not intend anything negative by it.
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
attacks are not being added to the pf table Daffy OpenBSD Security 4 21st October 2011 04:03 PM
why won't my table work? tomp OpenBSD Security 3 25th August 2011 12:23 PM
match vs pass (changes in 4.7), and inet vs inet proto mikesg OpenBSD Security 4 12th June 2010 02:35 AM
I think I just mangled my partition table Mantazz FreeBSD Installation and Upgrading 2 2nd July 2009 09:55 PM
Quick question about PHP script 18Googol2 Programming 2 21st September 2008 05:33 AM


All times are GMT. The time now is 10:19 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