[RhinoSoft.com User Group] Event action to block an IP?

[Sparky]

I would like to be able to block an IP for a period when a logon
attempt for root, admin, etc is attempted, since this is almost
certainly a hack attempt. I could use the "execute command" event
action to manipulate the Windows firewall, but I'd rather do this
through Serv-U.

Is there a good way to to this?

Also, could it be considered for the next version to add an event
action "block IP for x minutes/hours/days/permanent"?

Thanks,
Michael

--
You received this message because you are subscribed to the Google Groups "RhinoSoft.com User Group" group.
To post to this group, send email to rhinosoft-...@googlegroups.com.
To unsubscribe from this group, send email to rhinosoft-user-g...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhinosoft-user-group?hl=en.

[FTPServerTools]

There is no easy and simple way I found to do this. It is possible tho
but you would need to use a dll you would need to make yourself or a
self made external program...

[Sparky]

I found an workable solution, although not ideal.

First create a script similar to this

@echo off
echo %1, %2, %3, %4, %date%, %time% >>C:\WINDOWS\system32\LogFiles
\Serv-U\block.log
route ADD %1 MASK 255.255.255.255 1.2.3.4

Replace 1.2.3.4 with any address on your subnet that is unused and
otherwise unable to actually route traffic. Name the script something
like block.cmd and save it to your Serv-U program directory.

Next, create user accounts that are commonly targeted for exploit
(assuming you don't actually use these IDs): root, admin,
administrator, etc. Make sure if someone actually accesses one of
these IDs that they have no access to any valuable resources. Set
ridiculously hard passwords and don't bother remembering them. Create
a group (I named mine hackblock) and throw them into it.

Now create an event action for that group. Use event type "user login
failure" and "execute a command" for the action. Enter the path to the
script you just created and enter "$IP $Name $Protocol $IPName" for
command line parameters.

What this will do is any time someone tries to login to your server
using one of these "trap" IDs, an invalid TCP/IP route will be added
for their IP address, making it impossible for them to communicate
with your server. This route is not persistent - the next time you
reboot the block will be lifted. If you use "route -p ADD..." in your
script it will be persistent, but you probably don't want to do that
since having hundreds (or thousands) of single host routes build up
over time will probably not be good for your server's performance. I
think a non-persistent black-hole route on a server that gets rebooted
every few weeks will probably not be a problem. (If it is I'll know
soon and post back here!)

Other ways of doing this including using a command to modify the
Windows firewall instead of adding a dead route (http://
support.microsoft.com/kb/947709). That's the way to go for a
persistent block. If you use IPSec you could also script a deny rule
for it. You can also use the block log created by the command above to
keep track of offenders and manually add them ot Serv-U's block list.

As FTPServerTools said, if you can code, you write a custom
integration DLL for Serv-U and really do this right. But I don't code :
(

I would really like to see the following enhancements to Serv-U's
configuration management:

1 - An event action or limit setting to allow "block IP for x minutes/
hours/days/permanent" for invalid logon attempt, set either by ID or
IP, by count/time.
2 - The ability to specify an include file for IP access. The include
file would be very useful if it could be set differently in all the
different places you can set an IP restriction and would be pretty
simple to implement (I think). Also some way of having the server
refresh from the include file periodically, or automatically on
change, or by a manual trigger. This would be a huge security enabler
for event actions.
3 - A command-line tool to add an IP restriction.

I don't think it would take much effort at all for Rhinosoft to
implement item 2.