PSAD and signature updates

Is it true that the creators of PSAD haven't updated the PSAD signatures since 2007???

Line 29 of my /etc/psad/signatures file:

# $Id: signatures 2129 2007-12-12 04:56:10Z mbr $

As well, at http://www.cipherdyne.org/psad/signatures, it is on line 28.

Dead project?  Not sure, but the signatures are old as hell!  While I don't think it's a usage deal-breaker, I'm rather surprised.  Does it need updated signatures?  Probably not, but every little bit helps, especially nowadays.  I'd much rather a developer (and package maintainer) be up-front about such things.

PSAD - DoS'd my Linode and my G-mail account

Yes, I DoS'd myself.

How?

I was tuning my firewall so that PSAD wouldn't alert on traffic from my static IP.  This was caused by me using a half-baked firewall policy (ie, the firewall was allowing too much and not blocking what it should've).  So, while making the policy more secure, I ended up blocking some of DNS, which the firewall blocked via the clean-up rule (deny by default policy on all chains).  

I didn't double-check my work, and 24 hours later, I was checking the server via the admin console and saw that the disk I/O was extremely high when looking at the system graphs.  CPU utilization was also wayyy up.  

I initially couldn't figure out what was going on, until I used Webmin to access the server and found that it was taking forever for the server to resolve the domain address.  As well, there were like 30,000 e-mails in the Postfix e-mail queue.  I was basically spamming the hell out of Gmail and DShield.  I'd begun to wipe out all the Gmail notifications, but I soon realized that I wasn't making any headway, so I killed PSAD, cleared ALL the mail in the queue, then restarted PSAD.  It was still generating e-mails, though, so I turned off e-mail notifications, as well as syslog notifications.  I also killed my DShield log feed.  THEN I fixed DNS by just rolling back to a known good policy...then I told PSAD to not log on port 53/UDP (no real need to log that traffic anyways, unless it hits the catch-all rule, but that wouldn't happen now since I fixed DNS within the policy).

It took quite awhile for Gmail to finish processing the e-mails (the ones that I couldn't kill via Postfix).

I just now re-enabled syslogging and the DShield log feed, but may have to reach out to the SANS team to see if they can remove all DNS traffic that was logged by my static IPs.

I think I've everything fixed now.

PSAD

I decided to give PSAD a spin on the Linode since I've never tried it before.  I'm impressed at the features of  it.  I've been running it maybe a bit over a month.  I get alerts whenever PSAD detects a scan or when it logs and drops specific traffic, so I'm aware of what's going on (instead of having to check my firewall logs).  One of the main reasons I decided to give PSAD a spin is because my fwanalog setup stopped working due to a code bug that affects Ubuntu v12.04.

One of the things I've been doing (I used to do this in the past) is I send my dropped logs to Dshield.org (or isc.sans.org).  One of PSAD's features enables me to send the logs, vs. using third-party or Dshield apps.

I noticed when sending my logs that I'm catching bidirectional traffic and my server IP is being flagged as a result.  Why?  I was blocking 118.0.0.0/8 (a large segment of APAC).  I was not only blocking but sending resets, which requires my firewall to send resets when means my IP is talking back, even though it's ending the session.  My firewall logs it as a drop.  To fix this, I just configured the firewall to drop the traffic, although I could've just changed the --log-prefix tag to something other than DROP, which by default PSAD looks for.  I'll monitor the Dshield logs to see how PSAD is now reporting.