[HOWTO] FreeBSD 7.x 8.x + IPFW + Brute Force Monitor + block_ip.sh

bdj

Verified User
Joined
Feb 22, 2008
Messages
139
Strange but it stopped working since I upgraded to FreeBSD 9.0.........
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
Joined
May 8, 2005
Messages
112
Location
Montreal, QC, Canada
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.
 

bdj

Verified User
Joined
Feb 22, 2008
Messages
139
mmx, I decided to go with FreeBSD 8.3 because 9.0 is still beta for directadmin and I need to have a stable system.
I did implement your guide and it's working like a charm. Thumbs up!
 

mmx

Verified User
Joined
May 8, 2005
Messages
112
Location
Montreal, QC, Canada
mmx, I decided to go with FreeBSD 8.3 because 9.0 is still beta for directadmin and I need to have a stable system.
I did implement your guide and it's working like a charm. Thumbs up!
Welcome! Thank you for pointing out the "echo sysctl.conf" command issue. The guide has been reflected with the necessary changes. I have also raised the dyn_max value to 65535 instead of the default 4096 and the original value of 16384.
 

bdj

Verified User
Joined
Feb 22, 2008
Messages
139
After 9 days uptime I have

Code:
server9:admin>ipfw -d list | wc -l
    6315
So after 90/100 days 65535 is about reached. Do you have any idea how to solve this issue
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,871
Location
GMT +7.00
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.
 

bdj

Verified User
Joined
Feb 22, 2008
Messages
139
Thanks you for your offer.
I figured out that the number is dropping rapidly if I run sysctl net.inet.ip.fw.dyn_keepalive=0 for 5 minutes
 

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
8,923
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
 

wattie

Verified User
Joined
May 31, 2008
Messages
994
Location
Bulgaria
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:

#!/bin/sh
set -e
/sbin/sysctl net.inet.ip.forwarding=0 >/dev/null
/sbin/ipfw -q list >/dev/null 2>&1 || /sbin/kldload ipfw
(/sbin/ipf -D) >/dev/null 2>&1 || true
(/sbin/kldunload ipl) >/dev/null 2>&1 || true
(/sbin/pfctl -d) >/dev/null 2>&1 || true
(/sbin/kldunload pf) >/dev/null 2>&1 || true
/sbin/ipfw -q /dev/stdin << EOF
flush
add allow ip from any to any via lo0
add check-state
add reset tcp from any to any established
add allow tcp from any to any 80 setup in keep-state
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 udp from any to any 53 in keep-state
add allow tcp from any to any 53 in keep-state
add allow tcp from any to any 443 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-state
add allow tcp from any to me 3306 in setup keep-state
add allow tcp from any to any 49152-65535 in setup keep-state

#blacklists - HERE I BLOCK BAD IP's
add deny tcp from xxx.xxx.xxx.xxx to me

#whitelists - HERE I WHITELIST IP's with SSH access allowed
add allow tcp from yyy.yyy.yyy.0:255.255.255.0 to me 22 setup in keep-state

#after whitelists
add allow icmp from any to me icmptypes 8 in keep-state
add deny tcp from any to me setup in
add deny ip from any to me in
add allow tcp from me to any setup out keep-state
add allow ip from me to any out keep-state
add deny tcp from any to any setup
add deny ip from any to any
enable firewall
EOF
/sbin/sysctl net.inet.ip.forwarding=1 >/dev/null
/sbin/sysctl net.inet.ip.fw.dyn_ack_lifetime=3600 >/dev/null
Any thoughts? Many IP's are listed in "Blocked IPs" in the Bruteforce monitors and they are not actually blocked... Here is an example:

/etc: ipfw table 10 list
12.40.5.162/32 0
24.106.41.206/32 0
24.173.170.242/32 0
37.0.121.152/32 0
37.59.180.250/32 0
37.220.1.62/32 0
38.100.55.66/32 0
... // and many more!
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,871
Location
GMT +7.00
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.
 

wattie

Verified User
Joined
May 31, 2008
Messages
994
Location
Bulgaria
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.
 

wattie

Verified User
Joined
May 31, 2008
Messages
994
Location
Bulgaria
/: ipfw show
00100 944289 180560852 allow ip from any to any via lo0
00200 0 0 check-state
00300 362096 17362185 reset tcp from any to any established
00400 23176100 14339787330 allow tcp from any to any dst-port 80 setup in keep-state
00500 0 0 allow tcp from any to any dst-port 20 in setup keep-state
00600 0 0 allow udp from any to any dst-port 20 in setup keep-state
00700 126998 7915283 allow tcp from any to any dst-port 21 in setup keep-state
00800 0 0 allow udp from any to any dst-port 21 in setup keep-state
00900 1546306 1029837660 allow tcp from any to any dst-port 25 in setup keep-state
01000 316135 34866264 allow udp from any to any dst-port 53 in keep-state
01100 43 1956 allow tcp from any to any dst-port 53 in keep-state
01200 10850 3484004 allow tcp from any to any dst-port 443 in setup keep-state
01300 2280887 1908975288 allow tcp from any to any dst-port 110 in setup keep-state
01400 505216 334063810 allow tcp from any to any dst-port 143 in setup keep-state
01500 86277 56218084 allow tcp from any to any dst-port 587 in setup keep-state
01600 109 16896 allow tcp from any to any dst-port 465 in setup keep-state
01700 7618 3779048 allow tcp from any to any dst-port 2222 in setup keep-state
01800 17317 911899 allow tcp from any to me dst-port 3306 in setup keep-state
01900 233728 150655723 allow tcp from any to any dst-port 49152-65535 in setup keep-state
02000 0 0 deny tcp from 61.235.113.205 to me
02100 185292 22501732 allow tcp from 212.36.25.0/24 to me dst-port 22 setup in keep-state
02200 0 0 allow tcp from 82.137.72.0/24 to me dst-port 22 setup in keep-state
02300 0 0 allow tcp from 85.130.22.0/24 to me dst-port 22 setup in keep-state
02400 0 0 allow tcp from 85.130.5.70 to me dst-port 22 setup in keep-state
02500 0 0 allow tcp from 85.130.15.30 to me dst-port 22 setup in keep-state
02600 0 0 allow tcp from 91.193.156.234 to me dst-port 22 setup in keep-state
02700 0 0 allow tcp from 217.174.50.96 to me dst-port 22 setup in keep-state
02800 0 0 allow tcp from 217.174.49.188 to me dst-port 22 setup in keep-state
02900 0 0 allow tcp from 194.0.235.0/24 to me dst-port 22 setup in keep-state
03000 0 0 allow tcp from 81.161.240.0/24 to me dst-port 22 setup in keep-state
03100 0 0 allow tcp from 81.161.245.0/24 to me dst-port 22 setup in keep-state
03200 4494 263266 allow icmp from any to me icmptypes 8 in keep-state
03300 10307 453564 deny tcp from any to me setup in
03400 7239 1595286 deny ip from any to me in
03500 1651276 754499630 allow tcp from me to any setup out keep-state
03600 93311 17946689 allow ip from me to any out keep-state
03700 1392 60532 deny tcp from any to any setup
03800 218 46446 deny ip from any to any
65535 0 0 deny ip from any to any
61.235.113.205 is the only IP that I am currently blocking.

212.36.25.0/24 and the others below are my whitelists for SSH.
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,871
Location
GMT +7.00
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?
 

wattie

Verified User
Joined
May 31, 2008
Messages
994
Location
Bulgaria
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:

add deny tcp from xxx.xxx.xxx.xxx to me
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:

/etc: ipfw table 10 list
12.40.5.162/32 0
24.106.41.206/32 0
24.173.170.242/32 0
37.0.121.152/32 0
37.59.180.250/32 0
37.220.1.62/32 0
38.100.55.66/32 0
... // and many more!
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
Joined
Apr 11, 2005
Messages
13,871
Location
GMT +7.00
Let me explain it once more and the final time.


Firstly, the order of your rules is a bit confusing and incorrect:

When a packet enters the firewall it is compared against the first rule in the ruleset and progresses one rule at a time moving from top to bottom of the set in ascending rule number sequence order. When the packet matches the selection parameters of a rule, the rules' action field value is executed and the search of the ruleset terminates for that packet. This is referred to as “the first match wins” search method. If the packet does not match any of the rules, it gets caught by the mandatory IPFW default rule, number 65535 which denies all packets and discards them without any reply back to the originating destination.
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-state
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.
 

bdj

Verified User
Joined
Feb 22, 2008
Messages
139
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.

Code:
ipfw -d list | wc -l
4676
netstat -anf inet | grep FIN_WAIT | wc -l
8541
I 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 52
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:
sysctl net.inet.tcp.fast_finwait2_recycle=1

>ipfw -d list | wc -l
 133

>netstat -anf inet | grep FIN_WAIT | wc -l
  28
 
Top