From: Fabian W. <fa...@we...> - 2013-04-20 21:04:40
|
Hello Daniel On 19.04.2013 12:16, Daniel Black wrote: > If a rule with the table exists a new ipfw rules isn't created. I was just rethinking this, and you should loosen the check if there is a rule which does use a specific table. It is probably better to change: ipfw show | fgrep -q 'from table(<table>)' || to this: ipfw show | fgrep -q 'table(<table>)' || Because it could be, that there is maybe a rule like this: ipfw add 42 deny ip from not table\(1\) to me or even something like this: ipfw add 42 allow udp from any 123 to table\(1\) 123 Unfortunately it is not possible to check if there is a table in use or not, because 'ipfw table all list' shows only tables which have at least one IP address in it. Output from an other of my systems (again, sorry for the line wrapping): root@superman:~ # ipfw show | grep table 00005 50033 3134923 unreach port tcp from table(22) to me dst-port 22 in 00006 27645 1769389 deny ip from table(53) to me dst-port 53 in root@superman:~ # ipfw table all list ---table(22)--- 74.63.218.136/32 0 180.96.23.74/32 0 root@superman:~ # In the above output, there is currently no IP listed in the table(53), so is not shown with 'ipfw table all list'. Even when tried to show with the table number, it is not visible (64 as example of just a random not use table): root@superman:~ # ipfw table 22 list 74.63.218.136/32 0 180.96.23.74/32 0 root@superman:~ # echo $? 0 root@superman:~ # ipfw table 53 list root@superman:~ # echo $? 0 root@superman:~ # ipfw table 64 list root@superman:~ # echo $? 0 root@superman:~ # So you need to relay and check if there is any ipfw rule, which would be used by the configured jail. > If the table isn't used then create a early as possible rule to deny > traffic. The table is only created when it is filled with IP addresses, e.g. from actionban. >> 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. Cool. >> 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? You mean something like this?: ipfw add 1 deny ip from table\(1\) to me Yes, this works, it will block access from the source IP to any port locally on the system. This is probably a much better default, so table(1) can be used for multiple jails. I had it this way, until I once was in the same shared network (behind NAT) together with one of my mail users who mistyped his password once to much and I was blocked too. I even could not connect with ssh any more. Luckily I had an other system in the same network, which I could use as jump host to start debugging. ;) After that incident I changed my setup to block only the abused service. I was just thinking, is the actionstart/actionstop run for every jail which does use an action, or only once for all jails? > 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. This is fine. An advanced user always has the chance to set the 'table' in the jail configuration and then use own ipfw rules with it. > Thanks for the support, fixes and advice. You're welcome. I hope you will find what is causing f2b to not properly run the actionstart/actionstop. Good luck. If you have any questions regarding FreeBSD, do not hesitate to ask me. I am also in the #fail2ban IRC channel. bye Fabian |