Erics Tech Blog » Security

Modsecurity 2.5 Review Coming

eric — Sun, 22 Nov 2009 11:00:12 +0000

The folks over at Packt Publishing are kind enough to send me out an advance copy of the upcoming Modsecurity book by Magnus Mischel. I have written about mod security before, but really haven’t had a chance to look into it recently. I am anxious to see where its advanced to in version 2.5.

If you don’t know anything about mod_security, I encourage you to read up on it in the interim.

Stay tuned for the review.

Mod-Security 2.5 by Magnus Mischel

Redacted On A Feedback Loop

eric — Fri, 28 Aug 2009 00:00:43 +0000

This post is a little more of a rant than I usually make, but I think its warranted. If you don’t know what a feedback loop is, read here.

I’m not sure who thinks its a good idea to replace all instances of an email addresses in a feedback loop with [redacted]@feedbackloopcompany.com, but it is of no help to anyone. An argument can be made for protecting the identity of the recipient, but that argument holds little weight because there is little the sender can do about it.

If a sender needs to go through the authorization process of a larger recipient domain (like AOL, Yahoo!, or Excite for example) where their IP reputation is checked and their history is checked, etc. then why should there still be restrictions placed on the information going between the two domains (you as the sender and them as the recipient domains). I am aware that the draft specification allow the operating domain for the feedback loop to keep the identity private of the user clicking the “Report SPAM” button, but that forces the sending domains to use tactics to circumvent this to keep their reputation up.

Therefore I believe that if a sending company has verified their feedback loop address, they should be able to see which recipient reported their email as “Junk”. Get rid of the redacted and leave the email address intact.

Checking Roles in Views Using RoleRequirement

eric — Thu, 06 Aug 2009 15:00:42 +0000

One of the rails projects I am working on is using the RoleRequirement plugin. This is a great plugin for seamless integration of roles into the controller level, but there wasn’t really much documentation on integrating this into the views themselves. So I figured I would put this little gem out there which has done wonders for the DRYness and cleanliness of my code.

For instance, the code below checks whether or not the current user has the admin role. If they do, it prints the admin menu (in my case I use a partial for this).

< % if current_user.has_role?('admin') %>

<h2>adminh2>
< %= render :partial => '/layouts/admin' %>

< % end %>

The great thing is that (although it might be a little unclean), you can chain some conditionals here to show the appropriate menu items based on a users role(s). This is powerful because a user< ->role relationship is a HABTM (Has And Belongs To Many) relationship.

Checking For A DoS

eric — Mon, 17 Nov 2008 14:00:58 +0000

Working on groups of web servers, especially ones that are highly susceptible to attack, it is a good idea to have a string of commands that will allow you to check what is going on.

Check for DDos:

netstat -n | grep EST | awk '{ print $5 }' | cut -d: -f1 | sort | uniq -c | sort -nr | perl -an -e 'use Socket; ($hostname, @trash) = gethostbyaddr(inet_aton($F[1]), AF_INET); print "$F[0]\t$F[1]\t$hostname\n";'

Using this command will produce a list of hostnames that have a connect to the machine in an ESTABLISHED state. This is handy for creating a firewall rule either on the host (iptables, ipfw) or a little further away from the machine (at the edge router).

Check for web attacks:

cat eric.lubow.org-access_log.20081015 | awk '{print $1 }' | sort | uniq -c | sort -nr | head | perl -an -e 'use Socket; ($hostname, @trash) = gethostbyaddr(inet_aton($F[1]), AF_INET); print "$F[0]\t$F[1]\t$hostname\n";'

By using this command, you will get a hostname lookup on the IP sorted by total hit count descending. As when checking for DDos attacks, you can use this information to write firewall rules.

More web attack checks:

for i in `ls *.20081015 | grep -v error`; do echo "##### $i ######"; tail -n 10000 $i| awk '{print $1};' | sort -n | uniq -c | sort -nr | head -2; done

The difference between this check and the previous check is that this time, you may have a lot more logfiles to go through. I am also assuming that they are stored by .. They will print out which file its scanning and the top 2 issues from that file.

Referrer Check:

for file in `ls -lrS *access*20080525* | tail -n20`; do echo "==========" $file; gawk --re-interval -F'"' '{ split($4, myrt, "/"); split($0, myct); split(myct[3], myc, " "); if (length(myrt[3])==0) { myrt[3]="none"}; if (myrt[3] ~ /([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}/) { referrers[myrt[3]"/"myc[1]]++; } else { t=split(myrt[3], myrt2, "."); myref="*."myrt2[t-1]"."myrt2[t]; referrers[myref"/"myc[1]]++; } } END { for (referrer in referrers) { print referrers[referrer], referrer } }' $file | grep -v none | sort -n; done

This last check will get the referrer for a page from the logs and count up the number of times that exact referrer drives traffic to your page. Although this may initially appear to be only tangentially useful, if you are getting DDos, it may be hard to track down. Let’s say that you have some static content like a funny image and want to know why everyone is going to that image. Maybe your getting Dugg or ./ and this will help you tell (and find out what your page is so you can Digg yourself if you’re into that sort of thing).