IIS 6 FTP Server brute force attacks, can I block IPs automatically after many failures? RRS feed

  • Question

  • User1206389878 posted

    Every time I check my server logs, I've got some IP address hitting my server a few thousand times in a row with a random username.  Usually it has several requests per second for a few hours at a time.

     Each time I find this, I block the IP address in IIS which stops it until they switch IP addresses.

     Is there a way to automatically have the IP blocked after a set number of failed logins?  My FTP server doesn't get much "real" traffic so I'm not concerned with locking out actual users.


    Thursday, September 7, 2006 3:47 PM

All replies

  • User-823196590 posted
    I'm not aware of any existing product or technique to do this.
    Thursday, September 7, 2006 3:55 PM
  • User989702501 posted
    Some smart IDS and expensive firewall have this feature I think.... blocking at IIS level will not help as well if the attack traffic is huge.
    Thursday, September 14, 2006 12:50 AM
  • User-496721008 posted

    Check out this link. It seems to do the job.


    Monday, October 16, 2006 8:30 AM
  • User-823196590 posted
    Monday, October 16, 2006 10:13 AM
  • User989702501 posted

    LOL... finally - someone took the time and write it.  Here's another post with similar intention.


    Tuesday, October 17, 2006 12:35 AM
  • User1234732635 posted

    Well, that script will make sure that no matter how many times they try, the brute force robot will never get in, but your server will still respond to every request for hours on end using precious resources and bandwidth. I've written a small application in .NET that will stop your server from responding completely. You'll see a few entries in your logs, but once the app sees the attack those entries will cease from that IP. It works for me, but I would need to add some additional configuration options if I were to distribute it.  So, that being said, would anyone here pay 3-5 bucks for something that would solve this problem once and for all? Also let me know if you'd prefer a windows service over a desktop application though I'll probably write both and give you guys a choice.

    Please reply in this thread or contact me.



    Friday, October 26, 2007 12:46 PM
  • User-1853252149 posted

    Stopping brute force attacks isn't the job of a web server, or any server for that matter.  These need to be stopped at the edge of the network, in a firewall or IDS.  Otherwise they just become DOS attacks and shut down access to the server anyway.


    Friday, October 26, 2007 5:32 PM
  • User1234732635 posted

    Firewalls don't know the difference between good and bad traffic if that traffic is not at the DOS attack frequency. I agree that restricting access is the job of the firewall; however I don't know of anyway to setup NATing, filters or anthing else that will reliably determine the difference between a brute force attack and legitimate traffic. Even if this product does exists it likely costs upwards of $5,000. I'm simply offering a solution to hobbiest and those running home networks or managing a small business and can't afford to spend more on a firewall than they did on their main server. Go ahead, give it a shot. ftp://fhclive.com. FYI: it'll take 10 attempts before it recognizes the attack and anonymous is allowed so try another user (i.e. administrator). if you like what you see email ftp@fhclive.com

    Monday, October 29, 2007 11:26 AM
  • User1256146517 posted

    A very inexpensive solution for blocking FTP Attacks on IIS servers can be found at:

    It is very useful for smaller business who don't have hardware firewalls or sniffers to block these attacks.


    Thursday, October 1, 2009 11:18 AM
  • User-376128307 posted

    May be it is a little late for answer. But if you are looking for commercial solution e.guardo is best.


    I am using it for Sharepoint and FTP protection.

    Friday, January 18, 2013 6:42 PM
  • User42427535 posted

    Here is a free solution to FTP attack blocker


    Thursday, January 31, 2013 12:09 AM