Ah, ok, thanks ... and now I have an idea .... Could it be ... that if the attacker does not start a new connection, he is not dropped, until he starts a new connection because the connection already exists?
So I have to kill all existing connections? Perhaps that was my fault ... Regards Alexander Maringer PS: Yes, I did a shorewall reset before the dump. Am 18.07.2010 23:37, schrieb Tom Eastep: > On 7/18/10 1:29 PM, Alexander Maringer wrote: >> Hello, >> >> I wrote some message about 1 month ago with the subject "Blacklist" (at >> beginning of june). At this time I was not able to reproduce the >> problem, because I didn't have this kind of attack until now. >> >> As I wrote before, I have some IPs in the blacklist table and I have >> added the blacklist option to the interface. But never the less the >> blacklisted IP has the ability to connect to my IMAP server: >> Jul 18 21:51:28 **** dovecot-auth: pam_unix(dovecot:auth): >> authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=bebe >> rhost=213.123.136.225 >> Jul 18 21:51:28 **** dovecot-auth: pam_unix(dovecot:auth): >> authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=becky >> rhost=213.123.136.225 >> >> The dump is attached. >> >> Thanks a lot for any hints > > Unfortunately, the firewall configuration has been restarted since the > dovecot messages were logged > > Shorewall 4.4.10.2 Dump at linsenwelt.com - So 18. Jul 22:40:07 CEST 2010 > > Counters reset So 18. Jul 22:40:00 CEST 2010 > -------- > > But here is what is there now: > > Chain INPUT (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > 22 3388 dynamic all -- * * 0.0.0.0/0 > 0.0.0.0/0 ctstate INVALID,NEW > 165 16817 net2fw all -- eth1 * 0.0.0.0/0 > 0.0.0.0/0 > > So all traffic entering through eth1 is sent through the net2fw chain. > > Chain net2fw (1 references) > pkts bytes target prot opt in out source > destination > 22 3388 blacklst all -- * * 0.0.0.0/0 > 0.0.0.0/0 ctstate INVALID,NEW > > All new connection requests (and any packets in invalid state) are sent > through the blacklst chain. > > Chain blacklst (2 references) > pkts bytes target prot opt in out source > destination > 0 0 DROP all -- * * 87.106.24.224 > 0.0.0.0/0 > 0 0 DROP all -- * * 193.85.18.72 > 0.0.0.0/0 > 13 624 DROP all -- * * 213.123.136.225 > 0.0.0.0/0 > > Note that in the approximately 7 seconds between the time that you > reloaded the firewall and when Shorewall captured the dump, 13 > connection requests from 213.123.136.225 were dropped. And there are > currently no existing connections from that IP address (search for other > instances of that address in the dump). > > If you see this happen again, please verify that the above chains/rules > are all in place. With them in place, I can see no way that any > connection from 213.123.136.225 could be successful. > > -Tom > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > > > _______________________________________________ > Shorewall-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
