locked
FTP and Brute force (yet again) RRS feed

  • Question

  • User-2133191591 posted

    Dear IIS Developers,

     

    I can't find a single post that states Microsoft's position on this issue, so I came here looking for input.

     

    I know I'm not the first to bring it up, but I just can't seem to figure out why it hasn't been addressed. All my servers that have FTP enabled have the logs chronically maxed with login attempts. This makes IIS FTP not a realistic option for public facing ftp servers. I've seen a few posts saying this is the job of the IDS systems, but I disagree. IDS is good at preventing DDOS attacks, not long term slow brute force attacks (which most FTP attacks are like now). IDS also can't tell difference between successful FTP attempts vs. fails. I have plenty of other reasons but I don't want to waste your time :)

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>

    All third party solutions appear to scan logs to figure out the same information. Large logs tend to cause problems for these programs/scripts, and they frequently drag down the ftp server when they crash. Not to mention they really don't ban IPs in real-time (only every time they scans logs).

    <o:p> </o:p>

    Even a small feature that, when enabled, tracks login attempts and bans IPs if the number of attempts passes a certain threshold within a set amount of time, would be great. It won't use up much memory because it will only track the IPs that have made failed attempts within a set amount of time. Those IPs whose failed attempts don't surpass the limit simply expire out of the in-memory list.

    <o:p> </o:p>

    As an administrator and not a developer, I know I might be missing something in terms of code complexity. I just need to know what that is so I can stop dreaming. As this must be the 210938120938 time someone has brought up this point to the IIS development team, I'm very curious what you guys think.

    <o:p> </o:p>

    Thanks

    <o:p> </o:p>

    <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:City w:st="on"><st1:place w:st="on">Eugene</st1:place></st1:City>

     

    Wednesday, December 5, 2007 8:15 PM

Answers

  • User1073881637 posted

    http://forums.iis.net/t/1024380.aspx   Necessity is the mother of all invention.  Someone wrote a script, take a peak at the google posting link by Bernard.

     

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, December 5, 2007 11:36 PM
  • User-1122936508 posted

    Some other options might involve:

    a) not permitting non-anonymous access to public FTP servers (someone can't brute force an account when there is no offered authentication protocol)

    b) configuring account lockout (even if only for 1-2 minutes). This dramatically changes the equation for brute force attempts.

    HTH

    Cheers
    Ken

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Thursday, December 6, 2007 1:07 AM
  • User-1853252149 posted

    I know I'm not the first to bring it up, but I just can't seem to figure out why it hasn't been addressed.

    This has been addressed.  It's not an FTP function or an FTP server function, it's a firewall/IDS issue.  No third party FTP server, or any server service of any kind, does packet filtering or stateful inspection, and these types of attacks occur on all services.  Most IDS systems have rule sets which can handle multiple attempts from a specific IP over a period of time.

    FWIW, this isn't an FTP issue, an IIS issue or a Windows issue.  It's a security issue that affects all operating systems and all services, from FTP to email to simply getting root.  It would be pretty myopic to write logic to stop this into only one service for one platform.  Configure your Windows security properly, account lockout policies, strong passwords, strip common accounts and so on.  Then move off the box to stop attacks at the perimiter.

    Jeff

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Thursday, December 6, 2007 6:28 AM

All replies

  • User1073881637 posted

    http://forums.iis.net/t/1024380.aspx   Necessity is the mother of all invention.  Someone wrote a script, take a peak at the google posting link by Bernard.

     

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, December 5, 2007 11:36 PM
  • User-1122936508 posted

    Some other options might involve:

    a) not permitting non-anonymous access to public FTP servers (someone can't brute force an account when there is no offered authentication protocol)

    b) configuring account lockout (even if only for 1-2 minutes). This dramatically changes the equation for brute force attempts.

    HTH

    Cheers
    Ken

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Thursday, December 6, 2007 1:07 AM
  • User-1853252149 posted

    I know I'm not the first to bring it up, but I just can't seem to figure out why it hasn't been addressed.

    This has been addressed.  It's not an FTP function or an FTP server function, it's a firewall/IDS issue.  No third party FTP server, or any server service of any kind, does packet filtering or stateful inspection, and these types of attacks occur on all services.  Most IDS systems have rule sets which can handle multiple attempts from a specific IP over a period of time.

    FWIW, this isn't an FTP issue, an IIS issue or a Windows issue.  It's a security issue that affects all operating systems and all services, from FTP to email to simply getting root.  It would be pretty myopic to write logic to stop this into only one service for one platform.  Configure your Windows security properly, account lockout policies, strong passwords, strip common accounts and so on.  Then move off the box to stop attacks at the perimiter.

    Jeff

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Thursday, December 6, 2007 6:28 AM
  • User-2133191591 posted
    Jeff, I read your comments in the original post (http://forums.iis.net/t/1024380.aspx) and disagree with you for several reasons. (you never responded to LucidObscurity, who made very valid points).

    You're right in that I am basically saying every service should have its own additional security settings... but that’s how it's supposed to be. Mail servers, ftp servers, web servers, are inherently different and will always require some amount of custom security settings.

    I think you are mixing several areas of network security in one big salad. Knowing the source IP is not really packet inspection. DDOS and brute force are completely different. These days viruses/hackers rarely flood any server unless they are trying to take it down. Most of the time is a steady stream of login attempts, trying to break in. Although the word "brute" seems strong... most of the time it just a trickle of traffic. This isn't that easy to just block.

    Furthermore, the kinds of IDS systems you have in mind aren't in your average firewall or router, and even the mid size stuff that has IDS built in requires some know-how to configure right (or you will just be chasing false alarms and locking out good traffic). Cisco is doing a good job of simplifying IDS but it's still not something I would dive into without a second thought. To assume that’s what everyone should have to protect a FTP server is not practical.

    The only thing in a network that knows a good login from a bad login is the FTP server itself, so the job of protecting itself falls back to it. If you are at a computer and try to login with the wrong password too many times, it locks you out for a period of time, preventing you from trying ANY login. With the FTP server, the lockout mechanism has to be the IP, and not the userid, to prevent the hacker from continuing to try other logins (so account lockout policies aren't a good solution).

    My final point is that a properly configured server should be able to stand open to the internet, without a defensive barrier (firewall or otherwise) in front of it, and remain secured. It shouldn't be assumed that the server is going to be protected by a third party.
    Thursday, December 6, 2007 3:22 PM
  • User-2133191591 posted

    http://forums.iis.net/t/1024380.aspx   Necessity is the mother of all invention.  Someone wrote a script, take a peak at the google posting link by Bernard.

     

    I mentioned in my post that the script solutions out there that read through logs aren't that great. They eat up a lot of resources looking through logs, and aren't realtime.

    Thursday, December 6, 2007 3:42 PM
  • User-2133191591 posted

    Some other options might involve:

    a) not permitting non-anonymous access to public FTP servers (someone can't brute force an account when there is no offered authentication protocol)

    b) configuring account lockout (even if only for 1-2 minutes). This dramatically changes the equation for brute force attempts.

    HTH

    Cheers
    Ken

    Both good points.

    Unfortunately option (a) can only be used in certain situations and option (b) is a good way to keep them from breaking in, but it won't stop the hammering away and use of resources. Also, if you don't block on an IP level then they can continue to try other logins as well as end up locking out a legitimate user.

    Thursday, December 6, 2007 3:48 PM
  • User1073881637 posted

    This is a tough issue especially if you are using FTP from IIS that was designed in like 1994 or around that timeframe.  Back then (yeah a whole 13 years ago) security wasn't the forefront of internet technologies.  If you say ANY FTP server should have it's own security, then you are mistaken. 

    There is no perfect answer from what I can tell, it takes a blend of various solutions to prevent this type of thing.  Actually, now I think about it, the only secure server is the one not attached to the network.  All you can do is have a box patched, all un-necessary services turned off and other security measures in place.  Or pick a 3rd party solution that meets your needs.  But an anonymous FTP server is not going to withstand a brute force attack without some other pieces in place to help protect it.  I can't speak to IDS systems because I have no experience.  Too bad FTP servers don't have some form of 'tarpitting' like mail servers can implement.  Maybe they do, but I'm not aware of a product implementing this feature. 

    Thursday, December 6, 2007 6:51 PM
  • User-2133191591 posted

    This is a tough issue especially if you are using FTP from IIS that was designed in like 1994 or around that timeframe.  Back then (yeah a whole 13 years ago) security wasn't the forefront of internet technologies.  If you say ANY FTP server should have it's own security, then you are mistaken. 

    There is no perfect answer from what I can tell, it takes a blend of various solutions to prevent this type of thing.  Actually, now I think about it, the only secure server is the one not attached to the network.  All you can do is have a box patched, all un-necessary services turned off and other security measures in place.  Or pick a 3rd party solution that meets your needs.  But an anonymous FTP server is not going to withstand a brute force attack without some other pieces in place to help protect it.  I can't speak to IDS systems because I have no experience.  Too bad FTP servers don't have some form of 'tarpitting' like mail servers can implement.  Maybe they do, but I'm not aware of a product implementing this feature. 

    "Tarpitting" is actually pretty accurate to describe this. A lot of FTP server software out there does have several settings to prevent brute forcing and resource hogging by temporarly blocking or slowing down connecting clients. The solution isn't that difficult (it's already been done with mailservers as you pointed out) and several FTP server software solutions out there that do just that. I'm a microsoft fan personally, and I guess I'm just curious why they chose not to implement these security features into IIS5, IIS6, and now IIS7

    Thursday, December 6, 2007 7:15 PM
  • User-2090102198 posted

    Hi,

     

    Ok if you need one third party software then use gene6ftp. It has all the features you need. But I think Microsoft should implement this also. 

     

    Friday, December 7, 2007 1:07 AM
  • User-1122936508 posted

    But an anonymous FTP server is not going to withstand a brute force attack without some other pieces in place to help protect it.

    Do you mean an FTP server that allow authentication rather than an anonymous server?

    It's very easy to defeat a bruteforce attack. Even with a known username (Administrator) a password with, say, 13 characters (from the keyspace A-Z, a-z, 0-9, special characters etc) would be completely unbruteforceable even locally using the fastest processors we have available today, without introducing the network latency involved in attempting a login over the network. You can't even get NTLM hash rainbow tables for >12 character passwords because (a) they haven't been calculated and (b) the storage requirements are immense (terabytes of required space)

    And then, introduce unknown usernames as well, and a bruteforce attack is unlikely to succeed.

    And then introduce a 1 minute delay every 3 attempts, and it's simply implausible for an attacker to brute force an account given any sort of decent password.

    What are we are left with is: (a) noise in the logs and (b) possible DoS against legitimate clients

    Cheers
    Ken

    Sunday, December 9, 2007 9:09 PM
  • User-2133191591 posted

    A one minute (or any period of time) block on IP after x number of failed attempts would be perfect. Why can't IIS have such a simple feature? And it would reduce a lot of log noise too.

    Monday, December 10, 2007 2:06 AM
  • User-2090102198 posted

     Hi,

     

    Ken it was good presentation all together but brute force attacks are generally done with dictionary attacks and they are successfully 2 out of 10. So there is no guarantee that having password length greater than 12 will save you. Moreover the dictionaries are customized for specific language and hence attack size will be reduced. So the concern over the bruteforce attack being stopped is right.

     Secondly I dont think that blocking the IPS will solve the purpose as there are seamlessly thousands of proxy Ip that can be used while attacking. So blocking one IP will not be beneficial as it will not contend the attacker. Attacker will not choose one ip to break the accounts.

     So security concern will remain the same even after enabling this feature. Security does depends on lots of things and much on the clients itself. Which is really difficult to guess.



     

    Monday, December 10, 2007 2:46 AM
  • User-1853252149 posted

    This thread got me thinking and I've looked at a bunch of FTP software to see what might have options for brute force rejection.  I don't really find any that are truly effective, on any platform.  With bot farms and distributed sources, none of the options really is adequate.  It's looking like only a combination of tactics will work well enough to discourage a brute force attack.  Account lockout policies combined with strong passwords seem to do pretty well at discouraging attacks.  If a brute force attack has three chances, then a five minute lapse on any account before it can try again, the length of time an attck would take is long enough that the attack is ineffective.  But this could end up in a DOS attack as the accounts get locked out.  IDS can easily stop rapid requests from a single IP, possibly even many requests from multiple IPs, but a well distributed attack on a system that normally would see a lot of activity is another matter.  Any effective rule would slow or block legitimate use. The best place to stop these attacks would be closer to the source, at the bot client or ISP.  But even though the technology is available, the expectation of it working is unreasonable.  The internet is too big and too unregulated for that to work.

    The stats that a brute force attack works 20% of the time are probably useless.  It may very well be that 20% of systems have weak security, common account names and simple passwords.  Dictionary attacks are far less effective with strong passwords.  But the one guaranteed solution is to eliminate passwords.  The secureID process provides rotating passwords in a token, if you don't have the token you can't get in and a brute force attack is ineffective.  But there are still problems with these systems.  Biometrics is an answer, but there are no solutions that don't use the biometrics to encode a password string, so there's still an attack surface.  And nothing aimed at FTP security of course.

    Pretty much, you'll just need to be okay with the adage that you don't need impregnable locks, just better locks than your neighbors.

    Jeff

    Monday, December 10, 2007 7:00 AM
  • User-2133191591 posted

    I agree, the chances of brute force actually working on a decently secure machine (no common accounts with common passwords) is nearly nill. Unfortunately, the log noise, network noise, and resource hogging remain an issue. You guys ever try to track down a legimitate hacker going through logs? It's almost always full of more hack attempts than legitimate use, and makes it hard to make sense of anything.  

    Every 12 year old geek with a computer tries at least once to install an ftp hacking program (or was it just me?). A machine that continues to respond after repeated hack attempts is more of a target... it's what hackers practice on. I have three ftp servers that have 4MB logs rather than 20k because of constant stream of login attempts.. and these are completely random servers (not published anywhere). I biggest concern isn't that one of the random users is going to get in, but that I will miss someone very determined that has been trying different things hiding in the crowd.

    As you pointed out Jeff, all you need to do is be better than your neighbor, and in this case, IIS FTP is by far not the right solution. Unless, of course, your neighbor is running IIS FTP with username/passwords like "administrator/password."

    This again goes back to me being a Microsoft fan who is just trying to find out why such simple features as temporary IP lockout after failed attempts aren't implemented in IIS. There has to be a reason for not adding in what seems to be a common and easy to make security option. It's like a word processing software not including the ability to bold text. If you find such a program, you can be damn sure there was a reason why they didn't include that feature.

     

    Monday, December 10, 2007 11:03 AM
  • User-2133191591 posted

    Does anyone from the IIS team actually read these posts?

    Monday, December 10, 2007 11:11 AM
  • User1073881637 posted

    Hi Ken,

    I agree with your additional methods to help lockdown an FTP server.  I'm talking about an 'anonymous' only FTP server.  If someone has a user id and password (with complex schemes), things should be ok.  I did some research and products such as CheckPoint firewall have methods to detect and block these kinds of attacks. 

    My only point is if we are picking on the built-in FTP service with IIS, it has not really been designed to stop brute force attacks.  That is where using policies you outlined would come in.   The IIS 7.0 publishing service supports FTP over SSL, which can help sure up so passwords are not sent in clear text.  Other solutions are to use FileZilla, WS-FTP secure server, GeneFTP6 types of products.  There are many FTP over SSL clients available, www.coreFTP.com, www.smartftp.com, FileZilla Client (posted on sourceforge). 

    The nice thing about the FTP 7.0 publish service is it appears to be extendable.  I'm not sure if you can implement an HTTP module type solution to keep track of IP's and block accordingly.  That might be a 'feature' request. 

    Monday, December 10, 2007 12:50 PM
  • User1073881637 posted

    There are members of the IIS team that participate in the forums.  They are very active in IIS community, in my experience anyway.

    Monday, December 10, 2007 12:56 PM
  • User-2133191591 posted

    I really want to hear what the IIS team has to say. I'm actually trying to figure out how I'm going to handle a few companies FTP needs in the next two years. If IIS FTP is going to be a viable solution really depends on whether it is something being focused on by the developers.

    There is good chance that Microsoft doesn't see FTP being a big part of new technologies, or maybe see IIS FTP used strictly for web publishing rather than any form of storage. I just want to know what to plan for.

    Monday, December 10, 2007 8:09 PM
  • User1138193213 posted

    Honestly speaking – I could have used what elk5432 is suggesting on my own server. I had one person actively attacking the FTP server on my home server over a couple days that I would have loved to have blocked. But for that matter, this guy changed IP addresses after a random interval of requests – so the net effect of blocking any single IP would have meant that the attacker would have simply needed to rewrite his attack scripts to get around my lockout time, which could be easily discoverable depending on the implementation. (e.g. Do you deny access for the IP or simply return a 530 error when an IP address is in "blocked" mode?)

    The great thing about my home server was - it was a public-facing FTP site where I only had anonymous enabled so the break-in attempts were effectively useless. Not everyone has that luxury, though.

    All that being said - blocking brute-force attacks from an IP seems a good idea, but it presents some interesting challenges. For example, what happens when you deploy FTP in an array of servers using shared configuration? The break-in attempts would be distributed across an array of servers, so just because ServerA wants to block the IP, ServerB and ServerC won't know anything about that since there's no shared state for login attempts. However, if an attempt is made to exploit user account with lockout settings configured then the IP address doesn't matter - the account gets locked out for the entire array and when the attacker changes IP addresses he's still prevented access. So the only sure-fire way to prevent access is to configure your account policies properly, which can be done using group policy in active directory.

    Please don't misunderstand me, I do think that this is a great idea and it's something that I want to investigate, but echoing others' comments on this thread I need to stress that this is not a complete replacement for good security practices.

    Tuesday, December 11, 2007 5:26 PM
  • User-2133191591 posted

    All that being said - blocking brute-force attacks from an IP seems a good idea, but it presents some interesting challenges. For example, what happens when you deploy FTP in an array of servers using shared configuration? The break-in attempts would be distributed across an array of servers, so just because ServerA wants to block the IP, ServerB and ServerC won't know anything about that since there's no shared state for login attempts. However, if an attempt is made to exploit user account with lockout settings configured then the IP address doesn't matter - the account gets locked out for the entire array and when the attacker changes IP addresses he's still prevented access. So the only sure-fire way to prevent access is to configure your account policies properly, which can be done using group policy in active directory.

    Hey Rob,
     
    The problem with using account policies is that you will end up with a lot of legitimate accounts locked out, and it doesn't give a reason for the hacker to stop beating on the server (he's not really wasting his time because he can hammer other accounts). An IP block on the other hand will probably result in a hacker to move on to target that doesn't waste as much of his resources. Something as simple as blocking an IP for 1 minute after three bad login attempts will result in a quick block of currently hammering IPs on all servers. Even in a distributed environment, a brute force attack as slow as two attempts a second would result in that IP being blocked on every server within a few seconds of being accessed. Log-wise alone, instead of having 120 entries for failed attempts on every server, per minute, it cuts it down to three.

    This leads me to the arguably even more important advantage.. being able to see real threats more clearly. If someone is so desperate to get into your FTP server that they make an effort to rotate IPs, the moment they start doing any real volume, it will stick out like a sore thumb in your now relatively clean logs, alerting you of a problem that you might have missed otherwise.

    I agree, nothing is ever going to replace good practices when it comes to security. Tools like a timed IP block are only part of the equation. I'm simply asking why such a tool is missing from IIS :)

    On that same subject.. is there anything in the pipeline for logs to expire? (I know I'm going on to something that should be a different post, but I can't help myself) I have a really great feature on my mail server software that automatically deletes logs older than a certain number of days. Amazingly useful for everyday management. These days more and more servers are being handled by fewer and fewer administrators.. self maintaining features like automatic clearing of a log older than x days (30 days usually), or notifications of server failure are unbelievably handy.  My mail server sends me an email when it thinks someone is trying to hack it, if it is having problems process (if restarting, it includes a data dump!), and maintains the last 30 days of logs. As someone who uses many management tools as well as SNMP, this still really makes my life a lot easier. Every month I have it my schedule to go through every server and delete old logs. Obviously this can be done with a easy script/program, but I feel it is something that belongs under logging options in IIS. Imagine being able to check a box to keep the last 30 days of logs. Many programs these days set a certain limit on the number of days of history or content to keep (including internet explorer as well as the operating system), why not do it for IIS?

    Oh man, I might have taken my monologue too far. Sorry.

    Eugene

     

    Tuesday, December 11, 2007 7:45 PM
  • User1073881637 posted

    Check out IISLogsLite.  It's a free program that I developed that does the exact thing you want, zip X number of days and delete files after X number of days.  It can do one or both.

    http://iislogs.com/download/IISLogsLiteSetup20.zip

    It requires the .NET framework, however that should be on most IIS servers.

    If you don't this option, there are free scripts available.

    Tuesday, December 11, 2007 8:18 PM
  • User-2133191591 posted

    Nice program!

    I'm aware of a few free scripts, I was only commenting that the option should be right under the logging tab in IIS :)

    I'm not one to say that every option out there should be built into IIS, there are enough features as it is. However, certain things are handy (strinctly in my opinion) enough that everyone is probably going to use them, and don't introduce unnecessary complexity into the code.

    Then again, who am I to say what is complex and not complex. I always hate it when my boss (non-I.T. exec) starts with "this is going to be easy..." rather than letting me figure out if it is.

    Tuesday, December 11, 2007 8:31 PM
  • User-2133191591 posted

    Just a quick bump to see if maybe an IIS engineer might be back after the holidays.

    Friday, January 4, 2008 7:56 PM
  • User989702501 posted

    Rob is from IIS team, to me this is not an technical issue - either ip blocking or account lock out, IIS team can deliver it within a short time (IMHO of coz). This is more toward finding the right balance and political stuff :)

    Sunday, January 6, 2008 11:18 PM
  • User-2133191591 posted

    Rob is from IIS team, to me this is not an technical issue - either ip blocking or account lock out, IIS team can deliver it within a short time (IMHO of coz). This is more toward finding the right balance and political stuff :)

     How do we stir up some grass roots support for this? The ol squeeky wheel gets the grease sort of nagging.

    Monday, January 7, 2008 1:40 PM
  • User989702501 posted

    I'm sure the product team is reading this, just becoz they work for MS sometime they are not allow to comment or make any statement in public before legal/xyz approval. Just like even they know the RTM date for W2k8, they can't say it.

    I would go for automatic ip blocking for this attack. yet if the traffic is massive, smarter IDS is needed.

    Monday, January 7, 2008 11:09 PM
  • User1073881637 posted

    There is a lot of things that can get the 'ole' squeeky wheel.   All things take time and priority.  I don't see this being a higher priority than say making modules for IIS 7.  If the IIS 7.0 publishing service doesn't meet your needs, I'm sure there is a 3rd party FTP service that might offer this type of thing.  That is where ISV (independent software vendors) fit.  Yes, it would be cool for this type of thing to be available or something we can program, all in good time.  As Bernard mentioned, an IDS solution is probably a good alternative.

    Monday, January 7, 2008 11:34 PM
  • User-2133191591 posted

    A year and a few months later I searching around to see if any modules are released that perform timed ip blocks based on authentication pass/fail find my own post.

    FTP 7.5 just came out, I had crossed my fingers hoping that the functionality would be in there. No such luck.

    Is there a roadmap somewhere on what the IIS team is working on for any of these modules?

    I wonder if third parties are holding off building modules for IIS7 because there is a chance microsoft will release the same functionality.

    Wednesday, May 6, 2009 6:41 PM
  • User989702501 posted

    Wow! elk5432 :) didnt' expect to see you here after two years.
    In Feb - Microsoft released dynamic ip restriction module :)http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/

    but it is for HTTP only, I did asked before if there's plan to support FTP and if I recalled correctly, MS was saying with the extensibility in 7.5, you can write your own !! or something like that.

    Wednesday, May 20, 2009 8:43 AM
  • User1138193213 posted

    I just published a walkthrough for the FTP service that shows how to create an authentication provider that gives you dynamic IP restrictions for the FTP service at the following URL:

    http://learn.iis.net/page.aspx/673/how-to-use-managed-code-c-to-create-an-ftp-authentication-provider-with-dynamic-ip-restrictions/

    That being said, you need to install the re-release of FTP 7.5 that came out on August 3rd, 2009, because that update resolves an issue with the FTP Log() method where the RTM version of FTP 7.5 was returning the incorrect IP addresses.

    Friday, August 7, 2009 4:57 PM
  • User-2133191591 posted

     Was looking for FTP/WebDav dynamic IP restriction, accidentally came across my own post :) Still can't find what I'm looking for.

    I'm a bit torn on the "DIPR" module because what really matters is bad login attempts (whether it be WebDav or FTP). DIPR addresses the DDOS issue more than it does brute-force/general login hacking attempts. I never really had an issue with DDOS, because they either took my server down completely (flood network pipe) or didn't have enough volume to do any real damage to the site. Not to mention I would be hard pressed to figure out just the right settings that would stop DDOS but not block legitimate HTTP traffic on a very active web server. At least in my case, there source of the DDOS was tens of thousands of IPs, and while they were definitely behaving differently that regular HTTP users, it would still be a pain to tweak the settings to block them.

     Still think FTP needs it's own tarpitting / failed login IP blocking settings. And now that I'm more actively using WebDav, running into the same problem on that front as well.

     

     

    Sunday, August 14, 2011 4:04 PM
  • User989702501 posted

    Yo. welcome back after 4yrs plus !!! agreed on the DIPR part it is meant for heavy traffic target. and I'm still think that for ftp, any good decent firewall or ids should do the job. I'm not sure how heavey is your brute-force ftp traffice per day... is it so huge that take up 50% of your bandwidth?

    I mean in real life today, if I'm going to deploy one sql server with 1433 open to then. guess what in less than 24hrs, I will get lot of failed attempt on sa' login. Same for ftp, either anonymous or valid user. I maybe luckier, coz most of my ftp are meant for internal, so proper firewall access /etc are in place, not so much of headache. I do have few public ftp, these are purely for file access, special isolated within the dmz zone, and yes! many traffic to attempt login/etc. but we didn't pay much attention to it. it is not like fully cordinate attack that can bring down the entire pipe, and of coz very annoying log entries when you try to find something you need. since last year is much better, I told the firewall guy that 'hey, can you do something about these junk traffic', i'm didn't ask for the details, but i'm sure he turns on some smart defence stuff to lower the noise and we had not hear any complaint from valid user as well. so life is quite good for that setup now :)

    To me there are certain thing you can handle at app protocol level, for many others network layer or lower it is still the best. that's just my opinion.

    Sunday, August 14, 2011 11:47 PM
  • User1138193213 posted

    I posted an FTP extensibility sample some time ago that was intended to be a stop-gap measure for preventing brute-force attacks over FTP, while behind the scenes we were working on a built-in version. With that in mind, I wanted to everyone know that we now have a brute-force prevention feature built-in to the FTP service for Windows Server 8. This feature is called FTP Logon Attempt Restrictions, and more details are available at the following URL:

    http://learn.iis.net/page.aspx/1094/iis-80-ftp-logon-attempt-restrictions/

    If you'd like to try out the feature, you can download the Windows Server 8 Beta from the following URL:

    http://www.microsoft.com/en-us/server-cloud/windows-server/v8-default.aspx

    Saturday, March 3, 2012 12:29 AM
  • User989702501 posted
    Hoho.. after 5 yrs :) still... better than late then never.
    Sunday, March 4, 2012 5:50 AM
  • User-2133191591 posted

     Any plans on bring this functionality to IIS 7.5 or allow windows 2008 r2 servers to upgrade to iis8?


    Monday, March 5, 2012 10:32 AM
  • User989702501 posted

    Second that.... would love to see it as another out of band component that can deploy on IIS 7 onward.

    Monday, March 5, 2012 10:53 PM
  • User-376128307 posted

    I see new product named E-Guardo on the web. They says their product stops brute force and dictionary attacks for RDP, MSSQL, FTP, SMTP, IIS, Microsoft CRM, SHAREPOINT, LYNC SERVER and many others. I am trialing product and it seems very professional.

    Also they are giving free black list API over xml webservices. I think you should try this one.

    http://www.eguardo.com

    Friday, January 11, 2013 9:11 AM
  • User-901261979 posted

    After searching high and low.. I finally found the best product to take care of brute force attacks in Windows 2008 (IIS 7/7.5) without waiting for Windows 2012 on my Plesk Windows hosting servers.  It’s called CyberArms which can be found at http://ww.cyberarms.net

    They charge $199.99 per server, but you own the software.   It works with your firewall and automatically blocks for invalid login attempts that you can configure.  It protects the following:

    Outlook Web

    Microsoft FTP

    SQL Server Login attempts

    Remote Desktop attempts.

    What I can tell you in evaluating the software is that the company is a Microsoft Partner, so it has been well tested.  They are also going to be releasing additional modules for SMTP in the future.  It uses hardly any CPU at all.  On my first hosting server, I already have over 200 IP’s blocked in a week from attempts to FTP brute force in.  I also like that fact that it doesn’t have tons of overhead with fancy maps, and un-needed “junk”, since in my mind – I don’t need all that on the server, I just needed something that just works…. Nothing fancy.  Check them out!

    Tuesday, February 5, 2013 11:56 AM
  • User42427535 posted

    Hello ,

    Why to pay 199 $ if we have people who contributes to make such application for free of use.

    Just check at http://cskatta.co.in/index.php/2013/01/29/blocking-ftp-brute-force-attack/

    This is enough to block such attack

    Tuesday, February 5, 2013 1:27 PM
  • User-901261979 posted

    Because honestly, I don't have time to figure out what that does right now.  In fact, the thread is not even in proper english, and there is no documentation on what it actually does... so ... the $199.99 is an insurance policy on my server, and it's a one time price - enough said.

    Sadly, if it could have been written, then why isn't it in IIS to begin with?

    the $199 is totally worth my time, bandwidth, aggravation and updates.

    Tuesday, February 5, 2013 6:17 PM
  • User1138193213 posted

    Thanks CavalloComm, that's not a bad solution, but as I pointed it out earlier in this thread that the FTP service in IIS 8 has a built-in brute-force prevention feature in the FTP service for Windows Server 2012; this feature is called FTP Logon Attempt Restrictions, and more details are available at the following URL:

    http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-ftp-logon-attempt-restrictions

    That feature isn't available for the FTP service in IIS 7.5, but we added extensibility in that version, and I posted an FTP extensibility sample that was intended to be a stop-gap measure for preventing brute-force attacks over FTP while we were working on a built-in version. That is available at the following URL:

    http://www.iis.net/learn/develop/developing-for-ftp/how-to-use-managed-code-c-to-create-an-ftp-authentication-provider-with-dynamic-ip-restrictions

    (Note: You needed to install the re-release of FTP 7.5 that came out on August 3rd, 2009, because that update resolves an issue with the FTP Log() method where the RTM version of FTP 7.5 was returning the incorrect IP addresses.)

    Wednesday, February 6, 2013 12:47 AM
  • User1138193213 posted

    If you can't upgrade to IIS 8 and you don't want to use the FTP extensibility features in IIS 7.5, you can also use LogParser to determine IP addresses that are attempting to log into your server too many times and use that information to prevent them from accessing your server. There are many ways to accomplish this, but the following example will create a file with a list of IP addresses that have failed to access your server more than a certain number of times per day and a specified number of days total:

    @echo off
    
    set MAXDAILYFAILURES=10
    set MAXTOTALFAILURES=1000
    
    if exist _ban_hackers.tsv del _ban_hackers.tsv
    if exist _ban_hackers.txt del _ban_hackers.txt
    
    for /f "usebackq delims=|" %%a in (`dir *.log /b`) do logparser "SELECT c-ip, COUNT(*) INTO _ban_hackers.tsv FROM '%%a' WHERE cs-method='PASS' and TO_STRING(sc-status)='530' GROUP BY c-ip HAVING COUNT(*)>=%MAXDAILYFAILURES%" -i:w3c -o:tsv -headers:off -fileMode:0
    
    logparser "SELECT DISTINCT Field1 INTO _ban_hackers.txt FROM _ban_hackers.tsv GROUP BY Field1 HAVING SUM(Field2)>=%MAXTOTALFAILURES%" -i:tsv -o:tsv -headers:off -fileMode:1 -headerRow:off
    
    set MAXDAILYFAILURES=
    set MAXTOTALFAILURES=

    Once you have the list of IP addresses, you can do anything you want to block them. For example, the above sample is an excerpt from a much larger sample that I wrote some time ago that I keep meaning to turn into a blog. I'll get around to finishing that blog one of these days, but in the meantime - you can add the following sample to my earlier sample to add the IP addresses to the list of FTP IP restrictions:

    for /f %%b in (_ban_hackers.txt) do (
    pushd "%windir%\system32\inetsrv"
    appcmd.exe set config -section:system.ftpServer/security/ipSecurity /-"[ipAddress='%%b']" /commit:apphost>NUL
    appcmd.exe set config -section:system.ftpServer/security/ipSecurity /+"[ipAddress='%%b',allowed='False']" /commit:apphost
    popd
    )

    You can easily automate that batch file to provide similar functionality to the program that you mentioned and save yourself the cost of a third-party application, and you can also replace the lines of code that add the IP addresses to the FTP restrictions to add the IP addresses to something else, like the IPSEC example that $Niraj$ was suggesting.

    Wednesday, February 6, 2013 12:53 AM
  • User34527776 posted

    $Niraj$

    Hello ,

    Why to pay 199 $ if we have people who contributes to make such application for free of use. Just check at http://cskatta.co.in/index.php/2013/01/29/blocking-ftp-brute-force-attack/ This is enough to block such attack

    How did you get that script working. I got it running but then it does not add the IPs into the firewall rule from the log file.

    Thursday, July 4, 2013 9:08 AM
  • User42427535 posted

    Hello ,

    If you have not created Firewall rule then you will need to create one.

    This can be done by executing below command.

    netsh advfirewall firewall  add rule name="Block External IP" dir=in  remoteip=10.10.10.10 action=block

    Then download the executable file and place it under  c drive.

    You can test it by executing ftpattackblocker.exe to check if it works or not.

     Output will look like this >>

    C:\>FTPAttackBlocker.exe 9999999
    Microsoft Windows 7 Ultimate
    Current Sytem Time :7/4/2013 8:16:37 PM
    FTP server Version: 7.5.7600.14294
    Name : FTP1 2
    Logfile Path: C:\inetpub\logs\LogFiles\ftp1\FTPSVC2
    Recent Logfile: C:\inetpub\logs\LogFiles\ftp1\FTPSVC2\u_ex130127.log
    Parsing Logfiles
    Name : FTP2 3
    Logfile Path: C:\inetpub\logs\LogFiles\ftp2\FTPSVC3
    Could not find a part of the path 'C:\inetpub\logs\LogFiles\ftp2\FTPSVC3'.
    Recent Logfile: No Files found
    netsh.exe advfirewall firewall set rule name="Block External IP" new remoteip="1
    0.10.10.10"
    
    Updated 1 rule(s).
    Ok.

    Application accept 1 argument as number of minutes  which will used to check log entries for recent n number of minutes.

    By default it will check log file for previous 30 minutes. It will check log file entries records for a day(24 hours)

    It shows the log files which was traversed by application.

    It will also shows command output with list of ips to block in command prompt.

    If all works perfectly then you can schedule the exe to run after 30 minutes to check log files for new attacks.

    If you experience any issue then let me know and provide the screenshot of command output so I can help you to resolve it.

    Regards,

    Niraj

    Thursday, July 4, 2013 11:02 AM
  • User2099496241 posted

    Here is a very simple FTP 'tarpitting' script that works on Windows 2003 / IIS6, maybe others.
    First create a 'resetftp.bat' file in 'c:\scripts\' (or modify the command line below to match your path)...include the following in your batch file:

    net stop msftpsvc
    ping -n 5 127.0.0.1
    net start msftpsvc

    Once you have created the batch file, go to a command prompt and run:

    eventtriggers /create /TR "Reset FTP Service" /TK C:\scripts\ResetFTP.bat /L System /EID 100 /SO MSFTPSVC /RU "system"

    Credit to http://mymcp.blogspot.com/2008/03/tarpitting-iisftp-service.html

    HTH.

    ***j

    Wednesday, November 13, 2013 12:56 PM
  • User-1122936508 posted

    Here is a very simple FTP 'tarpitting' script that works on Windows 2003 / IIS6, maybe others.

    Stopping the whole FTP service? Seems like this exposes a very simple way for me to launch a DOS at your FTP server then...

    Thursday, November 14, 2013 2:27 AM
  • User2099496241 posted

    Stopping the whole FTP service? Seems like this exposes a very simple way for me to launch a DOS at your FTP server then...

    That is one potential problem, of course, but, generally the point of a FTP brute force attack is to get into the server...if it's not available, or if the service stops just long enough to kill your bot or script...it serves the purpose.  It's just one angle to consider, and no doubt could be tweaked to work better and/or to be more exclusive in how is blocks attacks.

    Thursday, November 14, 2013 2:42 AM
  • User-1122936508 posted

    That is one potential problem, of course, but, generally the point of a FTP brute force attack is to get into the server...if it's not available, or if the service stops just long enough to kill your bot or script...it serves the purpose

    Sure. But the point of security is:
    Availability - service is available to authorised users (that's why DOS attacks compromise security)
    Confidentiality - only data that users are authorised to access is available
    Integrity - data available is correct and not compromised

    This fails the first item on the list. Better implementation of tarpitting would only block IPs where a failed logon has occured - not DOS everyone else.

    To be perfectly honest, account lockout is a simpler and better way to block brute force unless you have a very small FTP environment.

    Thursday, November 14, 2013 6:20 AM