Jim's Depository

this code is not yet written

I have a server which contains a bunch of virtual machines. These machines are continually harassed by script kiddies. I use Fail2ban to keep the trolling to a minimum. 

  • Each virtual machine sends its syslog activity to the physical server, using something like this in its syslog.conf…  *.* @some.host.com
  • The physical server saves all the syslog activity from the virtual machines, safe from tampering. (/etc/defaults/syslogd needs a -r)
  • fail2ban runs on the physical server and drops bans into the FORWARD chain to protect the inner machines.
  • The syslog port needs to be protected to only take traffic from trusted machines.  This ought to block anything from the machine’s two physical ethernets but let through the virtual ones… /sbin/iptables -I INPUT -p udp –dport 514 -m physdev –physdev-in eth0 -j REJECT /sbin/iptables -I INPUT -p udp –dport 514 -m physdev –physdev-in eth1 -j REJECT

Things that needed changing…

/etc/fail2ban/actions.d/iptables.conf… the actionstart and actionstop need to also put the chains into the FORWARD rule….

# Option:  fwstart

# Notes.:  command executed once at the start of Fail2Ban.

# Values:  CMD


actionstart = iptables -N fail2ban-<name>

              iptables -A fail2ban-<name> -j RETURN

              iptables -I INPUT -p <protocol> –dport <port> -j fail2ban-<name>

              iptables -I FORWARD -p <protocol> –dport <port> -j fail2ban-<name>

# Option:  fwend

# Notes.:  command executed once at the end of Fail2Ban

# Values:  CMD


actionstop = iptables -D INPUT -p <protocol> –dport <port> -j fail2ban-<name>

             iptables -D FORWARD -p <protocol> –dport <port> -j fail2ban-<name>

             iptables -F fail2ban-<name>

             iptables -X fail2ban-<name>

Interesting observation when using a single fail2ban on multiple machines. It catches horizontal sweeps much sooner. Today I noticed it catch someone that was making one try at root on each of my machines. The merged auth.log files tripped my 10 hour ban after one attempt on each of three machines.

Things you will want to know if you have to replace your OpenVPN certificates, because say you got caught in the Debian key entropy problem.

  • Don’t forget to also run build-key-server.
  • Don’t forget to copy keys/server.* and ca.crt up to /etc/openvpn if that is where you keep them.
  • Each windows client with old keys is going to chew up 30 slots in your server until they get new keys. If you have many users, you don’t have enough slots. The windows clients retry every two seconds, but it takes 60 seconds to time out on the server side.

I had to resort to grepping syslog and dropping firewall blocks on people trying old certificates. I used another script watching my http logs to unblock people who had created new certificates. “TLS Error: TLS key negotiation failed to occur within 60 seconds” is a good bit to select IPs for blocking.

You know you have too many clients connected if you see “MULTI: new incoming connection would exceed maximum number of clients“ in the syslog.

I’ve added a few features today.

  • There is now a ‘recent comments’ link under Contribute. It also has its own RSS feed, so I can watch for comments should the comment spammers get through.
  • Articles now have URLs constructed from their titles. I feel I could do better at this. I need to read some papers on automated abbreviators.
  • I fixed a nasty little problem where a sqlite3 “insert or replace” was whacking my password. Turns out that deletes the whole row on a replace, so you better be specifying all the field values.

And now 4 days later.

  • I now log much of the POST methods into my database. There is a distributed botnet trying to leave a comment on one article in this blog. I’m curious what they wish to say. I’d hate to miss out on a first contact situation.
  • Found a couple URLs that were missing their “.php”.  Apache was ok with this, lighttpd is not.
I have made contact with the robots. We should all be afraid. Thus far the robots have attempted to add these comments:
  • SEX
  • SEX
  • zubav1na-ps1h1chesk1e-bolezn1  except the digits 1 are supposed to be the letter 'i', I just didn't want to get indexed by it.
I suppose some filtering software will now block my site because it talks about sex.
More robot chatter:
  • fandango
  • tatuazh
So if a tattooed robot offers to dance the fandango with you, you should know it only wants sex.