Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

Friday, March 13, 2015

The Case of the Lync 2013 Edge Server Centralised Logging Ports

If you have ever done any port testing on a Lync 2013 Edge server you may have noticed that the external interface of the Edge server had ports in the 50001-50003 range open and listening for TCP connections. Usually this is not the case in the 50000-59999 media range because these ports are only opened for short periods of time when media ports have been allocated by the Edge server for active calls. The Media Relay Service on the Edge was designed this way for security purposes, so that the 50000 range could be opened on external firewalls without posing a significant security threat. So what are the undocumented 50001-50003 ports facing externally? Well, they are actually the Centralised Logging Service and they appear to be facing externally for no reason other than they are bound to port 0.0.0.0. The netstat command show this:

ClsAgent.exe Ports


The netstat output shown above shows that the ClsAgent.exe service is listening on the 50001, 50002 and 50003 ports on the IP Address “0.0.0.0”. This means that the service has not bound to any specific interface and as a result will listen on all interfaces. I image this is a design issue with the CLSAgent because it was originally designed to run on internal Lync servers that only had one interface and so binding to a specific port wasn’t a requirement at the time of designing the software. I’m happy to be told different by someone at Microsoft though…

As mentioned earlier, the CLS port range falls into the TCP 50000-59999 range, which is also legitimately used for Edge Media Relay service. So it is included on the list of external port ranges that may be open on the external firewall. I say may be opened because this range of TCP ports does not need to be opened inbound (as per the guidance from Microsoft) unless you are federating to OCS 2007, or in the more complex scenario when you are using NATing with DNSLB on the external edge and your firewalls do not support hairpinning (ie. traffic coming from one Edge server’s NATed external public IP address back in to another Edge servers NATed External Public IP address) of media between multiple edge servers in the same pool. Another legitimate reason for this is when you want an optimised media path that does not require tunnelling via port 443/3478 to get to the required 50000 range media port. These scenarios were explained in a great amount of depth by Bryan Nyce and Thomas Binder at LyncConference 2014. I suggest you watch these videos several times if you don’t understand what I’m talking about here.

'So what percentage of companies actually open the 50000 range of ports to the internet?' I hear you asking… Well, I also wondered this, so I decided that I might do some research and find out. I tested approximately 250 Edge servers of some of the largest organisations in the world and found that approximately a quarter of them have the 50000 range open (with CLS ports showing). So quite a large number of organisations currently have this issue.

The actual security implications of having these ports open on the Internet is not fully known at this stage. The existing ClsController.exe application and CsCls Powershell commands supplied with Lync do not allow the user to connect to servers outside of the Lync pools within their installation. So it's certainly not the case that you can use them to randomly connect to other organisations' Edge servers and start logging service. It's my understanding that Microsoft is aware of this issue and have not yet done anything to change the behaviour, so they obviously have deemed it low risk. In my opinion though, the reduction of attack surface is always a good idea for internet facing services. So my recommendation is to block these ports because they serve no practical function externally.


A Work Around


I have written a Powershell script that will block the CLS service ports on selected interfaces of your Edge server. This will function as a work around until Microsoft decides to formally change this behaviour in the product.

When you run the script it will display a list of IP Addresses on the server that you can choose to block the CLS service on. You simply need to enter the number of the interfaces in the list that you would like to block access to the CLS ports on. The script will then automatically create a new firewall rule to block TCP ports 50001-50003 inbound on the selected IP Address to the CLSAgent service on the machine. Follow this process for all externally facing Edge IP Addresses (ie. Access Edge, AV Edge and Conferencing Edge IP Addresses).

BlockCLSExternalEdgePorts1.00

The rules that are added can be seen in the Advanced settings of Windows Firewall in the system Control Panel:



Once you have done this for all of your Internet facing Edge IP Addresses you can rest easy: your Edge is now as safe as you previously thought it was…




Note: Run Powershell as Administrator when running the script.

The Wrap Up


Security is important and we all need to try to understand what we are asking when we tell the firewall team to open internet facing firewall ports. Whether you are deploying a new Edge server or already have an Edge server out in the wild, then I suggest you implement my firewall work around. Enjoy and see you next time. Ciao!



Read more →

Friday, October 24, 2014

When Poodles Attack - Poodle Checker Tool


It’s not too often you get to be excited about a security threat. However, the POODLE security threat seems to put a smile on my face every time I see it written somewhere… Poodles are just so innocent and ridiculous looking to take seriously as a major threat. So in a bid to take this security issue more seriously, I have built a Powershell tool for remotely checking servers for having either SSL 2.0 or SSL 3.0 enabled on them.


More Detail on the POODLE threat


Here are some links that explain the POODLE threat in a little more detail:


POODLE Checker Tool


  • The tool will try and connect using SSL 2.0 and SSL 3.0 to any server FQDN/IP and port (multiple ports can be entered with a comma separating them) you enter.
  • Press the Test button and it will check all the ports in the ports text box. The tool will report in the Powershell window which ports have SSL 2.0 and SSL 3.0 running on them.
  • The tool will also visually display the results…
  • Script is signed.

Update 1.01
  • Added additional checking of TLS (1.0, 1.1, 1.2) protocols so you can better understand all the TLS connection options available on the server before deciding to disable SSL. 
Update 1.02 (16/2/2015)
  • Added the ability to handle multiple comma separated IP Addresses/DNS Names.
  • Added Cancel button to stop testing.
  • Disabled text boxes during testing phase.
  • Textboxes now stretch when resized.

      Download Version 1.02:



      Standard SSL Port Numbers


      SSL can technically run on any port that you configure and application to use. However, the well-known port numbers for applications that use SSL (as defined by IANA, and IETF) are listed below:

      Protocol
      Port
      Description
      nsiiops
      261
      IIOP Name Service over TLS/SSL
      https
      443
      http protocol over TLS/SSL
      ddm-ssl
      448
      DDM-SSL
      smtps
      465
      smtp protocol over TLS/SSL
      nntps
      563
      nntp protocol over TLS/SSL
      sshell
      614
      SSLshell
      ldaps
      636
      ldap protocol over TLS/SSL
      ftps-data
      989
      ftp protocol, data, over TLS/SSL
      ftps
      990
      ftp, control, over TLS/SSL
      telnets
      992
      telnet protocol over TLS/SSL
      imaps
      993
      imap4 protocol over TLS/SSL
      ircs
      994
      irc protocol over TLS/SSL
      pop3s
      995
      pop3 protocol over TLS/SSL

      Note: A listing of all IANA port assignments can currently be found at: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

      I have made the tool load all of these ports into the port text field by default.

      Note: The documented attack vector for POODLE is described for HTTPS connections, and not necessarily for these other protocols. The tool checks all of these protocols to check if your server is still accepting SSL2/3 connections in order to determine if it's globally enabled (in Windows the registry key effects SSL across most applications). Also, additional attack vectors may be found for other protocols, so if your applications can support newer versions of TLS it is probably wise to turn these older versions of SSL anyway.

      The Wrap Up


      There you have it, short and sweet! I hope the tool is useful to you and helps you take security issues more seriously J

      Let me know if you find any bugs or have any issues.


      Read more →