Wikipedia defines 'Script Kiddies' in this informal way: "In hacker culture, a script kiddie, occasionally script bunny, skiddie, script kitty, script-running juvenile (SRJ), or similar, is a derogatory term used to describe those who use scripts or programs developed by others to attack computer systems and networks."
In the recent months, I have encountered several 'script kiddies', both of a domestic and foreign locations, attempting to brute-force hack their into my SSH and FTP server. Since I have a need for both applications for personal and business needs, I needed a quick and easy way to 'fix their little red wagon' and keep my site running without having to watch it day and night. As a result, I discovered that someone had developed a Perl script (URL below) but it was only intended for ssh attacks, so I took it upon myself to help improve the script and give it the ability to watch over the ProFTPd application processes as well.
Block.pl script (the one for sshd) can be found here: http://shellscripts.org/pr
But before the script could be deployed as a counter to these ssh and ftp brute-force attacks, I first needed to harden my existing network infrastructure.
First, I reconfigured my router to port forward port 19 (or whatever non '21' port) to port 21 on the IIS/FTP server. Then I configured port 21 on the router to forward to the Linux server (as described below). This way I can tell my customers to use the new FTP forwarded port (i.e. '19') to access the 'other' IIS/FTP server site.
Second, I setup a basic Linux server w/ IPTables. I setup a CentOS Linux server on the same network with the Windows server. On the Linux server, I configured ProFTPd to be the FTP server running on port 21. I then downloaded and executed (in background/nohup mode -- 'nohup ./myapp.pl &') a modified 'block.pl' Perl script (see URL below) to scan the message log for incoming SSH & FTP attempts.
Modified block.pl script -- http://www.mwecomputers.co
When a script kiddie attacks, the block.pl script will read the /var/log/messages file for the attack trigger response, determine if the attack is of an 'ftp' or 'ssh' type and then impose a special IPTables firewall rule -- based on the IP address -- to drop the incoming attempts. After a period of one hour, the script check to see if the attack from the offender's IP address have subsided. If the offender has disappeared, the script will then actually clean itself up and remove the offender's IP address from the firewall rule and watch the /var/log/messages file for another attack to happen.
Personally, I have utilized this script and during the first hour alone, the modified block.pl script was able to drop nearly 40 script kiddies and put a knot in their chain. Since the script cleans itself up, I did not have to check to see if my server was operational or not. I was happy and my customers were just as happy.
For other ideas on how to improve this script or make your own 'script kiddie' prevention, I recommend taking at look at this article...
Dynamic IPTables Firewalls:
http://www.gentoo.org/doc/
Good luck!
-- Michael
In the recent months, I have encountered several 'script kiddies', both of a domestic and foreign locations, attempting to brute-force hack their into my SSH and FTP server. Since I have a need for both applications for personal and business needs, I needed a quick and easy way to 'fix their little red wagon' and keep my site running without having to watch it day and night. As a result, I discovered that someone had developed a Perl script (URL below) but it was only intended for ssh attacks, so I took it upon myself to help improve the script and give it the ability to watch over the ProFTPd application processes as well.
Block.pl script (the one for sshd) can be found here: http://shellscripts.org/pr
But before the script could be deployed as a counter to these ssh and ftp brute-force attacks, I first needed to harden my existing network infrastructure.
First, I reconfigured my router to port forward port 19 (or whatever non '21' port) to port 21 on the IIS/FTP server. Then I configured port 21 on the router to forward to the Linux server (as described below). This way I can tell my customers to use the new FTP forwarded port (i.e. '19') to access the 'other' IIS/FTP server site.
Second, I setup a basic Linux server w/ IPTables. I setup a CentOS Linux server on the same network with the Windows server. On the Linux server, I configured ProFTPd to be the FTP server running on port 21. I then downloaded and executed (in background/nohup mode -- 'nohup ./myapp.pl &') a modified 'block.pl' Perl script (see URL below) to scan the message log for incoming SSH & FTP attempts.
Modified block.pl script -- http://www.mwecomputers.co
When a script kiddie attacks, the block.pl script will read the /var/log/messages file for the attack trigger response, determine if the attack is of an 'ftp' or 'ssh' type and then impose a special IPTables firewall rule -- based on the IP address -- to drop the incoming attempts. After a period of one hour, the script check to see if the attack from the offender's IP address have subsided. If the offender has disappeared, the script will then actually clean itself up and remove the offender's IP address from the firewall rule and watch the /var/log/messages file for another attack to happen.
Personally, I have utilized this script and during the first hour alone, the modified block.pl script was able to drop nearly 40 script kiddies and put a knot in their chain. Since the script cleans itself up, I did not have to check to see if my server was operational or not. I was happy and my customers were just as happy.
For other ideas on how to improve this script or make your own 'script kiddie' prevention, I recommend taking at look at this article...
Dynamic IPTables Firewalls:
http://www.gentoo.org/doc/
Good luck!
-- Michael