OCS RAS authentication - is it secure ?

Gesperrt OCS RAS authentication - is it secure ?

  • Freitag, 24. Oktober 2008 17:19
     
     

     

    I have a question related to the RAS authentication process on OCS.

    OCS 2007 Access Edge and Clients don’t support 2 factor authentication.

     

    To stop brute force password guessing, is there a way that a filter could be built into the authentication process on RAS connections?

    As I know the TLS protocol is encrypting the packets from the client to the edge and further to the OCS front end pool, where the pool or director is sending NTLM authentication request to the Active Directory, there is no way of an IDS system to watch the content of the packets and stop abnormal authentication retries/guessing scripts.

    I guess a password guessing C# script could use the API to brute force with password guessing, and could possible lock down the user accounts in AD when to many attempts are done within set time intervals.

     

    How to stop it ?

     

    For.example

    Could there be an OCS access edge filter looking at the authentication packets passing thru, SIP address, logon name and filter for bad attempts, and count them?

    If too many authentication attempts are found within a time interval(ex. 1-2 minutes) from same IP and with same SIP account or different accounts, block the client IP for some time to stop it ?

    Abnormal authentication retries should be stopped.

     

    We have many customers that are concerned about this possibility.

     

    Will TLS time out a C# script like this?

    Is Group Policy the last security protection to stop to many remote authentication request with OCS clients ?

     

    As sip names are known, hackers could guess logon names and passwords, and then it is just to make the script auto run in loops.

    If they get in, the can impersonate an internal user.

     

    Any answers to this issue or explanation, would be great.

     

    Thank you.

     

    Best Regards
    Hans Uleberg,
    Technical Principal ICT Engineer

    ErgoGroup AS
    P.O. Box 4364 Nydalen, 0402 Oslo, Norway 
    Cell Phone.
    +47 99 55 99 56
    www.ergogroup.no  

Alle Antworten

  • Sonntag, 26. Oktober 2008 13:57
     
     
    I am not much of a developer but when I looked at the OCS Server SDK I saw some properties such as "AuthenticationInfo" which I guess you could use in a custom application.

    On the other hand your problem could be resolved by deploying more advanced firewalls that will "bridge" the MTLS connection and can investigate what's being requested in the SIP headers. There are plenty of SIP firewalls out there but I don't know if they can help prevent the account lockout issue.

    SIP Firewalls: http://www.sipcenter.com/sip.nsf/html/Firewalls+Security

    Also these are "generic" SIP Firewalls and they may or may not support OCS !! Furthemore there is a negative advice from Microsoft on using DPI firewalls as shown below:


    with Office Communications Server?
    Will DPI Firewalls Work


    No, deep packet inspection (DPI) should not be used with Office Communications Server. Not only can DPI affect the quality of voice over IP (VoIP) communication by increasing latency, but recent studies have questioned whether any security advantage of DPI justifies the resource costs of its inclusion in the perimeter network.DPI inspects layers 2 through7 of the OSI model; that is, not just the headers, but also the data protocol and message payload. DPI then determines how to identify, classify, and forward traffic by comparing data from the packet to a signature database. This process is considerably more costly in computing terms than analysis of packet headers only, particularly when it occurs at wire speed.In addition, DPI may trigger a number of recognized risks on available DPI hardware. For a discussion of specific vulnerabilities, see Thomas Porter’s article The Perils of Deep Packet Inspection on the SecurityFocus Web site.

    As a security option, DPI is not yet mature. It adds unnecessary complexity and impedes the quality of VoIP.

    <source: OCS 2007 Perimeter Network Whitepaper>

    Another approach would be to have your client first authenticate using dual-form authentication in the form of a SSL VPN. Once this VPN has been established all services would become available for your users.

    Until Microsoft supports dual-form authentication across their operating systems and applications this topic will always be a though one to solve.

    Sincerely,
    Tonino Bruno