none
Denial of Service/Brute Force protection via the Director Role RRS feed

  • Question

  • Hi there,

    I'm designing a Lync deployment, and have a question about what protection the Lync Director role affords the internal AD environment. Specifically, does it include the ability to prevent DoS/Brute force attacks against the internal Active Directory?

    The TMG publishing rules are configured to pass the authentication request straight through to the Director server (and to the Front End server as well), which means 3rd party ISAPI filters like Lockout Guard (http://www.collectivesoftware.com/Products/LockoutGuard) can't be used to provide this protection, and must rely on the server being published - in this case the Lync Director... and possibly the Front End servers as they're also published.

    I know the Lync Edge has a seperate filter by Rui Maximo that seems to provide a similar capability for the Edge services... but I'm uncertain how the Director manages this.

    Rui has the following to say about the Director:

    The Director in this scenario behaves differently than in the internal user scenario. The Director offloads the task of authenticating the user and proxying the request to the correct pool. The Director serves as a buffer against attacks originating from the Internet. If a DoS attack was mounted, the Edge Server and Director would be under fire; however, the internal pools would be isolated and protected from such attacks.

    Would this stop an external user brute forcing the internal AD accounts database and potentially causing a DoS by locking all the internal accounts out?

    Regards, James.


    James Frost
    Monday, December 19, 2011 6:54 AM

Answers

  • Yep, as the TMG is not doing any auth, requests would be passed straight to the Director pool/FE pool.

    Given that the Lync Web Components runs on IIS on the Director/FEs, any protection against DoS attacks (whether it's what IIS provides out of the box or a 3rd party app) could be employed here.


    Justin Morris | Consultant | Modality Systems
    Lync Blog - www.justin-morris.net
    Twitter: @jm_deluxe
    If this post has been useful please click the green arrow to the left or click "Propose as answer"

    Friday, December 23, 2011 5:52 PM
  • Fabian Kunz brought this email discussion to my attention. As mentioned, the security filter only protects the SIP traffic. Because it's installed on the Edge Server, and the HTTPS traffic traverses the reverse proxy directly to the Director and FE web services, the security filter is not in the path of this HTTPS traffic. If you would like to read more about the security filter, Fabian Kunz helped develop documentation for the security filter. You can find it and the security filter here:

    http://tinyurl.com/security-filter

    To address the issue of protecting the web (HTTPS) traffic from DoS attacks, I'm currently in the process of developing a web security filter for Microsoft ForeFront TMG. The objective is to enforce the same logic as the security filter with one additional benefit. I will integrate the Lync security filter with the TMG web security filter so that the two filters share the same lockout information as an integrated solution.

    Feel free to reach out to me at rui AT maximo.ws if you would like to test out the web security filter when I get it done.

    rui

    • Marked as answer by James Frost Tuesday, January 24, 2012 6:58 AM
    Sunday, January 15, 2012 7:12 PM

All replies

  • Hi James,

    Based on the design of Rui's filter for the Edge Server (detailed here), it can provide the following functionality to protect against AD account lockout:

    "When either the internal pool or the Director sends the authentication response to the Edge Server, the security filter captures the REGISTER response. If the sign-in failed, the security filter increments the count of failed attempts. If the sign-in succeeds, the security filter resets the count of failed attempts to zero.

    Every time the Edge Server receives a sign-in request, it is passed to the security filter. It checks whether the sign-in request has exceeded the maximum allowed number for the particular user account. If the request has not exceeded the maximum lock-out count permitted, the security filter allows the request to continue its course to either the internal pool or the Director. If the request exceeds the maximum lock-out count permitted, the security filter blocks the request, and returns a 403 response. This rejects the request. Any further sign-in attempts are rejected for the duration of the lock-out period. After the lock-out period expires, it is reset to allow new sign-in requests to be authenticated."

    This would effectively safeguard against failed sign-in attempts from locking out AD accounts. 

     


    Justin Morris | Consultant | Modality Systems
    Lync Blog - www.justin-morris.net
    Twitter: @jm_deluxe
    If this post has been useful please click the green arrow to the left or click "Propose as answer"


    Tuesday, December 20, 2011 4:24 PM
  • Hi Justin,

    Sorry, I should have been more descriptive. It certainly sounds like the Director will provide the neccessary protection for Edge -> Director traffic via Rui's filter... which is great.

    However, my question was with regards to HTTPS traffic (Lync address book lookups etc) from Client -> TMG -> Director. Considering Rui's filter is located on the Edge - and plays no part in this traffic flow - is there any inherent protection in the Director to prevent failed sign-in attempts from locking out AD? Typically I'd look to TMG to provide this protection, but because the publishing rules are configured to pass the authentication attempt directly to the Director ("Authentication delegation: No delegation, but client may be authenticate directly"), I don't see how TMG can help in this regard?

    Thanks for taking the time to respond.

    Regards, James.


    James Frost
    Tuesday, December 20, 2011 10:06 PM
  • Yep, as the TMG is not doing any auth, requests would be passed straight to the Director pool/FE pool.

    Given that the Lync Web Components runs on IIS on the Director/FEs, any protection against DoS attacks (whether it's what IIS provides out of the box or a 3rd party app) could be employed here.


    Justin Morris | Consultant | Modality Systems
    Lync Blog - www.justin-morris.net
    Twitter: @jm_deluxe
    If this post has been useful please click the green arrow to the left or click "Propose as answer"

    Friday, December 23, 2011 5:52 PM
  • Thanks Justin (apologies, I've been on holidays),

    I’ve stumbled across the IIS 7 Dynamic IP Restrictions module (http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/ ) which sounds like it will go a long way to providing the desired protection against DoS/brute forcing of internal AD accounts. This would provide some protection at the internal IIS layer and not TMG, but it’s better than nothing…

    … the problem is that everything I’ve found about the module would suggest it’s in Beta, even though it’s a couple of years old. I've asked Microsoft seperately to clarify what the situation is with this module, whether it’s ever to go RTM, and whether they'd support it.

    I'll post their response.

    Update: Microsoft have confirmed their is no official release date for the final version of the IIS 7 Dynamic IP Restrictions module (Sigh)

    Regards, James.


    James Frost

    • Edited by James Frost Tuesday, January 24, 2012 6:58 AM
    Tuesday, January 3, 2012 2:05 AM
  • This is actually a very good point. As I have been wondering why there are so big pressure from the MS to deploy the directory (especially for the single pool installation) when you have direct line from outside to your FE's IIS service. I really like to see, that in a future there are single entry point for the external users and all protection is from that point till FEs.
    Petri
    Tuesday, January 3, 2012 11:05 PM
  • Fabian Kunz brought this email discussion to my attention. As mentioned, the security filter only protects the SIP traffic. Because it's installed on the Edge Server, and the HTTPS traffic traverses the reverse proxy directly to the Director and FE web services, the security filter is not in the path of this HTTPS traffic. If you would like to read more about the security filter, Fabian Kunz helped develop documentation for the security filter. You can find it and the security filter here:

    http://tinyurl.com/security-filter

    To address the issue of protecting the web (HTTPS) traffic from DoS attacks, I'm currently in the process of developing a web security filter for Microsoft ForeFront TMG. The objective is to enforce the same logic as the security filter with one additional benefit. I will integrate the Lync security filter with the TMG web security filter so that the two filters share the same lockout information as an integrated solution.

    Feel free to reach out to me at rui AT maximo.ws if you would like to test out the web security filter when I get it done.

    rui

    • Marked as answer by James Frost Tuesday, January 24, 2012 6:58 AM
    Sunday, January 15, 2012 7:12 PM
  • Hi Rui,

    Thanks for taking the time to respond.

    Can you clarify how your solution will differ from a product like Lockout Guard?

    Also, considering that TMG doesn't actually provide the authentication in the Lync publishing scenario, and it's instead delegated to the Lync Front-end, can you elaborate on how your filter would provide the necessary protection?

    Thanks. James.


    James Frost
    Monday, January 16, 2012 3:13 AM
  • hi James,

    My pleasure. My apologies for the late reply. I didn't get a notification that you had posted a reply.

    I'm not familiar with the Lockout Guard product. So, I can't comment on it.

    In terms of how the web filter I'm building for TMG would function, I recommend you contact me privately.

    best regards,

    rui

    Tuesday, January 24, 2012 3:55 AM
  • Thanks Rui,

    I've confirmed with Captivate, the makers of Lockout Guard, that their product can only provide protection when TMG is doing the authentication - not when it's passed through to an internal server, as is the case with the Lync publishing scenario.

    I'll contact you seperately to discuss your security filter.

    Thanks. James.


    James Frost
    Tuesday, January 24, 2012 6:56 AM
  • Hi, i hope the discussion regarding this topic hasnt been abandoned in the lst 6 months, as I am actively interested in this topic as well :) A little bit offtopic duscission follows: My new customer is deadly afraid of getting all their 5000 users locked out in a huge brute force attack against the Lync system. I wanted to reply, that unfortunately Lync out of the box does not have any kind of protection against brute force account lockouts, and wanted to give an example of Exchange2010 and OWA, as it does not have that kind of protection either. However, as i did not find any clarification about this topic (either MS to confirm the lack of bruteforce protection, or confirm that TMG indeed does protect OWA via the web publishing) I would like to ask it here: CAN tmg (or Exchange2010) out of the box(!) protect OWA users against bruteforce account lockouts, or not? If it is possible via 3rd party either on TMG or on Exchange side, pleast let me know this as well. Thanks!
    Saturday, July 7, 2012 8:08 AM
  • Hi Richard,

    So just so I'm clear, your question is whether Exchange 2010 and OWA provides brute force protection (which you can then cite as an example when discussing the Lync publishing scenario via TMG)?

    In my experience, there are some crucial differences when publishing the two systems which does put the Exchange/OWA scenario ahead of Lync in my opionion (from a security perspective). Firstly, if you have any remote access token based infrastructure (ie. RSA SecureID) you can you can use a combination of forms based authentication and username/password/one-time-password to enforce multi-factor authentication at the perimeter (TMG) with OWA. In this scenario, it would be difficult to brute force any logon attempts as the randomly generated OTP would prevent this, and crucially any authentication attempts are first offloaded to TMG and not to the internal infrastructure.

    If you don't have any token based security infrastructure, and just want to deploy OWA with username/password, you can still get a prevention from brute-force DoS attacks by installing Lockout Guard which I mentioned at the top of the post. This is an effective little ISAPI filter which sits on the TMG server and monitors auth attempts, blocking them from DoS'ing your internal Active Directory once they reach a pre-defined threshold. I've used this tool before, and it performs exactly as advertised. Unfortunately, it works in this scenario because the authentication attempt is being performed by TMG.

    In the Lync publishing scenario via TMG, the authentication attempt is instead passed straight thru to the Lync Front End/Director servers, meaning Lockout Guard is rendered useless (I've confirmed this with the vendor).

    As far as I'm aware until Rui releases his web security filter for Microsoft ForeFront TMG, I don't think this hole will be blocked any time soon. Personally, we've accepted the risk and moved on (most companies do), but it would be nice to see it addressed by Microsoft or a 3rd party.

    Regards, James


    James Frost


    Tuesday, July 10, 2012 1:01 PM
  • Hi James,

    thanks for the clarification. Yes, I was especially interested in out-of-the-box bruteforce-protection capabilities of TMG, which it turned out simply does not exist, as it requires 3rdparty. As far as Lync is concerned, I do really expect MS is DOING SOMETHING official solution regarding the FE-IIS and edge server brute-force protection, as I wouldnt want to depend on unsupported 3rd parties (developed by Rui in this case, dont get me wrong thats a clever creative product, but still a 3rd party and AFAIK not free).

    But as I usually have bad experience regarding feature-requests handled by the mammoth MS (requests actually not handled at all and flushed down on the toilet...), I am like 99% sure this protection wont be ever put into the Wave15, and at the end of the day I would indeed rely on 3rd party developed by semi-independent enthusiasts and hacked into the system at the cost of getting unsupported deployments.

    Tuesday, July 10, 2012 11:25 PM
  • hi Richard,

    As James mentioned, the Lync web authentication traffic is passed through TMG to the internal Lync Server. fyi. I just completed the Security Web Filter for Forefront TMG 2010, which protects against DoS attacks on user accounts for all Lync web traffic. This includes Lync 2010, browsers (IE, Firefox, Chrome) connecting to the simple URLs, and Lync Mobile (WP, Android, iPhone, iPad). Note that each client authenticates to Lync Server's external web services in a slightly different way.

    Saturday, July 28, 2012 2:36 PM