Major DOS attacks

cruiseoveride · #1 27th April 2006, 03:12 AM

im getting a dos attack from one ip only, which i s relatively a good thing but, i can t stop the guy, i have every possible drop rule in iptables, but it doesnt stop anything, do i have to restart iptables or something? or the network interface?

brandor · #2 27th April 2006, 04:21 PM

How are you blocking?

liro · #3 27th April 2006, 04:25 PM

Quote:

Originally Posted by cruiseoveride

im getting a dos attack from one ip only, which i s relatively a good thing but, i can t stop the guy, i have every possible drop rule in iptables, but it doesnt stop anything, do i have to restart iptables or something? or the network interface?

no restart is not needed...but be sure that your rule is on first place! iptables is rule based, first rule which is true is the one which is used...

so, not just add the rule insert it on first place....

AlexFR · #4 27th April 2006, 06:51 PM

go into /etc/hosts.deny and enter this line

ALL: ipaddress

cruiseoveride · #5 27th April 2006, 10:14 PM

let me try, im barely able to get to this webpage itself, .
im getting icmp hits like crazy from a particular ip only, i have dropped all packets from this source

Code:

iptable -I INPUt -s xxx.xxx.xxx.xxx -j DROP

i also tried -m mac --mac-source
but that only makes a dent in the recieve graph for a second then its back to 100% again.
i will try the tcp_wrappers,
but why isnt iptables able to stop this guy?

Zigzagcom · #6 28th April 2006, 04:07 AM

Can you post the output of "iptables -L --line-numbers". This is the output of whats running in memory. If you changed something in the running iptables config, you have to save it to /etc/sysconfig/iptables with either the "service iptables save" or "iptables-save > /etc/sysconfig/iptables" command, or else it will not survive a reboot (as it's only in memory).

With the default Fedora Core firewall you can place the rule before the rule that passes ICMP traffic within the RH-Firewall-1-INPUT chain, or as the first rule of the INPUT chain.
Problem is, that the rule may conserve your systems' resources, but cannot prevent your bandwidth (the pipe to your IP) from being eaten.

Code:

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
:RH-Firewall-1-INPUT - [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/255.255.255.0 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 22 --state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 10000 --state NEW -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Generated by webmin
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed
# Generated by webmin
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

I've re-run a rule I temporarily created just after the built-in INPUT chain, before the RH-Firewall-1-INPUT chain and it works as well.

Code:

[root@server ~]# iptables -I INPUT -s 192.168.1.101 -j DROP
[root@server ~]# iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    DROP       all  --  192.168.1.101        anywhere
2    RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere
2    ACCEPT     icmp --  anywhere             anywhere            icmp echo-request
3    ACCEPT     ipv6-crypt--  anywhere             anywhere
4    ACCEPT     ipv6-auth--  anywhere             anywhere
5    ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp
6    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp
7    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
8    ACCEPT     all  --  192.168.1.0/24       anywhere
9    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
10   ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ndmp
11   REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

cruiseoveride · #7 28th April 2006, 05:55 AM

i cleared all the previous rules, they were getting hectic, i have the following only

Code:

 /sbin/iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    DROP       all  --  134.117.161.72       anywhere
2    DROP       all  --  134.117.158.187      anywhere
3    DROP       all  --  134.117.158.170      anywhere
4    DROP       all  --  134.117.158.169      anywhere

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

so ur saying that the data is still getting into the pipe and dropping the icmp requests from the dos will not prevent bandwith usage?

when i have no rules, both the send and recieve goes crazy (50% each of my total bandwidth),, when i put the drop rule in place the send drops to 0% and the recieve hits 100% ,
can i redirect them or send them back to the source?
i think im gonn ado a little dos attacking once all this is done,

Zigzagcom · #8 28th April 2006, 06:21 AM

Consider that your ISP accepts data/traffic destined to your WAN ip and pipes it down to your gateway device. Since the ISP allocates a certain download rate to you, the ICMP traffic will chew up a portion of that.

The way your firewall is configured now is rather useless, since the POLICY for the INPUT chain is to accept all traffic. This means, that you would have to configure your rules to drop or filter just about everything on the planet. A better way, would be to have a policy that DROPs all traffic to your system and then selectively open up the ports and protocols for those services you really intend to accept traffic for. This is much easier from an administrative point of view.

The best thing you can do is to rename /etc/sysconfig/iptables to iptables.old and revert back to your default firewall configuration by invoking the graphical "system-config-securitylevel" tool from System-->Administration-->Security Level and Firewall or "system-config-securitylevel-tui" from the commandline.
The user defined RH-Firewall-1-INPUT chain has as a last rule a "reject" target, similar to a "drop" target.
Below are a couple of links about iptables that might shed a bit of light on the matter.

http://forums.fedoraforum.org/forum/...d.php?t=106379
http://forums.fedoraforum.org/forum/...d.php?t=104848

Zigzagcom · #9 28th April 2006, 06:33 AM

Also, what do you have to gain from getting sucked into a tit for tat? You inadvertantly become just another user, that helps to permeate the internet with useless traffic. Neither have you a way of knowing for sure, that you are getting back at the "real" culprit. The traffic could be coming from a zombied machine, worse from an unaware company or university server. The tables could be turned on you for trying to DOS those machines.
Best would be to delete the rule that allows ICMP responses (in the default firewall configuration), i.e., you become un-pingable.
The rule that deals with ICMP packets could just as easily be modified to accept traffic from your LAN only. Now you can still ping your machines from within the LAN.

The multitude of set-ups for internet connectivity can complicate things. If you have a cable modem that passes the public IP to your machines' NIC, then you are much more vulnerable.
Placing a router/switch combo between a cable modem and a computer has the benefit of NAT, i.e., you are hiding behind a private network.
If you have DSL instead of cable, your ISP would most likely provide you with a NAT capable device. In many cases, you could then disable ICMP on that device. Also, with portforwarding, you can then control which machine receives traffic for services you offer.
I suppose that for some games one would need to be pingable, or for remote administration.

cruiseoveride · #10 28th April 2006, 07:21 AM

i agree with ur suggestions, and my rules are not quite at the mark . however, i have no problem from anyother source, except the ones i have defined, but why doesnt iptables drop the traffic from those sources? or is it? but im getting almost 1.2mbs of recieve

Zigzagcom · #11 28th April 2006, 07:43 AM

I assume that you have a web-site that is under a DOS attack...and your last "iptables -L" listed several ip's you have a drop rule for, so not only one IP is attacking, but several...if that is the case, you are experiencing a DDOS, or distributed denial of service attack, which is far more difficult to deal with.

Anyway, the above rules should be dropping traffic from those sources.
I don't know what tool you are using to determine your traffic rates. I would use something like ethereal to capture the traffic and save a portion of it to a file for analysis, but the tool would have to be on the server or capable of sniffing the traffic from a monitor port of a switch on the network.

Being able to look at the headers of these packets would maybe yield better info.

Zigzagcom · #12 28th April 2006, 08:00 AM

You could file a complaint to the administrator, and rather than blocking a single IP, you could block the entire network, 134.117.0.0 to 134.117.255.255 with

Code:

iptables -I INPUT -s 134.117. -j DROP
service iptables save

this would prevent any machine from that block getting to you.

cruiseoveride · #13 28th April 2006, 04:38 PM

ok, thanks, let me try get something straight,
when i get attacked, without a firewall, my server recieved millions of icmp requests, and so it responds to them all, and hence the traffic is used iup, both the send and recieve right?
Now when i drop the traffic from the trouble sources, the icmp headers get into the netfilter (using up my download bandwidth) but my machine will not respond, so hence my upload bandwidth becomes normal again? is that wats going on?

Can i not put a general rule from any source saying drop icmp, syn, and echo requests if there are occuring too often like (100 a second) or something like that?

And by the way, the tcp wrapper (hosts.deny) once i add an entry do i have to reinit the kernel or a service for the changes to make effect?

ccrvic · #14 28th April 2006, 04:50 PM

Quote:

Originally Posted by cruiseoveride

Can i not put a general rule from any source saying drop icmp, syn, and echo requests if there are occuring too often like (100 a second) or something like that?

You can, but if these IP addresses are still hammering out ICMP requests, you're still going to get them.

If you have nothing to do with Carleton University, I'd recommend a short phone call to their abuse number.

If you are something to do with Carleton, you might want to make sure it's not something daft you've done first :-)

Vic.