LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
LinkBack Search this Thread
Old 06-21-2013, 10:47 AM   #1
rjo98
Senior Member
 
Registered: Jun 2009
Location: US
Distribution: RHEL, CentOS
Posts: 1,320

Rep: Reputation: 36
Auto block IP via iptables after certain number of failed attempts


Hey guys. I'm not an iptables master, let me get that out of the way first.
We have an FTP server that I'm told if someone tries to log in to it X amount of times unsuccessfully, it blocks them in iptables, but if you restart iptables it clears out those blocks so they must just be kept in memory rather than being written to a file i'm assuming.
I'm looking at the server though, but I don't see where/how that's setup. Any ideas where I should look for something like that?
 
Old 06-21-2013, 01:56 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,534
Blog Entries: 51

Rep: Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604
Quote:
Originally Posted by rjo98 View Post
(..) I don't see where/how that's setup. Any ideas where I should look for something like that?
Either a daemon or other continuously running process (pgrep, ps) that reads the FTP daemons log file (lsof, fuser), or whatever file FTPd / syslog logs auth errors to, or a cron job?
 
Old 06-21-2013, 02:06 PM   #3
rjo98
Senior Member
 
Registered: Jun 2009
Location: US
Distribution: RHEL, CentOS
Posts: 1,320

Original Poster
Rep: Reputation: 36
I looked under root's crontab, didn't see anything. If I do a ps aux and grep for lsof or fuser, I don't see any running.
 
Old 06-21-2013, 06:11 PM   #4
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 767

Rep: Reputation: 154Reputation: 154
There could be several programs that work as you describe. fail2ban is one that I use. If it is installed, the config files are probably somewhere in /etc. Mine are in /etc/fail2ban. Look for a fail2ban log file. Mine is /var/log/fail2ban. Other configurations are possible, of course. Issue "which fail2ban-client" and it'll tell you if it's in your path.

You can list your iptables with "iptables -nL". If fail2ban is installed, you will see one or more custom chains that it adds, and the banned IPs will show up under one of them.

The banned IPs disappear when you boot your system because your iptables firewall gets rebuilt. I made some changes to fail2ban to preserve all IPs banned for ssh violations. It runs as part of fail2ban after it starts up following a boot, so I never lose my banned IPs.
 
1 members found this post helpful.
Old 06-21-2013, 08:01 PM   #5
rjo98
Senior Member
 
Registered: Jun 2009
Location: US
Distribution: RHEL, CentOS
Posts: 1,320

Original Poster
Rep: Reputation: 36
thanks Z. I just ran that iptables command you told me, and under Chain INPUT, I see these lines, maybe these have something to do with it?

Quote:
tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: SSH side: source
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: UPDATE seconds: 60 hit_count: 5 TTL-Match name: SSH side: source
tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW recent: SET name: FTP side: source
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW recent: UPDATE seconds: 60 hit_count: 10 TTL-Match name: FTP side: source
 
Old 06-21-2013, 11:30 PM   #6
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 767

Rep: Reputation: 154Reputation: 154
It's not fail2ban, but it looks similar. Here's mine, showing lots of banned IPs for ssh.

Code:
# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-recidive  tcp  --  0.0.0.0/0            0.0.0.0/0           
fail2ban-BadBots  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-VSFTPD  tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:21
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpts:30000:30099

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-BadBots (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-SSH (1 references)
target     prot opt source               destination         
REJECT     all  --  211.25.211.230       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  198.15.66.150        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  212.227.54.102       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  190.66.23.12         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  218.69.248.24        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  199.19.108.50        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  183.221.125.10       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  61.60.148.12         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  117.240.185.36       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  117.240.185.36       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  61.133.244.245       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  218.64.114.103       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  221.176.53.74        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  210.51.2.200         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  61.146.164.35        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  222.134.62.171       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  178.20.228.220       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  184.107.168.202      0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  220.231.194.109      0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  119.148.10.87        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  59.53.94.9           0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  119.36.186.44        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  119.254.231.76       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  113.106.1.93         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  201.20.233.228       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  87.106.255.146       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  78.36.239.69         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  113.195.5.231        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  183.232.32.24        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  153.122.0.232        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  168.126.49.200       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  213.170.78.14        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  123.233.247.119      0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  112.65.239.124       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  85.214.66.105        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  124.160.194.27       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  61.155.150.217       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  189.26.255.11        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  75.127.85.60         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  61.34.216.213        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  125.46.13.163        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  177.189.241.74       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  218.200.177.234      0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  184.22.232.250       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  58.215.82.148        0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  50.115.36.27         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  46.21.161.37         0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-VSFTPD (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-recidive (1 references)
target     prot opt source               destination         
REJECT     all  --  117.240.185.36       0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  61.133.244.245       0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
 
1 members found this post helpful.
Old 06-24-2013, 08:38 AM   #7
rjo98
Senior Member
 
Registered: Jun 2009
Location: US
Distribution: RHEL, CentOS
Posts: 1,320

Original Poster
Rep: Reputation: 36
OK, thanks. I think those lines in post #5 are doing the blocking for me. Now if I only knew what was being blocked by those lines haha
 
Old 06-24-2013, 12:14 PM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,534
Blog Entries: 51

Rep: Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604
Quote:
Originally Posted by rjo98 View Post
Now if I only knew what was being blocked by those lines haha
Simply prefix them with a similar line but with a "-j LOG" target instead?

Last edited by unSpawn; 06-24-2013 at 12:16 PM.
 
1 members found this post helpful.
Old 06-24-2013, 01:35 PM   #9
rjo98
Senior Member
 
Registered: Jun 2009
Location: US
Distribution: RHEL, CentOS
Posts: 1,320

Original Poster
Rep: Reputation: 36
So I would just added "-j LOG" to the beginning of those lines I pasted a few posts ago? Does that log them to a file, or will that then show them when I do a iptables -nL command?
 
Old 06-24-2013, 01:48 PM   #10
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,534
Blog Entries: 51

Rep: Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604
Quote:
Originally Posted by rjo98 View Post
So I would just added "-j LOG" to the beginning of those lines I pasted a few posts ago?
No. Duplicate the "-j DROP" line to the line above it, then change "-j DROP" to read "-j LOG".


Quote:
Originally Posted by rjo98 View Post
Does that log them to a file, or will that then show them when I do a iptables -nL command?
'man iptables' says to syslog.
 
1 members found this post helpful.
Old 06-24-2013, 01:51 PM   #11
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 767

Rep: Reputation: 154Reputation: 154
From the man page for iptables:

Code:
   LOG
       Turn  on  kernel logging of matching packets.  When this option is set for a rule, the Linux kernel will print some information
       on all matching packets (like most IP header fields) via the kernel log (where it can be read with dmesg or syslogd(8)).   This
       is  a  "non-terminating target", i.e. rule traversal continues at the next rule.  So if you want to LOG the packets you refuse,
       use two separate rules with the same matching criteria, first using target LOG then DROP (or REJECT).

       --log-level level
              Level of logging (numeric or see syslog.conf(5)).

       --log-prefix prefix
              Prefix log messages with the specified prefix; up to 29 letters long, and useful  for  distinguishing  messages  in  the
              logs.

       --log-tcp-sequence
              Log TCP sequence numbers. This is a security risk if the log is readable by users.

       --log-tcp-options
              Log options from the TCP packet header.

       --log-ip-options
              Log options from the IP packet header.

       --log-uid
              Log the userid of the process which generated the packet.
So you would duplicate the rule and specify -j LOG on the first one instead of the DROP target. The LOG target will cause the packet to be logged, the next rule (your current one) will DROP if the conditions are met.
 
1 members found this post helpful.
Old 06-24-2013, 02:17 PM   #12
rjo98
Senior Member
 
Registered: Jun 2009
Location: US
Distribution: RHEL, CentOS
Posts: 1,320

Original Poster
Rep: Reputation: 36
oh ok, I get it now, so the first line purely logs it, then the next one actually drops them. So then if something gets blocked, it only shows up in the log file, or can I run iptables with some switch to see what's blocked, since I think these only block until iptables restarts?
 
Old 06-24-2013, 04:06 PM   #13
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,534
Blog Entries: 51

Rep: Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604Reputation: 2604
Quote:
Originally Posted by rjo98 View Post
oh ok, I get it now, so the first line purely logs it, then the next one actually drops them.
That's the idea, yeah.


Quote:
Originally Posted by rjo98 View Post
can I run iptables with some switch to see what's blocked
Code:
cat /proc/net/[ipt|xt]_recent/{FTP,SSH}
 
1 members found this post helpful.
Old 06-24-2013, 04:11 PM   #14
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 767

Rep: Reputation: 154Reputation: 154
I'm not sure how long they block. I don't clearly understand how your rules are operating. Sorry.
 
Old 06-25-2013, 09:08 AM   #15
rjo98
Senior Member
 
Registered: Jun 2009
Location: US
Distribution: RHEL, CentOS
Posts: 1,320

Original Poster
Rep: Reputation: 36
Thanks for all the help you guys.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SMTP Relay Attempts - how do I block then! Smokin... Linux - Security 5 05-15-2012 12:30 PM
Block IP after failed login attempt using iptables? FireRaven Linux - Security 6 08-11-2009 12:33 PM
SSH tricks -- any way to block failed attempts by IP address tensigh Linux - Security 10 06-06-2008 03:46 PM
Configure Failed logins to lock accounts after 5 failed attempts mccartjd Linux - Newbie 5 05-05-2008 08:02 AM
restrict number of logon attempts depaul Linux - Security 5 07-28-2003 12:17 PM


All times are GMT -5. The time now is 10:26 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration