Recompile iptables to block a MAC address[SOLVED]

[danny_b85]

Hi all,

I've been having some problems these last couple of days with some "benevolent" people who have been attacking a couple of servers I am working on. The attacks are similar to what I've found here, without the ssh part, which is pretty much secured with public/private authentication, login is permitted from a single local IP, with a ten count on the number of tries before getting banned and the passphrase being a 25 character license key of a program.

But let's not digress, the problem is as follows, the attacks consist of either SYN flooding, for which I had previously activated tcp_syn_cookies, either by attacking different ports for the usual things, MySQL, VNC, Samba, etc. Now, with the SYN flood, let's say the syn_cookies help, but I don't know how much ... As for the rest of the ports they attack, the server is one of the servers whose primary purpose is to keep alive a webhosting company, so that implies having to open a number of ports for different needs, and my concern is the HTTP/HTTPS 80/443 ports that have to remain open for inbound traffic. These ports get pounded with packets, and blocking the originating IPs has done little good, as the attackers generate random IP addresses, and by blocking the ones I get the hits from won't help for long either because they try from new ones. The "newest" thing they've done was to send packets with the source IP of the neighbouring servers, which need to communicate to one another.

Even at this point, let's say it wouldn't bother me as much that they're knocking away at the heavens door, but the Apache webserver has crashed on multiple occasions ever since the attacks began (I'm using Apache 2.0). What I've seen is that they manage to create multiple Apache child processes, so it jumps from a normal 30-40 processes to over 100-150 processes, at which point the websites stop loading and Apache wouldn't come back to life no matter what I've tried. Looking through it's logs, I got this:

[SnakeByte]

Hi,

some random things.

Can you post the physical connection setup of your machines,
for example, is there a single gateway to the internet,
and the ports which have to be open on which machine.

Maybe your iptales setup ( with real ips / hostnames removed )
could be some start for suggestions.


Maybe it is be possible to block MAC address zero?

best regards

[Hu]

Is the MAC address actually all zero in the log or is it that way because you blanked out the real MAC address?

The MAC address showed up as 14 octets because the kernel prints the entire layer 2 frame and labels it MAC. The layer 2 frame consists of the destination MAC address, source MAC address, and layer 3 type.

Be aware that the MAC address available to you is the address of the next hop, not the ultimate peer. As an example, take a packet capture while you ping two distinct Internet destinations, such as Google and Yahoo. Look at the MAC addresses in the returned ICMP echo responses. Thus, filtering by MAC address is really only useful if you are using it to whitelist traffic that comes from a directly attached system which is known not to route malicious traffic.

SYN floods should not be visible to Apache, since the connection must complete before the server is notified. In a SYN flood, the attacker uses spoofed source addresses that never ACK the SYN|ACK. The attackers must also be opening full connections to cause problems for Apache.

[danny_b85]

[Hu]

You might be able to use syncookies to combat the forged SYN packets that never complete a connection.

Since the attacks on Apache require a full three way handshake, the attackers must have control of the IP addresses that they use to initiate those connections. Theoretically, you could block them using Netfilter so that Apache does not receive new connections from those addresses. That said, it is possible that the attack is sufficiently heavy that you will not be able to identify and ban a significant portion of the attacking systems. If you cannot tell from the logs which connections are legitimate and which are malicious, this will be very hard. Without detailed knowledge of both legitimate behavior and malicious behavior, it is difficult to speculate on ways to distinguish them.

[danny_b85]

Hi, I found the problem, don't know why I didn't look into it earlier, I was using Apache 2.0.63, and it had a security vulnerability which was leading to a DoS attack (what a shock, that's what I was experiencing ... ).

I've upgraded to Apache 2.2.9, had some problems with the PHP not working correctly after the upgrade, solved that issue and now the server/s are working fine.

Hu, thanks a lot for your insight into the problem and for your help.