Think bigger, much BIGGER

whois 180.76.5.24

180.76.5.24

inetnum:        180.76.0.0 - 180.76.255.255
netname:        Baidu
descr:          Beijing Baidu Netcom Science and Technology Co., Ltd.
descr:          Baidu Plaza, No.10, Shangdi 10th street,Haidian District Beijing,100080
country:        CN
admin-c:        WN141-AP
tech-c:         JC2179-AP
mnt-by:         MAINT-CNNIC-AP
mnt-lower:      MAINT-CNNIC-AP
mnt-routes:     MAINT-CNNIC-AP
status:         ALLOCATED PORTABLE
changed:        hm-changed@apnic.net 20090715

What's with the drop-down by the source IP? Does that contain anything useful, like a "within" setting perhaps?

Haha thanks guys - cheers for the additional range, where did you find that amount of detail from?

As for the drop down - I have:

Equals

Does not equal

Vonskippy, if the address range is 180.76.0.0 - 180.76.255.255 how can I ban the entire range? I read somewhere that the /24 does that but it may be wrong…

180.76.0.0/16 = 180.76.0.1-180.76.255.254

/24 is just a Class C network range

http://en.wikipedia.org/wiki/Subnetwork

Scroll down to the CIDR part for a good overview how the /24 (and others) subnetting works.

Pretty much any WHOIS utility will tell you the IP Range for any given IP.

Ok thanks mate - I have added it to the firewall rules using webmin and double checked it on ssh

DROP       all  --  180.76.0.0/16        anywhere  

Let's see how it goes!

Ok, as I thought it's not working - I just caught a load on my website now

180.76.5.52 is just one I picked out. Seems like the firewall is just not working ;(

Do this and report the results:

sudo iptables -L -n|grep "180.76.0.0/16"

Cheer jebblue, here is the result:

DROP       all  --  180.76.0.0/16        0.0.0.0/0     

I suspect you may need to take a wider view of your rules. Even if you have a specific DROP rule as you show, if there's an earlier rule in the chain that, for example, permits all web traffic to port 80, it'll never reach the DROP rule.

I'd dump the entire iptables and trace the rules that apply to the INPUT chain (and any associated chains called from it depending on how Webmin set up the filter) and reason about what would happen with the most recent source address, for example, that seemed to get through.

You'll still then need to figure out how to adjust the filters the way you want with Webmin (which I don't have any familiarity with), but at least you'll have an idea of why what is happening is happening.

– David

The only rules I have is for these specific addresses and fail2ban.

If I was to do this outside of webmin (ssh etc), what would you advise?

Just post ALL your rules (#iptables -L)

It wouldn't have to be for that specific Source Network.

As db3l mentioned, you could have a global rule bypassing your specific DROP rule.

Might be easier to help if you stated which Distro you're using.

Thanks guys. My Distro is Ubuntu 10.04

Here is the output:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere            multiport dports ssh 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain Hackers (0 references)
target     prot opt source               destination         
DROP       all  --  59.151.24.211        anywhere            

Chain baidu (0 references)
target     prot opt source               destination         
DROP       all  --  180.76.0.0/16        anywhere            
DROP       all  --  119.63.196.0/24      anywhere            
DROP       all  --  180.76.5.149         anywhere            
DROP       all  --  180.76.5.99          anywhere            
DROP       all  --  180.76.5.92          anywhere            
DROP       all  --  180.76.5.91          anywhere            
DROP       all  --  180.76.5.158         anywhere            
DROP       all  --  180.76.5.139         anywhere            
DROP       all  --  180.76.5.140         anywhere            
DROP       all  --  anywhere             anywhere            

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere  

Thanks for all the help, I really do appreciate it!

@crazyfruitbat:

Thanks guys. My Distro is Ubuntu 10.04

Here is the output:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere            multiport dports ssh

So this chain essentially allows anything through to your node (other than ssh traffic that might be blocked by the fail2ban-ssh chain, though that's currently empty). It has no block rules (nor calls any other chain with any), and its policy is to accept all traffic by default. Basically your node is wide open to incoming traffic.

Your baidu chain is never called, so nothing you have in it makes any difference. If you add a rule to the INPUT chain to call the baidu chain as the target you can invoke those exclusion rules, but I'm not sure of the process to do that by webmin. You can do it manually, but I don't know if or when webmin might rewrite the rules losing local changes. Although, if the baidu chain was created by webmin, it's odd it doesn't add a call to it itself.

BTW, although you can do it either way, I prefer to exclude anything not permitted in filters rather than permit anything not excluded. So I generally recommend having all default policies as DROP and then rules specifically for permitted traffic. Though I'll admit that is a matter of preference.

– David

Thanks for the help david - I have been trying to work out what is wrong with this the past few days and realised that it's all very messed up.

I put webmin on the server before having fail2ban running, actually fail2ban hasn't been running at all. I hadn't set up the config file.. So this morning I looking over the settings on fail2bans site and I basically blocked everything, couldn't access SSH, sftp and none of the sites work at all. I managed to get around by turning off the firewall rules using this: which I found online via lish:

# iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -P INPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P OUTPUT ACCEPT

And that at least got me back into the system, but I don't know what caused it to turn off everything. Can you see anything up with the config file?

# Fail2Ban configuration file.
#
# This file was composed for Debian systems from the original one
#  provided now under /usr/share/doc/fail2ban/examples/jail.conf
#  for additional examples.
#
# To avoid merges during upgrades DO NOT MODIFY THIS FILE
# and rather provide your changes in /etc/fail2ban/jail.local
#
# Author: Yaroslav O. Halchenko <debian@onerussian.com>#
# $Revision: 281 $
#

# The DEFAULT allows a global definition of the options. They can be override
# in each jail afterwards.

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 180.11.85.131
bantime  = 1209600
findtime  = 1800
maxretry = 3

# "backend" specifies the backend used to get files modification. Available
# options are "gamin", "polling" and "auto".
# yoh: For some reason Debian shipped python-gamin didn't work as expected
#      This issue left ToDo, so polling is default backend for now
backend = polling

#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = root@localhost

#
# ACTIONS
#

# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to define 
# action_* variables. Can be overriden globally or per 
# section within jail.local file
banaction = iptables-multiport

# email action. Since 0.8.1 upstream fail2ban uses sendmail
# MTA for the mailing. Change mta configuration parameter to mail
# if you want to revert to conventional 'mail'.
mta = sendmail

# Default protocol
protocol = tcp

#
# Action shortcuts. To be used to define action parameter

# The simplest action to take: ban only
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]

# ban & send an e-mail with whois report to the destemail.
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
              %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s]

# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
               %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]

# Choose default action.  To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g.  action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section 
action = %(action_)s

#
# JAILS
#

# Next jails corresponds to the standard configuration in Fail2ban 0.6 which
# was shipped in Debian. Enable any defined here jail by including
#
# [SECTION_NAME] 
# enabled = false

#
# in /etc/fail2ban/jail.local.
#
# Optionally you may override any other parameter (e.g. banaction,
# action, port, logpath, etc) in that section within jail.local

[ssh]

enabled = true
port    = ssh
filter    = sshd
logpath  = /var/log/auth.log
maxretry = 3

# Generic filter for pam. Has to be used with action which bans all ports
# such as iptables-allports, shorewall
[pam-generic]

enabled = true
# pam-generic filter can be customized to monitor specific subset of 'tty's
filter    = pam-generic
# port actually must be irrelevant but lets leave it all for some possible uses
port = all
banaction = iptables-allports
port     = anyport
logpath  = /var/log/auth.log
maxretry = 3

[xinetd-fail]

enabled   = false
filter    = xinetd-fail
port      = all
banaction = iptables-multiport-log
logpath   = /var/log/daemon.log
maxretry  = 2

[ssh-ddos]

enabled = true
port    = ssh
filter  = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 3

#
# HTTP servers
#

[apache]

enabled = true
port    = http,https
filter    = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

# default action is now multiport, so apache-multiport jail was left
# for compatibility with previous (<0.7.6-2) releases

[apache-multiport]

enabled   = false
port      = http,https
filter      = apache-auth
logpath   = /var/log/apache*/*error.log
maxretry  = 6

[apache-noscript]

enabled = false
port    = http,https
filter  = apache-noscript
logpath = /var/log/apache*/*error.log
maxretry = 6

[apache-overflows]

enabled = false
port    = http,https
filter  = apache-overflows
logpath = /var/log/apache*/*error.log
maxretry = 2

#
# FTP servers
#

[vsftpd]

enabled  = false
port     = ftp,ftp-data,ftps,ftps-data
filter   = vsftpd
logpath  = /var/log/vsftpd.log
# or overwrite it in jails.local to be
# logpath = /var/log/auth.log
# if you want to rely on PAM failed login attempts
# vsftpd's failregex should match both of those formats
maxretry = 6

[proftpd]

enabled  = false
port     = ftp,ftp-data,ftps,ftps-data
filter   = proftpd
logpath  = /var/log/proftpd/proftpd.log
maxretry = 6

[wuftpd]

enabled  = false
port     = ftp,ftp-data,ftps,ftps-data
filter   = wuftpd
logpath  = /var/log/auth.log
maxretry = 6

#
# Mail servers
#

[postfix]

enabled  = true
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log

[couriersmtp]

enabled  = false
port     = smtp,ssmtp
filter   = couriersmtp
logpath  = /var/log/mail.log

#
# Mail servers authenticators: might be used for smtp,ftp,imap servers, so
# all relevant ports get banned
#

[courierauth]

enabled  = false
port     = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter   = courierlogin
logpath  = /var/log/mail.log

[sasl]

enabled  = false
port     = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter   = sasl
# You might consider monitoring /var/log/warn.log instead
# if you are running postfix. See http://bugs.debian.org/507990
logpath  = /var/log/mail.log

# DNS Servers

# These jails block attacks against named (bind9). By default, logging is off
# with bind9 installation. You will need something like this:
#
# logging {
#     channel security_file {
#         file "/var/log/named/security.log" versions 3 size 30m;
#         severity dynamic;
#         print-time yes;
#     };
#     category security {
#         security_file;
#     };
# };
#
# in your named.conf to provide proper logging

# Word of Caution:
# Given filter can lead to DoS attack against your DNS server
# since there is no way to assure that UDP packets come from the
# real source IP
[named-refused-udp]

enabled  = false
port     = domain,953
protocol = udp
filter   = named-refused
logpath  = /var/log/named/security.log

[named-refused-tcp]

enabled  = false
port     = domain,953
protocol = tcp
filter   = named-refused
logpath  = /var/log/named/security.log</debian@onerussian.com> 

I have to admit, the security side of running this stuff is making me very nervous. I'm still a newb at all this stuff even after 6 months.

In reagards to security is it best to start over from scratch?

I don't see anything strange with fail2ban config. The strange thing is you got banned even that you have set up "ignoreip" with your IP.

Check /var/log/fail2ban.log to see if fail2ban really banned you.

Seems like you're trying toooooooo many things at once.

Do one thing (and one step) at a time, don't move on until that thing/step is working as expected.

First get IPTABLES working correctly (i.e. leave Fail2ban off).

Then get Fail2ban with ONE (and only one service, like SSH) working.

Then add additional Fail2ban services (one at a time).

The shotgun approach only provides too many variables to your problem solving task.

Finally got it! Did a lot of searching around (and ironically found a post by vonskippy on slicehost which helped) and I basically started from scratch.

This is what I have:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  180.76.0.0/16        anywhere            
ACCEPT     tcp  --  180.11.85.0/24       anywhere            tcp dpt:ssh state NEW,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www limit: avg 25/min burst 100 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:ssh state ESTABLISHED 

and it seems to be blocking fine. I stopped using webmin because it seems nothing was working with it - I entered rules and they just got ignored. Pointless!

So in regards to IP tables what other things would people recommend for standard practice for a web server?

I added to block SSH except for my ip and one for a DoS attack.

What ports should or shouldn't I keep open?

Thanks guys - really appreciate the help!