I'm about to setup a new box with FreeBSD 9 and I'm wondering if you did anything to get this to work?
[HOWTO] FreeBSD 7.x 8.x + IPFW + Brute Force Monitor + block_ip.sh
- Thread starter mmx
- Start date
I'm about to setup a new box with FreeBSD 9 and I'm wondering if you did anything to get this to work?
mmx
Verified User
There is no reason why the ruleset and scripts posted on here would not work with FreeBSD 9.0. Make sure that when you upgrade, the ipfw binary is also updated. What method will you be using for the 8 to 9 upgrade? freebsd-update? If so, you are not supposed to have any issues. Please keep us posted.
mmx
Verified User
zEitEr
Super Moderator
You might want to aggregate IPs into subnets then.
zEitEr
Super Moderator
I don't use FreeBSD with Directadmin any more, so you should either find a How-To/guide here or other places, or find somebody who would do it for you for free or as a commerce service. I could be the person who can do it for you, but it will cost you some money. So if you want feel free to PM me for a quote, of wait here for somebody else's replies and suggestions.
- Joined
- Feb 27, 2003
- Messages
- 8,500
Just an FYI, I've added the ipfw commands from this guide to our 3 .sh scripts (block_ip.sh, show_blocked_ips.sh, unblock_ip.sh), which are written for CentOS (basic uname check to use ipfw instead of iptables).
The changes to these 3 scripts require the ipfw.rules, as they use the 'table 10' option.
The benefit of the CentOS script is that they also use the /root/blocked_ips.txt file, which supports the dateblocked option.. which would then allow the use of the automatic unblock feature.
Related:
http://help.directadmin.com/item.php?id=380
Feel free to change the guide in post #1 to reflect these changes (download our scripts if you'd like).
Let me know if there are any issues with the way I've done it.
John
The changes to these 3 scripts require the ipfw.rules, as they use the 'table 10' option.
The benefit of the CentOS script is that they also use the /root/blocked_ips.txt file, which supports the dateblocked option.. which would then allow the use of the automatic unblock feature.
Related:
http://help.directadmin.com/item.php?id=380
Feel free to change the guide in post #1 to reflect these changes (download our scripts if you'd like).
Let me know if there are any issues with the way I've done it.
John
Hey guys, I did not come back here for a long time.
The dynamic rules are still not working on my end and I keep blocking the abusive IP's manually. I guess this has to be something related to my ipfw.rules file since it's quite different from what is posted in the tutorial. Let me show it to you:
Any thoughts? Many IP's are listed in "Blocked IPs" in the Bruteforce monitors and they are not actually blocked... Here is an example:
The dynamic rules are still not working on my end and I keep blocking the abusive IP's manually. I guess this has to be something related to my ipfw.rules file since it's quite different from what is posted in the tutorial. Let me show it to you:
Any thoughts? Many IP's are listed in "Blocked IPs" in the Bruteforce monitors and they are not actually blocked... Here is an example:
zEitEr
Super Moderator
Hello,
You've got deny after the all allow rules. In this the case, you'll never get any IP blocked with the firewall.
You should consider the order (firstly you deny connections, then only you allow connections), the best will be to follow the How-To step-by-step and do not write your own rules, until you know how to write them in correct order.
You've got deny after the all allow rules. In this the case, you'll never get any IP blocked with the firewall.
You should consider the order (firstly you deny connections, then only you allow connections), the best will be to follow the How-To step-by-step and do not write your own rules, until you know how to write them in correct order.
Do you mean the "#blacklists" part? It definitely blocks the IP's - it stops the bruteforces...
Only the dynamic rules are not working... The above is hardcoded and very hard to manage + I have to restart the firewall each time I need to add new IP which is bad.
Only the dynamic rules are not working... The above is hardcoded and very hard to manage + I have to restart the firewall each time I need to add new IP which is bad.
zEitEr
Super Moderator
zEitEr
Super Moderator
OK, in your particular case you seem to be protecting only SSH port. But not POP3/IMAP/SMTP/FTP.
So is that what you want?
So is that what you want?
All services except SSH are open to public. When the bruteforce monitor show abuser with thousands of hits to me (regardless if he is bruteforcing proftpd or exim), I add him into the "#blacklists" part like I shown above:
Then I restart IPFW and this effectively blocks the abuser. Later I remove the bad IP's to clean-up the ipfw.rules file. Now I have only one blocked IP there, as shown in my previous reply.
That way the config above works. What is not working is the automatic block of abuser from the block_ip.sh script in this thread. It does add them correctly, reminder:
but they are not blocked at all - they continue to bruteforce me even listed there.
So this has something to do with what you said... But I am unsure what exactly.
Then I restart IPFW and this effectively blocks the abuser. Later I remove the bad IP's to clean-up the ipfw.rules file. Now I have only one blocked IP there, as shown in my previous reply.
That way the config above works. What is not working is the automatic block of abuser from the block_ip.sh script in this thread. It does add them correctly, reminder:
but they are not blocked at all - they continue to bruteforce me even listed there.
So this has something to do with what you said... But I am unsure what exactly.
zEitEr
Super Moderator
Let me explain it once more and the final time.
Firstly, the order of your rules is a bit confusing and incorrect:
Once you allowed connections:
you won't be able to block them with section #blacklists - HERE I BLOCK BAD IP's, which comes bellow the allow rules. Is that clear? If not, then please read this http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html
Secondly, you've got no table rule, which is supposed to be used for autoblocking.
Thus, please use the guide step-by-step, and you will get the things working. If you don't use the guide, please read the handbook until you understand how the ipfw works.
Firstly, the order of your rules is a bit confusing and incorrect:
Once you allowed connections:
Code:
add allow tcp from any to any 20 in setup keep-state
add allow udp from any to any 20 in setup keep-state
add allow tcp from any to any 21 in setup keep-state
add allow udp from any to any 21 in setup keep-state
add allow tcp from any to any 25 in setup keep-state
add allow tcp from any to any 110 in setup keep-state
add allow tcp from any to any 143 in setup keep-state
add allow tcp from any to any 587 in setup keep-state
add allow tcp from any to any 465 in setup keep-state
add allow tcp from any to any 2222 in setup keep-stateyou won't be able to block them with section #blacklists - HERE I BLOCK BAD IP's, which comes bellow the allow rules. Is that clear? If not, then please read this http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html
Secondly, you've got no table rule, which is supposed to be used for autoblocking.
Thus, please use the guide step-by-step, and you will get the things working. If you don't use the guide, please read the handbook until you understand how the ipfw works.
After running this setup for a while on 2 production servers I noticed that connections in FIN_WAIT* state were building up. Also the Firewall rules list was getting bigger.
I never thought of it that much until I got a message 1 server was ddossing somebody with ACK packets
This guy had visited 1 url on the entire server once 2 days before and his connection remained in FIN_WAIT_2 and the server was ACKing him all the time.
So for a week now i'm running this; My FIN_WAIT*s and firewall rules stay very low:
Code:
ipfw -d list | wc -l
4676
netstat -anf inet | grep FIN_WAIT | wc -l
8541I never thought of it that much until I got a message 1 server was ddossing somebody with ACK packets
Code:
Apr/01/2013 01:07:02 proto TCP (ACK), xx.xx.xx.xx->yy.yy.yyy.yy:50572, len 52
Apr/01/2013 01:07:02 proto TCP (ACK), xx.xx.xx.xx->yy.yy.yyy.yy:50567, len 52
Apr/01/2013 01:07:02 proto TCP (ACK), xx.xx.xx.xx->yy.yy.yyy.yy:50602, len 40
Apr/01/2013 01:07:02 proto TCP (ACK), xx.xx.xx.xx->yy.yy.yyy.yy:50597, len 40
Apr/01/2013 01:07:02 proto TCP (ACK), xx.xx.xx.xx->yy.yy.yyy.yy:50602, len 52This guy had visited 1 url on the entire server once 2 days before and his connection remained in FIN_WAIT_2 and the server was ACKing him all the time.
So for a week now i'm running this; My FIN_WAIT*s and firewall rules stay very low:
Code:
sysctl net.inet.tcp.fast_finwait2_recycle=1
>ipfw -d list | wc -l
133
>netstat -anf inet | grep FIN_WAIT | wc -l
28