I added these rules to IPTABLES to slow brute force attacks.
iptables -A INPUT -p tcp --dport 22 -s my_subnet/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j DROP
I would like log entries when connections are dropped to see that its working. How do I do that?
I am guessing I would add this before the drop.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j LOG --log-prefix 'SSH attack: '
Is that right? Thanks.
Matt
On Tue, August 19, 2008 09:33, Matt wrote:
I would like log entries when connections are dropped to see that its working. How do I do that?
I am guessing I would add this before the drop.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j LOG --log-prefix 'SSH attack: '
Is that right? Thanks.
That's the right general approach; duplicate the drop rule but with a LOG target and appropriate logging parameters.
Hi all,
I am new for this group. I am using fetchmail as a pop connector. It downloads a lot of pop3 inbox from some isps and it works properly. Today i installed postfix and mailscanner for filtering virus and spam mails on the same server but there is something wrong with mail headers. Because mail header says that mail coming from localhost 127.0.0.1 which is already whitelisted. So every incoming mail is tagged as clean. How can i fix this problem ? Can i send incoming mails to smtp with the original header?
.fetchmailrc ------------- set daemon 20 set syslog set postmaster root poll pop.gmail.com with proto POP3 and options no dns user 'someone@gmail.com' with pass "123456" is 'realuser@ccc.net' here options ssl fetchall no keep no rewrite sslcertck sslcertpath '/home/.certs' smtphost localhost
Thanks
ismail
On Tue, Aug 19, 2008 at 1:16 PM, Ismail OZATAY ismail@ismailozatay.net wrote:
Hi all,
I am new for this group. I am using fetchmail as a pop connector. It downloads a lot of pop3 inbox from some isps and it works properly. Today i installed postfix and mailscanner for filtering virus and spam mails on the same server but there is something wrong with mail headers. Because mail header says that mail coming from localhost 127.0.0.1 which is already whitelisted. So every incoming mail is tagged as clean. How can i fix this problem ? Can i send incoming mails to smtp with the original header?
Fetchmail fetchs mails and resends them through you local MTA (so it always uses 127.0.0.1). To filter by the sender IP, your MTA has to be the [unique] MX of your domain...
Hi,
On Tue, Aug 19, 2008 at 14:44, Marcelo Roccasalva marcelo-centos@irrigacion.gov.ar wrote:
Fetchmail fetchs mails and resends them through you local MTA (so it always uses 127.0.0.1). To filter by the sender IP, your MTA has to be the [unique] MX of your domain...
Postfix actually has a feature (XCLIENT) to receive this information to the software connecting to it: http://www.postfix.org/XCLIENT_README.html
However, AFAIK, fetchmail does not have support for it, and I'm not aware of any patch that uses it.
Filipe
--On Tuesday, August 19, 2008 10:15 AM -0500 David Dyer-Bennet dd-b@dd-b.net wrote:
That's the right general approach; duplicate the drop rule but with a LOG target and appropriate logging parameters.
Another approach is to create a subchain that just logs and drops (no match rules), and in your main chain you match on the desired packet and jump to the subchain. That eliminates the need to maintain the same match in two places, and reduces the number of rules a non-dropped packet has to pass through.
On Tue, August 19, 2008 19:04, Kenneth Porter wrote:
--On Tuesday, August 19, 2008 10:15 AM -0500 David Dyer-Bennet dd-b@dd-b.net wrote:
That's the right general approach; duplicate the drop rule but with a LOG target and appropriate logging parameters.
Another approach is to create a subchain that just logs and drops (no match rules), and in your main chain you match on the desired packet and jump to the subchain. That eliminates the need to maintain the same match in two places, and reduces the number of rules a non-dropped packet has to pass through.
Or any arbitrary number of pairs of places, in fact; you can jump to that log-and-drop rule from a dozen different places if you have a dozen things you want logged-and-dropped. (It does mean you're not putting cause info into each log entry to use it that way, though; still, you can usually figure out from the packet why you dropped it.)
I've been known to put a log entry at the end of my chain, with suitable rate-limiting parameters, and actually log every spurious packet hitting my system. The rate-limiting parameters are important :-).
Matt (lm7812@gmail.com) kirjoitteli (19.8.2008 17:33):
I added these rules to IPTABLES to slow brute force attacks.
iptables -A INPUT -p tcp --dport 22 -s my_subnet/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j DROP
Hi,
I use fail2ban to prevent brute force attacks. Much simpler. :-)
Fail2ban keeps up blacklists of ip:s that have failed authentication too many times. What is "too many", and the duration of blacklisting can be configured easily in /etc/fail2ban.conf.
I think I installed fail2ban simply using yum. Maybe it was in dag or rpmforce, don't remember exactly now.
- Jussi
-- Jussi Hirvi * Green Spot Topeliuksenkatu 15 C * 00250 Helsinki * Finland Tel. & fax +358 9 493 981 * Mobile +358 40 771 2098 (only sms) jussi.hirvi@greenspot.fi * http://www.greenspot.fi
--On Wednesday, August 20, 2008 1:49 PM +0300 Jussi Hirvi greenspot@greenspot.fi wrote:
Fail2ban keeps up blacklists of ip:s that have failed authentication too many times. What is "too many", and the duration of blacklisting can be configured easily in /etc/fail2ban.conf.
The installation is easy, but the configuration looks daunting. There's a bunch of "jails" and it looks like I need to study fail2ban's model to understand what those do.
Fail2ban keeps up blacklists of ip:s that have failed authentication too many times. What is "too many", and the duration of blacklisting can be configured easily in /etc/fail2ban.conf.
Kenneth Porter shiva@sewingwitch.com escribio (20.8.2008 22:55)
The installation is easy, but the configuration looks daunting. There's a bunch of "jails" and it looks like I need to study fail2ban's model to understand what those do.
What do you mean by "jail"? I didn't find that word in my fail2ban.conf (dated "2005.06.21"). I needed to change the default conf only very slightly (mainly time constants, on/off switches for tasks, and or log file paths).
- Jussi
-- Jussi Hirvi * Green Spot Topeliuksenkatu 15 C * 00250 Helsinki * Finland Tel. & fax +358 9 493 981 * SMS +358 40 771 2098 jussi.hirvi@greenspot.fi * http://www.greenspot.fi
On Thursday, August 21, 2008 9:28 AM +0300 Jussi Hirvi greenspot@greenspot.fi wrote:
Kenneth Porter shiva@sewingwitch.com escribio (20.8.2008 22:55)
The installation is easy, but the configuration looks daunting. There's a bunch of "jails" and it looks like I need to study fail2ban's model to understand what those do.
What do you mean by "jail"? I didn't find that word in my fail2ban.conf (dated "2005.06.21"). I needed to change the default conf only very slightly (mainly time constants, on/off switches for tasks, and or log file paths).
I installed fail2ban-0.8.2-2.el5.rf. It includes a separate jail.conf file.
I added these rules to IPTABLES to slow brute force attacks.
iptables -A INPUT -p tcp --dport 22 -s my_subnet/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j DROP
I would like log entries when connections are dropped to see that its working. How do I do that?
I am guessing I would add this before the drop.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j LOG --log-prefix 'SSH attack: '
That seems to have worked. Another quick question. Would it be better to TARPIT rather then DROP the packets?
Matt
--On Wednesday, August 20, 2008 10:01 AM -0500 Matt lm7812@gmail.com wrote:
Would it be better to TARPIT rather then DROP the packets?
Is TARPIT compiled into the default kernel? Back when I thought it (and several other netfilter modules) might be interesting to play with, it was still "experimental" and not compiled in.
-
David Dyer-Bennet -
Filipe Brandenburger -
Ismail OZATAY -
Jussi Hirvi -
Kenneth Porter -
Marcelo Roccasalva -
Matt