Four years ago, I wrote about a script that I had been working on called Authban (though I didn't name it at the time):
http://blog.vollink.com/2011/09/geek-attack-vectors-and-twitter.html
I first started running a custom script to block IP addresses that tried too many times to login to ssh back in 2010. At the time, the script (and my home web host) was running on an Ubuntu virtual server. The name, Authban, surfaced in early 2011, as I organized the script to do more than just block ssh.
The First Rewrite
Since writing the initial introduction, my home web site was ported to Mac OS X, and along with it, Authban.
The first thing that had to change is that I no longer had iptables available, so the way my script was blocking IP addresses was no longer available, the Apple world prefers the BSD program pf (packet filter). With this came a very large number of little changes in many places. At that point (2013), the Authban script became a full OO Perl application module set, in which, PfCtl.pm is one piece. It also has a full test suite, and I did a very large number of upgrades to the threat vector detection. Another upgrade I did at that time was to database the blocked IP addresses directly into mysql.
The Second Rewrite
I was contacted by the administrator of a honey-pot aggregator about two months ago, after I did some maintenance on the volIPBan Twitter account. Despite my running a production system (and not a honey-pot), I was asked to contribute my threats. Seems legit enough (and no harm, even if it isn't), but I realized that this would be the right opportunity to fix one of the problems that has long plagued my little project: Slow run time.
I'm currently on the ninth running version of the second re-write, and I have a LOT more to do. However, as of today, I should be contributing my threats as promised. The aggregator takes some pains to not reveal the IPs or locations of the contributors, but since I'm running a web site and would rather be black-listed as a honey-pot, I'm happy to mention it here.
Still to come
Some of the other upgrades I'm doing has to do with ramping up my use of MySql, not only to store threats already blocked, but to store tallies on all IP addresses that contact my site for any reason. This will help me detect attacks that happen slowly, over weeks (and over log rotations) that I might now always pick up, currently. Also, by keeping these sorts of statistics, I'll also be able to scan all the various log files from the place I last left off, instead of the current method of reading every log file from the beginning. I try to run 3 times per minute, and if the log rotation wheels are against me, I can sometimes go a week where the run-time consistently lasts longer than 20 seconds. By the time I'm done with the second rewrite, I want to see this additional database functionality working.
I still have multiple modules (like the one that does twitter) that includes embedded authentication information. I also do not have all of the threat vectors that I have defined put into an external configuration file. Both of these prevent me from publishing this little work somewhere. Maybe this won't happen as part of the second rewrite, but I do plan to get this done at some point.
http://blog.vollink.com/2011/09/geek-attack-vectors-and-twitter.html
I first started running a custom script to block IP addresses that tried too many times to login to ssh back in 2010. At the time, the script (and my home web host) was running on an Ubuntu virtual server. The name, Authban, surfaced in early 2011, as I organized the script to do more than just block ssh.
The First Rewrite
Since writing the initial introduction, my home web site was ported to Mac OS X, and along with it, Authban.
The first thing that had to change is that I no longer had iptables available, so the way my script was blocking IP addresses was no longer available, the Apple world prefers the BSD program pf (packet filter). With this came a very large number of little changes in many places. At that point (2013), the Authban script became a full OO Perl application module set, in which, PfCtl.pm is one piece. It also has a full test suite, and I did a very large number of upgrades to the threat vector detection. Another upgrade I did at that time was to database the blocked IP addresses directly into mysql.
The Second Rewrite
I was contacted by the administrator of a honey-pot aggregator about two months ago, after I did some maintenance on the volIPBan Twitter account. Despite my running a production system (and not a honey-pot), I was asked to contribute my threats. Seems legit enough (and no harm, even if it isn't), but I realized that this would be the right opportunity to fix one of the problems that has long plagued my little project: Slow run time.
I'm currently on the ninth running version of the second re-write, and I have a LOT more to do. However, as of today, I should be contributing my threats as promised. The aggregator takes some pains to not reveal the IPs or locations of the contributors, but since I'm running a web site and would rather be black-listed as a honey-pot, I'm happy to mention it here.
Still to come
Some of the other upgrades I'm doing has to do with ramping up my use of MySql, not only to store threats already blocked, but to store tallies on all IP addresses that contact my site for any reason. This will help me detect attacks that happen slowly, over weeks (and over log rotations) that I might now always pick up, currently. Also, by keeping these sorts of statistics, I'll also be able to scan all the various log files from the place I last left off, instead of the current method of reading every log file from the beginning. I try to run 3 times per minute, and if the log rotation wheels are against me, I can sometimes go a week where the run-time consistently lasts longer than 20 seconds. By the time I'm done with the second rewrite, I want to see this additional database functionality working.
I still have multiple modules (like the one that does twitter) that includes embedded authentication information. I also do not have all of the threat vectors that I have defined put into an external configuration file. Both of these prevent me from publishing this little work somewhere. Maybe this won't happen as part of the second rewrite, but I do plan to get this done at some point.