DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD Security

FreeBSD Security Securing FreeBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 3rd December 2013
irukandji irukandji is offline
Port Guard
 
Join Date: Jul 2013
Posts: 11
Thanked 0 Times in 0 Posts
Default PF dynamic adding of ips to table (booby trap port)

As i have only few ports opend to the internet within the service range i would like to booby trap others to block any host that sends tcp or udp packet to any of them.

What i am having problem with is dynamically adding the offending ip to the table (most likely port scan), something like:

table <honeypot> persist
block quick from <honeypot>
pass in on em0 proto tcp from any to any port 1:24 "add ip to" <honeypot>

The problem is that i cant find syntax to add the ip sending the packet to the honeypot table, is this even possible? The overload has this possibility but this is not about the connection count as the handshake is not even done yet - there should be no traffic so any kind of tcp packet should be enough to get blocked.
Reply With Quote
  #2   (View Single Post)  
Old 3rd December 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,825
Thanked 214 Times in 189 Posts
Default

I think you're looking for the overload and flush stateful tracking options, which are designed to add offending IPs to a table (overload) and kill any established states (flush).
Reply With Quote
  #3   (View Single Post)  
Old 3rd December 2013
irukandji irukandji is offline
Port Guard
 
Join Date: Jul 2013
Posts: 11
Thanked 0 Times in 0 Posts
Default

yep overload would be fine but it requires max-src-conn or max-src-conn-rate. As the connection is not established (tcp handshake not done yet), even max-src-conn 1 wouldnt trigger it, so it is unadequate for what i want to achieve. For the port scans, completing the handshake is overhead, sending syn and waiting for syn-ack is more then enough. Also there is no listener running on those ports so the handshake is never established, the synproxy would be an option but not really usefull...

Last edited by irukandji; 3rd December 2013 at 09:13 PM.
Reply With Quote
  #4   (View Single Post)  
Old 3rd December 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,825
Thanked 214 Times in 189 Posts
Default

Hmmm... It appears that I've misinterpreted the syntax rules, then, as from pf.conf(5) it looks like the only dependency is is that flush requires overload.
Code:
     state-opt      = ( "max" number | "no-sync" | timeout | "sloppy" |
                      "pflow" | "source-track" [ ( "rule" | "global" ) ] |
                      "max-src-nodes" number | "max-src-states" number |
                      "max-src-conn" number |
                      "max-src-conn-rate" number "/" number |
                      "overload" "<" string ">" [ "flush" [ "global" ] ] |
                      "if-bound" | "floating" )
I've never had a desire to honeypot, so I've never tried something like setting max-src-nodes to 0 to see if that elimates state or if it sets no limit. Instead I've used overload or overload with flush where I wished to stop bad behavior.

To the best of my recollection, PF tables are manipulated only via pfctl(8) commands or stateful options.
Reply With Quote
  #5   (View Single Post)  
Old 3rd December 2013
irukandji irukandji is offline
Port Guard
 
Join Date: Jul 2013
Posts: 11
Thanked 0 Times in 0 Posts
Default

I hoped i am missing something... *grumble*

I'll check the sources if this can be changed without much of a problems and submit it
Reply With Quote
  #6   (View Single Post)  
Old 4th December 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,825
Thanked 214 Times in 189 Posts
Default

I just did some testing; you are correct, the syntax permits overload to be specified but pfctl(8) will insist on max-src-conn or max-src-conn-rate. Nor will pfctl permet max-src-conn or max-src-nodes set to 0.

If you want to create a honeypot using PF as designed, you're going to have to permit at least one connection. Consider redirecting traffic to a tarpit listener.
Reply With Quote
  #7   (View Single Post)  
Old 4th December 2013
irukandji irukandji is offline
Port Guard
 
Join Date: Jul 2013
Posts: 11
Thanked 0 Times in 0 Posts
Default

Ok, i have solved it this way, i dont like it but it works... And captured one offender within first 5 minutes... Practically all service ports except few that i am using are booby trapped.

tcpdump -lq -n "(not src net x.x.x.x mask y.y.y.y) and ((tcp dst portrange n-nn) or (tcp dst portrange n1-nn1)" | awk '{split($3,a,"."); system("pfctl -t tarpit -T add "a[1]"."a[2]"."a[3]"."a[4]) }'
Reply With Quote
  #8   (View Single Post)  
Old 4th December 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,825
Thanked 214 Times in 189 Posts
Default

Wow! That's certainly creative.

If I were to set up a honeypot, it would be for attack analysis. I would probably deploy honeyd and direct unwelcome traffic there via PF. However, I've not bothered, as no attempted (and noticed) attacks so far have warranted any analysis.
Reply With Quote
  #9   (View Single Post)  
Old 5th December 2013
irukandji irukandji is offline
Port Guard
 
Join Date: Jul 2013
Posts: 11
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by jggimi View Post
Wow! That's certainly creative.

If I were to set up a honeypot, it would be for attack analysis. I would probably deploy honeyd and direct unwelcome traffic there via PF. However, I've not bothered, as no attempted (and noticed) attacks so far have warranted any analysis.
Well analysing attacks would take a lot of time (since my post, i already catched 11 IPs contacting different ports) and this way it is faster. Every attack will start with some kind of probing and this way probing is also the last action they will perform. Beside that, that "security by obfuscation" aka moving services to different ports gets a new meaning as you need to hit it before you hit booby trapped port... and this is very small target with booby trap before and after it, plus multiple blocks of ports (like most of 1-1055) I was testing it with grc.com SYN scan and it managed to scan 29 ports before beeing banned. Botnet would maybe stand a chance

Ah one more thing, port 80 was left out of blocking where index is verifying if connecting client is tarpitted and captcha is shown to remove the blockage... (well... 98% of code done )

Last edited by irukandji; 5th December 2013 at 12:17 AM.
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
Security Web server backdoor also booby traps lighttpd and NGINX J65nko News 0 8th May 2013 09:50 PM
opera bug in openbsd 5.1 release with Abort Trap message daemonfowl OpenBSD Packages and Ports 2 26th May 2012 06:42 AM
why won't my table work? tomp OpenBSD Security 3 25th August 2011 12:23 PM
Fatal trap 12: page fault while in kernel mode sixshot FreeBSD General 11 18th July 2008 12:53 AM
Ajax dynamic table/spreadsheet robbak Programming 1 7th June 2008 10:33 PM


All times are GMT. The time now is 09:53 PM.


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