Menu
▾
▴
Re: [Fail2ban-users] bsd ipfw
|
From: Daniel B. <dan...@in...> - 2013-04-19 10:16:46
|
On 19/04/13 04:26, Fabian Wenk wrote:
> Hello Daniel
>
> On 18.04.2013 01:00, Daniel Black wrote:
>> I've added the actionstart/actionstop for ipfw on bsd to create and
>> delete a rule related to a table.
>
> Ah, I guess this would at least help the users which don't want to
> create manual ipfw rules for fail2ban. You are probably aware, that I
> have a little more advanced bsd-ipfw f2b setup. :)
>
>> If someone has a ipfw capable BSD machine can you test this action out?
>
> I just had a look at it, and I tried to understand what it will do. As I
> see it, it should work even with my setup where I have created my own
> ipfw rules with tables for f2b. So I gave it a try, but as I use the
> bsd-ipfw action from the FreeBSD f2b Port, I called it bsd-ipfw-new.
I intended it this way to alleviate a maintenance difference for the
ports maintainers and to introduce it in a not-incompatible way.
If a rule with the table exists a new ipfw rules isn't created.
If the table isn't used then create a early as possible rule to deny
traffic.
> I
> have created the following jail (changed logpath to what FreeBSD
> sshd/syslogd is using on default):
Ack. I'll alter the default jail likewise.
> # bsd-ipfw is ipfw used by BSD. It uses ipfw tables.
> #
> [ssh-bsd-ipfw-new]
> enabled = true
> filter = sshd
> action = bsd-ipfw-new[port=ssh]
> logpath = /var/log/auth.log
> maxretry = 5
Appreciate the level of detail. I just got a FreeBSD VM running.
> I had to modify your actionstart a little (some minor typos), and then
> it is working if I run the command in the shell with manually filled in
> f2b variables. The below listed table(22) is from my own rules, so just
> "ignore" it. Sorry for the line wrapping:
>
> root@freebsd9:~ # ipfw show | fgrep -q 'from table(1)' || ( ipfw show |
> awk 'BEGIN { b = 1 } { if ($1 <= b) { b = $1 + 1 } else { e = b } } END
> { if (e) exit e ; else exit b }' ; num=$? ; ipfw -q add $num deny tcp
> from table\(1\) to me 22 ; echo $num >
> /var/run/fail2ban/ipfw-started-table_1 )
<table> and <delfile> are meant to be substituted tags. Thanks for
correcting the other errors. Not sure why quotes where removed - was
spaces in filenames protection. perhaps not needed to breaking other bits.
> root@freebsd9:~ # ipfw show | grep table
> 00001 0 0 deny tcp from table(1) to me dst-port 22
> 00005 12807 793264 unreach port tcp from table(22) to me dst-port 22 in
Nice idea. I've made the action configurable.
> root@freebsd9:~ # ls -l /var/run/fail2ban/
> total 8
> -rw------- 1 root wheel 6 Apr 18 16:42 fail2ban.pid
> srwx------ 1 root wheel 0 Apr 18 16:42 fail2ban.sock=
> -rw-r--r-- 1 root wheel 2 Apr 18 16:52 ipfw-started-table_1
> root@freebsd9:~ #
>
> And also the actionstop does work in the shell, but not from f2b:
sounds like some tracing/debugging needed.
> root@freebsd9:~ # [ -f /var/run/fail2ban/ipfw-started-table_1 ] && (
> read num < /var/run/fail2ban/ipfw-started-table_1 ; ipfw -q del $num ;
> rm /var/run/fail2ban/ipfw-started-table_1 )
> ipfw: DEPRECATED: 'del' matched 'delete' as a sub-string
fixed deprecation.
> root@freebsd9:~ # ipfw show | grep table
> 00005 12807 793264 unreach port tcp from table(22) to me dst-port 22 in
> root@freebsd9:~ # ls -l /var/run/fail2ban/
> total 4
> -rw------- 1 root wheel 6 Apr 18 17:07 fail2ban.pid
> srwx------ 1 root wheel 0 Apr 18 17:07 fail2ban.sock=
> root@freebsd9:~ #
>
>
> f2b complains with this errors (loglevel = 3):
>
> 2013-04-18 15:50:31,664 fail2ban.jail : INFO Jail 'ssh-bsd-ipfw-new'
> started
> 2013-04-18 15:50:31,703 fail2ban.actions.action: ERROR ipfw show |
> fgrep -q 'from table(1)' || (ipfw show | awk 'BEGIN { b = 1 } { if ($1
> <= b) { b = $1 + 1 } else { e = b } } END { if (e) exit e returned 200
>
> and with this with loglevel = 4:
>
> 2013-04-18 16:58:54,691 fail2ban.comm : DEBUG Command: ['set',
> 'ssh-bsd-ipfw-new', 'actionstop', 'bsd-ipfw-new', '[ -f <delfile> ] && (
> read num < <delfile>']
> 2013-04-18 16:58:54,691 fail2ban.actions.action: DEBUG Set actionStop =
> [ -f <delfile> ] && ( read num < <delfile>
> 2013-04-18 16:58:54,691 fail2ban.comm : DEBUG Command: ['set',
> 'ssh-bsd-ipfw-new', 'actionstart', 'bsd-ipfw-new', "ipfw show | fgrep -q
> 'from table(<table>)' || (ipfw show | awk 'BEGIN { b = 1 } { if ($1 <=
> b) { b = $1 + 1 } else { e = b } } END { if (e) exit e"]
> 2013-04-18 16:58:54,692 fail2ban.actions.action: DEBUG Set actionStart
> = ipfw show | fgrep -q 'from table(<table>)' || (ipfw show | awk 'BEGIN
> { b = 1 } { if ($1 <= b) { b = $1 + 1 } else { e = b } } END { if (e)
> exit e
> 2013-04-18 16:58:54,692 fail2ban.comm : DEBUG Command: ['set',
> 'ssh-bsd-ipfw-new', 'actionunban', 'bsd-ipfw-new', 'ipfw table <table>
> delete <ip>']
>
> and stop (loglevel = 4):
>
> 2013-04-18 17:16:18,648 fail2ban.actions.action: DEBUG [ -f
> /var/run/fail2ban/ipfw-started-table_1 ] && ( read num <
> /var/run/fail2ban/ipfw-started-table_1
> 2013-04-18 17:16:18,655 fail2ban.actions.action: ERROR [ -f
> /var/run/fail2ban/ipfw-started-table_1 ] && ( read num <
> /var/run/fail2ban/ipfw-started-table_1 returned 200
> 2013-04-18 17:16:18,656 fail2ban.actions: DEBUG ssh-bsd-ipfw-new: action
> terminated
>
>
> I am not sure what the reason is, maybe the long command line or some
> special characters (', or the single < or >) which fail2ban / python
> does not like.
Seems to be using the ; as a delimiter except that its planned to run in
a subshell because of ( and ).
> I was also chatting with Yaroslav and he pointed me to something else to
> test. So I modified the action and removed the actionstart / actionstop,
> restarted f2b and tried to add them with the fail2ban-client like this:
>
> root@freebsd9:~ # fail2ban-client set ssh-bsd-ipfw-new actionstart "ipfw
> show | fgrep -q 'from table(<table>)' || ( ipfw show | awk 'BEGIN { b =
> 1 } { if ($1 <= b) { b = $1 + 1 } else { e = b } } END { if (e) exit e ;
> else exit b }' ; num=$? ; ipfw -q add $num deny tcp from
> table\(<table>\) to me <port> ; echo $num > <delfile> )"
> Sorry but the command is invalid
Soon you won't need to quote it (
https://github.com/fail2ban/fail2ban/pull/134 )
> root@freebsd9:~ #
>
> And found this in the log file (loglevel = 4):
>
> 2013-04-18 18:06:02,425 fail2ban.comm : DEBUG Command: ['set',
> 'ssh-bsd-ipfw-new', 'actionstart', "ipfw show | fgrep -q 'from
> table(<table>)' || ( ipfw show | awk 'BEGIN { b = 1 } { if ( <= b) { b
> = + 1 } else { e = b } } END { if (e) exit e ; else exit b }' ; num=255
> ; ipfw -q add 1 deny tcp from table\\(<table>\\) to me <port> ; echo 1 >
> <delfile> )"]
odd that $? is 255 substituted.
> 2013-04-18 18:06:02,426 fail2ban.comm : WARNING Command ['set',
> 'ssh-bsd-ipfw-new', 'actionstart', "ipfw show | fgrep -q 'from
> table(<table>)' || ( ipfw show | awk 'BEGIN { b = 1 } { if ( <= b) { b
> = + 1 } else { e = b } } END { if (e) exit e ; else exit b }' ; num=255
> ; ipfw -q add 1 deny tcp from table\\(<table>\\) to me <port> ; echo 1 >
> <delfile> )"] has failed. Received IndexError('list index out of range',)
very odd. This seems like an internal error.
> I have attached the bsd-ipfw.patch with my changes (even if it is not
> yet working). I also have modified the delfile line, so that f2b can
> also work with multiple ipfw tables (one for each jail).
Didn't realize tags were substituted like that. Cool.
> But then they
> need to be specified in the jail, e.g. like this (on default tables can
> only range from 0 to 127
>, else the "port" could be abused for it):
Sounds excessively crude.
> action = bsd-ipfw[port=ssh, table=2]
>
>
> An other drawback I currently see, that your actionstart does only
> support TCP and not UDP (I have a jail for named, which does block UDP).
> If you only will block TCP with it, then it would probably be better to
> use:
>
> ipfw -q add $num unreach port tcp from table\(<table>\) to me <port>
>
> instead from:
>
> ipfw -q add $num deny tcp from table\(<table>\) to me <port>
>
> The 'unreach port' does send back to the offending IP an ICMP message
> that this port is closed. The 'deny' does just silently drop the packet.
> In my experience most scanning bot do stop sending traffic, as soon as
> they get the 'port closed' information.
I agree. I just made it consistent with every other action that does a
DROP/deny by default. I'm happy to suggest a patch to change the default
but I think it should be on all actions rather than just this one.
I've added an option for it to be configurable.
> To block all traffic (TCP and UDP) to a port, use this:
>
> ipfw -q add $num deny ip from table\(<table>\) to me <port>
Nice. made it an option with ip as default.
> But still, I guess your approach will have some more pitfalls, e.g. as
> pointed out above, with multiple jails, which would need multiple
> tables, and need to be configured in the jail.
It detects if a fw rule is already in place related to the table before
trying to add one so you can still, a) manually create the ipfw rule, or
b) rely on one jail being created before another that uses the same
table. Can you set port to blank?
> I am not that advanced with awk to really understand what "calculation"
> you are doing there. But I guess if there are already ipfw rules
> starting from 1 on upwards until the end of custom rules, then it could
> be that there are some allow rules before the f2b deny rules will be
> set.
Yes this was intentional.
The awk is just grabbing the first unused number. Should the start
number be configurable?
Means at least it needs to be documented more.
> In this case the packet will never reach the deny rule and access
> is granted even if banned from f2b. As far as I know, FreeBSD does
> support some simple rule sets which a user can activate,
If the FreeBSD maintainers haven't created a action for it maybe they
prefer custom rules. The aim here was to create a more function version
of what was in ports.
> but I have
> always uses my custom rules, so I do not know them.
>
> But sure if your actionstart/actionstop will be working from f2b, then
> it is an easier setup for FreeBSD IPFW user who just want do block e.g.
> ssh brute force. Advanced users will figure out how to use this bsd-ipfw
> action with a more complex setup.
Thanks for the support, fixes and advice.
|