block forged packets with iptables
Hi, since a few day there is much in traffic (~100 kbit/sec) from a specified host to my server, I notice this first on my mrtg graph, then detailed with ntop. I want to block the IP with the following iptables commands: iptables -A OUTPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A OUTPUT -j DROP -s xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -s xxx.xxx.xxx.xxx A further look with iptables -L INPUT -vn (or OUTPUT) shows that there are no packets dropped. The webmaster of the IP tells me that there is no traffic from this host to my. So I think that the packets are forged. Any ideas/help what I can do against this attack? Thanks Oliver Krapp
-----------------------------------------------< etracker.de e.K. - Schopstraße 16 - 20255 Hamburg
http://www.etracker.de we're counting on you! EMail: oliver.krapp@etracker.de Tel: +49-40-43180803 Mobil: +49-179-4896999
2/22/02 10:58:34 AM, "Oliver Krapp - etracker.de"
Hi, since a few day there is much in traffic (~100 kbit/sec) from a specified host to my server, I notice this first on my mrtg graph, then detailed with ntop.
I want to block the IP with the following iptables commands:
iptables -A OUTPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A OUTPUT -j DROP -s xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -s xxx.xxx.xxx.xxx
If you use SNAT or DNAT and that IP is matched by an SNAT or DNAT rule then the INPUT and OUPUT chains are not used. Instead use the FORWARD chain.
A further look with iptables -L INPUT -vn (or OUTPUT) shows that there are no packets dropped.
The webmaster of the IP tells me that there is no traffic from this host to my. So I think that the packets are forged.
Any ideas/help what I can do against this attack?
Thanks Oliver Krapp
-----------------------------------------------< etracker.de e.K. - Schopstraße 16 - 20255 Hamburg
http://www.etracker.de we're counting on you!
EMail: oliver.krapp@etracker.de Tel: +49-40-43180803 Mobil: +49-179-4896999
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
since a few day there is much in traffic (~100 kbit/sec) from a specified host to my server, I notice this first on my mrtg graph, then detailed with ntop.
I want to block the IP with the following iptables commands:
iptables -A OUTPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A OUTPUT -j DROP -s xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -s xxx.xxx.xxx.xxx
If you use SNAT or DNAT and that IP is matched by an SNAT or DNAT rule
then the INPUT and OUPUT chains are not used. Instead use the FORWARD chain.
I don't use NAT, anyway if I also add rules for the FORWARD chain, it is the same effect. Thanks Oliver Krapp
-----------------------------------------------< etracker.de e.K. - Schopstraße 16 - 20255 Hamburg
http://www.etracker.de we're counting on you! EMail: oliver.krapp@etracker.de Tel: +49-40-43180803 Mobil: +49-179-4896999
Sounds like your default policy is ACCEPT... but some more information could be very helpfull.
Hi Ruediger, this is my rule set for normal server operation. I'm not a real iptables or network expert, but from my point of view it must be work. I can't see a reason why not. Thanks Oliver Krapp iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD iptables -A OUTPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A OUTPUT -j DROP -s xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -s xxx.xxx.xxx.xxx iptables -A FORWARD -j DROP -d xxx.xxx.xxx.xxx iptables -A FORWARD -j DROP -s xxx.xxx.xxx.xxx iptables -A INPUT -j LOG --log-level 6 --log-prefix "INVALID PACKET: " -p tcp -d alster -m state --state INVALID iptables -A INPUT -j DROP -p tcp -d alster -m state --state INVALID iptables -A INPUT -j ACCEPT -p tcp -m state --state ESTABLISHED,RELATED iptables -A OUTPUT -j ACCEPT -p tcp -m state --state ESTABLISHED,RELATED iptables -A INPUT -j LOG --log-level 6 --log-prefix "SSH Connection: " -p tcp -d alster --dport 22 -m state --state NEW iptables -A INPUT -j ACCEPT -p tcp -d alster --dport 22 -m state --state NEW iptables -A INPUT -j LOG --log-level 6 --log-prefix "Tunnel Connection: " -p tcp -s 212.121.145.243 -d alster --dport 1222 -m state --state NEW iptables -A INPUT -j ACCEPT -p tcp -s 212.121.145.243 -d alster --dport 1222 -m state --state NEW iptables -A OUTPUT -j ACCEPT -p udp -s 212.172.222.222 --dport 53 iptables -A INPUT -j ACCEPT -p udp -d 212.172.222.222 --sport 53 iptables -A INPUT -j ACCEPT -p tcp -d alster --dport 25 -m state --state NEW iptables -A OUTPUT -j ACCEPT -p tcp -s alster --dport 25 -m state --state NEW iptables -A INPUT -j ACCEPT -p tcp -d alster --dport 80 -m state --state NEW iptables -A OUTPUT -j ACCEPT -p tcp -s alster --dport 80 -m state --state NEW iptables -A OUTPUT -j ACCEPT -p tcp -s alster --dport 113 -m state --state NEW iptables -A INPUT -j LOG --log-level 6 --log-prefix "POP3 Connection: " -p tcp -s ! 62.156.160.60 -d alster --dport 110 -m state --state NEW iptables -A INPUT -j ACCEPT -p tcp -d alster --dport 110 -m state --state NEW iptables -A INPUT -j ACCEPT -p icmp --icmp-type echo-request -m limit --limit 5/s iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type echo-reply -m limit --limit 5/s iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type echo-request -m limit --limit 5/s iptables -A INPUT -j ACCEPT -p icmp --icmp-type echo-reply -m limit --limit 5/s iptables -A INPUT -j ACCEPT -p icmp --icmp-type destination-unreachable -m limit --limit 10/s iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type destination-unreachable -m limit --limit 10/s iptables -A INPUT -j ACCEPT -p icmp --icmp-type source-quench -m limit --limit 10/s iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type source-quench -m limit --limit 10/s iptables -A INPUT -j ACCEPT -p icmp --icmp-type time-exceeded -m limit --limit 10/s iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type time-exceeded -m limit --limit 10/s iptables -A INPUT -j DROP -p tcp --dport 135:139 iptables -A INPUT -j DROP -p udp --dport 135:139 iptables -A INPUT -j DROP -p udp --dport 67:68 iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -j ACCEPT -p udp --dport 33000:34000 iptables -A INPUT -j LOG --log-level 6 --log-prefix "FTP Connection: " -p tcp -d alster --dport 21 -m state --state NEW iptables -A INPUT -j ACCEPT -p tcp --dport 21 -d alster -m state --state NEW iptables -A OUTPUT -j LOG --log-level 6 --log-prefix "FTP Connection: " -p tcp -s alster --dport 21 -m state --state NEW iptables -A OUTPUT -j ACCEPT -p tcp --dport 21 -s alster -m state --state NEW iptables -A OUTPUT -j ACCEPT -p udp --dport 123 --sport 123 -s alster -d 131.188.3.221 iptables -A INPUT -j ACCEPT -p udp --dport 123 --sport 123 -s 131.188.3.221 -d alster iptables -A INPUT -j LOG --log-level 6 --log-prefix "PACKET dropped: " -p tcp -d alster iptables -A INPUT -j LOG --log-level 6 --log-prefix "PACKET dropped: " -p udp -d alster iptables -A INPUT -j LOG --log-level 6 --log-prefix "PACKET dropped: " -p icmp -d alster iptables -A OUTPUT -j LOG --log-level 6 --log-prefix "PACKET dropped: " -p tcp -s alster iptables -A OUTPUT -j LOG --log-level 6 --log-prefix "PACKET dropped: " -p udp -s alster iptables -A OUTPUT -j LOG --log-level 6 --log-prefix "PACKET dropped: " -p icmp -s alster
On Friday 22 February 2002 15:30, Oliver Krapp - etracker.de wrote:
since a few day there is much in traffic (~100 kbit/sec) from a specified host to my server, I notice this first on my mrtg graph, then detailed with ntop.
I want to block the IP with the following iptables commands:
iptables -A OUTPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A OUTPUT -j DROP -s xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -d xxx.xxx.xxx.xxx iptables -A INPUT -j DROP -s xxx.xxx.xxx.xxx
If you use SNAT or DNAT and that IP is matched by an SNAT or DNAT rule
then the INPUT and OUPUT chains are not used. Instead use the FORWARD chain.
I don't use NAT, anyway if I also add rules for the FORWARD chain, it is the same effect.
Maybe you already solved this, but here are some suggestions: How do the packets look like, did you try to capture some of them with tcpdump ? Maybe the packets get accepted before they reach your drop rules ? Andreas Baetz ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been scanned for the presence of computer viruses. **********************************************************************
participants (4)
-
Andreas Baetz -
ic_admin -
Oliver Krapp - etracker.de -
Raymond Leach