0

I have blocked an attacker IP that was sending me lots of UDP packets.

iptables -I INPUT 1 -s IP_OF_ATTACKER -j DROP

This rule was working all fine.

iptables -nvL --line-numbers

22G traffic was blocked for 2-3 days:

num   pkts bytes target     prot opt in     out     source               destination
1    3203K   22G DROP       all  --  *      *       ATTACKER_IP          0.0.0.0/0

However, from last 2-3 days, this rule isn't working anymore. Attacker is sending UDP packets and iptables are not blocking them.

num   pkts bytes target     prot opt in     out     source               destination
1     707K 3553M DROP       all  --  *      *       ATTACKER_IP         0.0.0.0/0

What could be the reason?

PS: Please do not suggest about contacting hosting provider if they were any help I wouldn't be here :)

Edit

I used wireshark/tcpdump to analyze/capture packets. It shows all packets are UDP. I use iptables command (as mentioned above) to see how much data iptables rule has blocked. Above is the output of iptables blocked data. When iptable was blocking all the data, our server was working all fine.

**IP Table rules**
# Generated by iptables-save v1.4.21 on Mon Jun 15 23:26:40 2015
*raw
:PREROUTING ACCEPT [8393:667810]
:OUTPUT ACCEPT [7043:795032]
COMMIT
# Completed on Mon Jun 15 23:26:40 2015
# Generated by iptables-save v1.4.21 on Mon Jun 15 23:26:40 2015
*nat
:PREROUTING ACCEPT [2517:112725]
:INPUT ACCEPT [2517:112725]
:OUTPUT ACCEPT [1018:179752]
:POSTROUTING ACCEPT [1018:179752]
COMMIT
# Completed on Mon Jun 15 23:26:40 2015
# Generated by iptables-save v1.4.21 on Mon Jun 15 23:26:40 2015
*mangle
:PREROUTING ACCEPT [8393:667810]
:INPUT ACCEPT [8393:667810]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7043:795032]
:POSTROUTING ACCEPT [7043:795032]
COMMIT
# Completed on Mon Jun 15 23:26:40 2015
# Generated by iptables-save v1.4.21 on Mon Jun 15 23:26:40 2015
*filter
:INPUT ACCEPT [23:1500]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [18:2068]
:fail2ban-ssh - [0:0]
-A INPUT -s xx.xxx.xx.xx/32 -j DROP
COMMIT
# Completed on Mon Jun 15 23:26:40 2015
Improve this question
8
  • First you need to post all your iptables rules as order of the rules matters. Second, your question is unclear, what makes you think you are recieving UDP packets and what makes you think they were accepted ? Last the syntax is -j DROP, not -s DROP. And you should use REJECT - chiark.greenend.org.uk/~peterb/network/drop-vs-reject
    – Panther
    Jun 16, 2015 at 14:42
  • @bodhi.zazen, I have updated my question with answers to your questions. I think, syntax is correct. It is indeed -j drop. I did not use "reject" as it will send back the signal to the attacker.
    – Tweety
    Jun 16, 2015 at 15:19
  • Did you read the link I gave you ? They can tell you are present at your IP address by your response to their packets (DROP), they already know your IP (hello you are blocking them) and hackers ignore timeouts.
    – Panther
    Jun 16, 2015 at 15:59
  • Your rules look fine, you are not accepting traffic from "-s xx.xxx.xx.xx/32"
    – Panther
    Jun 16, 2015 at 16:00
  • How come the same rule was blocking (as you can see in my question) GBs of traffic but after some days the same rule didn't block any traffic? My server was all fine when iptable was showing that it's blocking traffic. However, my server is slow while iptable shows little traffic is blocked. I checked iftop and it shows lots of traffic coming from the attacker's ip.
    – Tweety
    Jun 16, 2015 at 16:05

1 Answer 1

Reset to default
0

I don't fully understand your iptables listing, or how it came to be so. However, there does appear to be nat and mangle tables, and therefore it is entirely conceivable that your problem packets do not traverse the normal INPUT chain, but rather are directed through the iptables via another path at the prerouting stage (which would only be traversed once per connection, by the way). You could try adding:

sudo iptables -t raw -A PREROUTING -s IP_OF_ATTACKER -j DROP

I did so on my test computer, and it seems to be working fine:

$ sudo iptables-save -c
# Generated by iptables-save v1.4.21 on Tue Jun 16 11:12:51 2015
*raw
:PREROUTING ACCEPT [40:2664]
:OUTPUT ACCEPT [33:4520]
[31:2696] -A PREROUTING -s 192.168.111.103/32 -j DROP
COMMIT
# Completed on Tue Jun 16 11:12:51 2015
# Generated by iptables-save v1.4.21 on Tue Jun 16 11:12:51 2015
*nat
:PREROUTING ACCEPT [15:1344]
...

Note: I posted this same answer on your Ubuntu forums posting.

Improve this answer
3
  • How come it blocked at first and not now? Your answer sounds bit technical to me. Would you be kind enough to provide couple of reference to your answer so I can read more about it?
    – Tweety
    Jun 16, 2015 at 20:54
  • I do not know why it blocked at first and not now, and, as bodhi mentioned, it is not clear to me that it isn't. I am just saying that there is a possibility of another path through the iptables, however such a path would typically be initiated from your end. There are many many good (also many bad) references for iptables. Many of us like this one (and oh, look it is the web site of the above commenter).
    – Doug Smythies
    Jun 16, 2015 at 21:32
  • Sorry for taking bit long to get back to you. That guy was maybe on holidays He is back again and no your rules didn't help at all. Even now my rules don't stop any packet from that specific IP. BTW, he is using a perl script linuxscrew.com/files/udp_flood.txt.
    – Tweety
    Jun 21, 2015 at 2:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .