DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 13th March 2014
sparky's Avatar
sparky sparky is offline
Fdisk Soldier
 
Join Date: Mar 2012
Posts: 73
Default How to block Port Scans?

Hi,

I'm trying to figure out how to block port scans from the net on my OpenBSD router.

Currently the closest I've come is a site:

http://harrykar.blogspot.co.uk/2010/...lteringpf.html

which shows this as an example:

Code:
block in quick proto tcp all flags SF/SFRA
block in quick proto tcp all flags SFUP/SFRAU
block in quick proto tcp all flags FPU/SFRAUP
block in quick proto tcp all flags /SFRA
block in quick proto tcp all flags F/SFRA
block in quick proto tcp all flags U/SFRAU
block in quick proto tcp all flags P
I have added to my pf.conf and tested however, the second and last lines are not taken by PF which throws up an error.

Also using an Android based app "Fing" to do a TCP port scan, I am still able to detect "open ports". Though I've got Snort up and running which basically is giving me all kinds of ICMP sweeps and tcp/udp scan types.


I'm probably attacking this the wrong way so really the question is; is there a way to do this - or what would be an example of a way to do this?

{EDIT} outside of the obvious; closing ports! If one has web services like http or smtp running it really isn't an option :-)

Many thanks.
Reply With Quote
  #2   (View Single Post)  
Old 13th March 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
...the second and last lines are not taken by PF which throws up an error...
Usage and syntax for the TCP flags option is described in the pf.conf(5) man page. There, you will learn how to test for specific cleared or set flags.

---

Disclaimer one: I don't use flags options in any of my own rule definitions. I also don't recommend them to admins who do not have a clear understanding of each flag. Unless you understand each specific flag's specific purpose and role you may block desired traffic or inadvertantly permit undesired traffic.

TL;DR - Just because the tool gives you a gun, it does not mean you must pull the trigger. It's usually aimed at your own feet.

Disclaimer two: I don't believe blocking scans serves a useful purpose for those of us who use a block all policy and only pass permitted traffic, since only the permitted traffic will pass. I also use the return option with my block rules. I do this because appropriate blocked traffic that is dropped should learn about the drop immediately -- this limits application issues at the client. And I'm nice to the inappropriate traffic as well, because I don't believe dropping packets is useful, as there is no security through obscurity. Bad actors can still find the services I present to the Internet. For those services, I rely on application level protections such as authentication mechanisms.

TL;DR - Everything I don't want in is already blocked, whether they scan or not.
Reply With Quote
  #3   (View Single Post)  
Old 13th March 2014
sparky's Avatar
sparky sparky is offline
Fdisk Soldier
 
Join Date: Mar 2012
Posts: 73
Default

Thanks for the response.

Of course security at the application layer is important but if you can stop nastyness from getting there before it taxes the end servers less so they can do what they should be doing.... though I guess it's a bit of a tangent on the "chicken and egg" concpet???

I think I just felt like being invisible was the best way forward. My IDS is screaming at me for portscans though it might just be better to turn off those rules?
Reply With Quote
  #4   (View Single Post)  
Old 13th March 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Any device exposed to the Internet will be scanned. Welcome to 1992.

You cannot stop scanning from happening. You can only stop your IDS from seeing the scans or screaming about them.

In my case, as I noted above, due to block return rules, TCP scans to "closed" ports will receive an RST packet. I'm nice, that way. Mostly, because I want remote applications to be able to act on a connection failure immediately, and not undergo timeout handling, which I consider rude.

I'm not worried about the script kiddies, because eveni if I dropped blocked packets the kiddies will still find the services which are exposed. There is no "stealth" mode on the Internet, regardless what you may have read == all ports for all IP addresses are scanned constantly. This is the world we live in.

All we can do is try to ensure that all exposed services are as secure as we can make them. And that is an application specific subject.
Reply With Quote
  #5   (View Single Post)  
Old 13th March 2014
sparky's Avatar
sparky sparky is offline
Fdisk Soldier
 
Join Date: Mar 2012
Posts: 73
Default

Quote:
There is no "stealth" mode on the Internet, regardless what you may have read == all ports for all IP addresses are scanned constantly. This is the world we live in.
Dang.... they can make stealth aircraft but not networks :-( (though I think the F117's got phased out because people managed to detect them....)


Quote:
You cannot stop scanning from happening. You can only stop your IDS from seeing the scans or screaming about them.
Yeah.... I guess I'll just have to do that.

Quote:
In my case, as I noted above, due to block return rules, TCP scans to "closed" ports will receive an RST packet. I'm nice, that way. Mostly, because I want remote applications to be able to act on a connection failure immediately, and not undergo timeout handling, which I consider rude.
I set my PF rules up that way too.....


Actually this all came about as I was trying to integrate Snort into the network. Having tested it for a while I started to see a pattern of "false positives" so I'm currently in the 'tweaking' stage to get what I need out of it.

Though it's quite scary to see Snort reporting "Torjan-activity" or "Web application attack".... need to do more reading and more looking at tcpdump/wireshark output.
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 block command help newbsdied OpenBSD Security 1 7th November 2010 12:50 AM
Block IDM-DAP-P2P mohammadreza OpenBSD Security 5 25th February 2010 09:59 AM
block spam milo974 OpenBSD Security 1 26th May 2009 11:30 AM
Automaticaly block IPs with PF DNAeon FreeBSD Installation and Upgrading 7 20th February 2009 02:06 AM
nmap scans hamba FreeBSD Security 3 2nd February 2009 10:16 AM


All times are GMT. The time now is 02:02 PM.


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