trisweb's questions

Here's the deal: I have a persistent Chinese botnet that spams my forum (running on an Ubuntu 12.04.2 server on nginx, etc). I've been using UFW (Ubuntu's "Uncomplicated FireWall") for managing the firewall, just as a simple way to not have to deal with iptables.

I've identified the extremely consistent and unique (not to mention dumb) URL that it attempts to load each time a bot hits, and from that made a cron to parse the access logs every hour and find new attackers, and ufw deny from [ip-address] on them.

However, the onslaught just doesn't stop. It's incredible. I'm logging each blocked IP, and it's up to almost 17,000 IPs. 98% of the IPs are from China, with a few here and there from other countries.

This appears to be working well: in practice, all those attacks are blocked, and the connections have gone back to normal, traffic has gone down exponentially, and the effective DDOS has stopped (if I let these clients through, the volume and speed of the requests is staggering).

UFW also seems to be okay with it. Nothing is slowing down, requests are being served with the same speed, latency hasn't suffered as far as I can tell. I've tried combining the individual IPs into ranges as much as possible, but it would be difficult to figure out all of them, and would block an order of magnitude more IPs than are actually causing problems.

So, some questions:

1. How many rules (presumably iptables when all is said and done) can I reasonably have before I should be worried?
2. Is there any possible negative effect to continuing this exact practice?
3. Any suggested changes or improvements?
4. Does anyone know about this bot? It's attacking bbPress. Is there a better way to prevent attacks like this rather than treat the symptoms?

I don't want to block all of China, unfortunately, since I know we have users there...

Running Ubuntu on a 2.6.31-302 x86-64 kernel. The overall problem is that I have memory in the 'cached' category that keeps on going up and will not be freed or used even when our application needs it.

So here's what I get out of the 'free' command. None of this looks out of the ordinary at first glance.

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

The first thing someone's going to say is "Don't worry, linux manages that memory automatically." Yes, I know how the memory manager is supposed to work; the problem is that it's not doing the right thing. The "cached" 1.4 GB here appears to be reserved and unusable.

My knowledge of Linux tells me that 3 GB is "free"; but the behavior of the system says otherwise. When the 1.6 GB of real free memory is used up during peak usage, as soon as more memory is demanded (and the 'free' in the first column approaches 0) the OOM killer is invoked, processes are killed, and problems start to arise even though the 'free' in the -/+ buffers/cache row still has about 1.4 GB 'free'.

I've tuned the oom_adj values on key processes so it doesn't bring the system to its knees, but even then important processes will be killed, and we never want to reach that point. Especially when, theoretically, 1.4GB is still "free" if it would only evict the disk cache.

Does anyone have any idea what's going on here? The internet is flooded with the dumb questions about the Linux 'free' command and "why don't I have any free memory" and I can't find anything about this issue because of that.

The first thing that pops into my head is that swap is off. We have a sysadmin that is adamant about it; I am open to explanations if they're backed up. Could this cause problems?

Here's free after running echo 3 > /proc/sys/vm/drop_caches :

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5731688    1626804          0        524    1406000
-/+ buffers/cache:    4325164    3033328
Swap:            0          0          0

As you can see, some minuscule amount of cache is actually freed up, but around 1.4 GB appears to be "stuck." The other problem is that this value seems to rise over time. On another server 2.0 GB is stuck.

I'd really like this memory back... any help would be most appreciated.

Here's cat /proc/meminfo if it's worth anything:

# cat /proc/meminfo 
MemTotal:        7358492 kB
MemFree:         1472180 kB
Buffers:            5328 kB
Cached:          1435456 kB
SwapCached:            0 kB
Active:          5524644 kB
Inactive:          41380 kB
Active(anon):    5492108 kB
Inactive(anon):        0 kB
Active(file):      32536 kB
Inactive(file):    41380 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               320 kB
Writeback:             0 kB
AnonPages:       4125252 kB
Mapped:            42536 kB
Slab:              29432 kB
SReclaimable:      13872 kB
SUnreclaim:        15560 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3679244 kB
Committed_AS:    7223012 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        7696 kB
VmallocChunk:   34359729675 kB
DirectMap4k:     7340032 kB
DirectMap2M:           0 kB