Tuesday, December 29, 2009, 6:20:37 AM, you wrote: > On Mon, Dec 28, 2009 at 05:50:23PM -0600, Adam Vande More wrote: >> On Mon, Dec 28, 2009 at 4:59 PM, Chris H <chr...@1command.com> wrote: >> >> > >> > My point here was that by increasing the verbosity, you will more easily be >> > able >> > to grep against login /failures/, and more easily discover dictionary/ >> > brute-force >> > attacks. It's certainly made my job easier, and hasn't required any >> > modifications >> > to our current policies. You /have/ considered PF(4), haven't you? It's >> > /really/ >> > an excellent strategy for securing your network. >> > >> > --Chris H >> > >> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > >> >> I use security/denyhosts for this, very simple to setup like 5 minutes if >> you're a fast reader. There are other options as well that offer similar >> functionality.
> Then I simply do /etc/rc.d/pf check && /etc/rc.d/pf reload.
> I also have a script that pushes out the pf.conf.ssh-deny machines
> to other hosts on our network and executes the above commands.
Increase verbosity ? why not just create a pflog file just for port 22
or whatever you listen on for ssh or some kind of login and parse
that. See attached script for a start on parsing the explained pflog.
I have been toying around with the attached idea that makes use of
connection tracking in pf.
pass in log quick proto { tcp } from any port >1024 to any port \
{ $shports } label "SCT/Login:$dstport" keep state (max-src-conn 5, \
max-src-conn-rate 15/30 overload <blacklist> flush global)
This has worked out quite well so far but the script that is attached
has a few bugs and optimizations that could be made to it but it does
its job regardless without third-party utilities. I have added some
parsing of the pflogs through the use of tcpdump and sed to pull bad
IPs out as well but do not use that on a regular basis. I have the
script setup in a cron job to run once a hour and pull the IPs from
the active table and combine the contents with the blacklist file and
ultimately sort, uniq & reload the table with the contents of the
blacklist file making adding IPs to the blacklist just add to the
table on the next cron run..
Depending on where you put your blacklist deny rule you can be saving
the rest of your services from the attackers to.
Still lots of work to be done on this but I figured I would put it out
there for someone else to toy with and see what comes out of it.
Best regards.
--
Tuesday, December 29, 2009 12:09:10 PM
jhell
pflog_fil.sh
Description: Binary data
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
