New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
@Steve81, what type of load did you use with siege that caused the hash table to get saturated? What was the iptables logging memory set to? What happened to requests when the hash table was full?
@Xeoncross: Was ab, with 500 concurrent connections. Don't remember the iptables settings. Connection dropped with the table full.
@Steve81, Interesting, I didn't know you could set AB to spoof different IP Addresses...
@Xeoncross: I don't like too much your mood. Ofc ab can't spoof the ip.
Any iptables anti ssh-bruteforce script use the state module (that use the conntrack module) to avoid to count any packet related to already estabilished connections.
Note that the conntrack track each connection not each ip or connection on a specifical port.
If my memory isn't wrong, was this issue:
http://www.cyberciti.biz/faq/ip_conntrack-table-ful-dropping-packet-error/
As I can suppose, by the fact that the problem came after 10/20 seconds of ab, conntrack won't remove instantly closed connections.
I could increment the hash table size, but I found more secure to avoid to use conntrak totally. And so trash the iptables script.
I think something must be messing. It sound's like you're mistaking my statements.
At any rate, I'm interested in your research because I use iptables alone on one of my boxes and wasn't aware of the conntrack problem. Thanks for the links.