I was trying to block an ip of ( network stresser tool - a ddos websites selling ddos bots by seconds online ) the first one i was trying to block with iptables :
iptables -A INPUT -d 173.193.26.73 -j DROP
iptables -A INPUT -s 173.193.26.73 -j DROP
however i still see the ip and bandwidth still up on iftop. also still see the ip going on tcpdump.
is that normal? what's the problem in here?
Yes, it's normal. iptables doesn't stop inbound traffic turning up on your physical interface, thus notching up your iftop counts, and it doesn't stop the kernel seeing that it's there, hence the tcpdump output. It does, however, stop the kernel passing the traffic on to anything that might be listening for it.
If you see any output traffic in response to those input packets, something's wrong. But otherwise, no, that's normal.
The packets are still physically being transmitted to your system, iptables is just filtering them out before they get where the sender wants them to.
There are a few things you can do to remedy the underlying issue:
Put a router between your machine and the outside world which does the filtering for you and transparently forwards all other packets.
Routers are optimized for that kind of operation, so as a first line of defense it certainly isn't a bad idea. Although you will want to keep the firmware up to date, if it doesn't do that itself.
Of course, you'll also want to change the DNS record to a failover server (if you're worried about downtime, which you likely are) while you're hooking up the router and making sure it's doing what you want it to do.
Use -I rather than -A; that way, the block rules get processed first, and your CPU doesn't burn as many cycles checking packets you immediately know are awful against all the other rules.
If the site is trying to DoS you, I'm guessing they constitute a significant source of traffic and, if so, the rules which apply to them should be processed earlier. A good rule of thumb is to order the rules based on how likely the event is. The more likely the network event, the earlier it should be dealt with.
Of course, this must also be weighed against the complexity of processing the network event (i.e. If event A is twice as likely as event B but requires 300 times the processing, the rules for event B should probably go first), but in the case of a couple drop rules for a site that's attempting a DoS it's probably a safe bet.
One way to prevent the iptables ruleset from becoming too cumbersome is by creating new chains to handle each type of traffic (e.g. a chain to handle private network connection attempts, a chain to handle ssh throttling, etc.) so that the INPUT chain (which can be thought of as like a main method if you have a programming background) just calls other chains to do the meat of the processing. So if you want to experiment with new rulesets, or changing the order of processing for different events, you only have to change the order of unconditional jumps in INPUT.
Check their ISP's Terms of Service and, if they're in violation, inform their ISP (being as specific as you can about how they are in violation; you'll want to provide references, and you'll want to come across as polite and professional. If the person who gets your e-mail likes you, and you make their job easier to do, you're way more likely to get a result).
