MSP Blog Logo


Business Growth


Help Desk



Sales & Marketing


Empowering Your MSP Business to Grow and Prosper—One Post at a Time

5 Ways to Improve Your MSP Service Level Agreement (SLA)

Featured Post

5 Ways to Improve Your MSP Service Level Agreements (SLAs)

SLAs are the foundation of your MSP business. They are essential to building strong client relationships and must be clear, reasonable and well-constructed.

Read Now

8 Vulnerabilities You Didn’t Know Existed in Your System Configuration

Posted October 13, 2015by Yves Dorleans

Unsophisticated intruders using simple tools often are successful in breaching organization’s networks due to configuration errors, lack of IT controls and secure internal processes. During my blog series, we will cover simple countermeasures, safeguards that are easy to implement, that should significantly decrease the chance and occurrence of hacks and data loss. First, let us go through the 8 basic avenues that are available to cybercriminals:


1. Keeping default usernames and passwords on new software and network devices

Once an intruder finds basic information about a victim’s computer such as IP addresses, open ports, and the services running on those ports which can be garnered using freely available networking tools, the first step is to try to access resources using less sophisticated methods to avoid leaving traces through logging events. There are simple automated tools and wordlists, for example, that make the password brute force process a breeze, whether the intruder is trying to decrypt a password file or doing online authentication. The majority of Network appliances, such as firewalls, wireless access points and routers are sold with widely known credentials often available on the vendor’s website or in their manuals; several websites also offer libraries of network products as well as the default usernames and passwords. When an unauthorized users gain access to your server, you have to make them work hard for every piece of information. Oftentimes, the first break-in occurs with an unprivileged user account such as guest. The goal for the intruder at this point is to try to escalate privilege to administrative roles; Therefore disabling the guest account and assigning or changing the passwords are controls you should implement right away when configuring servers and workstations.

Rename the admin password to be less obvious, and change default known passwords on servers, workstations and network devices. Despite most IT administrators not implementing this configuration, it often represents the difference between a full system compromise with no trails of the intruder being caught, and your IPS/IDS systems triggering an alarm.


2. Not having a process to review users with domain admin access, and using privileged accounts on a day-to-day basis

Periodically assessing the list of users with elevated privileges allows you to remove access for users who have changed positions within your organization. Additionally, IT administrators should create another account for routine tasks that do not require administrative level roles and leave powerful users such as DBAs and backup administrators to have their own elevated account access.


3. Not removing access for terminated users and consultants after their work is done 

This is a simple, but valuable manual process. Organizations often lack user management procedures and controls to manage the provisioning of accounts for new and existing users. Generic accounts created for vendors, and contractors are not reviewed and deleted. For very small organizations with minimal turnover, it may not be a big deal; a frequent user account review may not be needed, as the IT administrator will know who has powerful access and when someone leaves the company. However when your organization is growing, and is seeing lots of traffic in terms of contractors, consultants and employee turnover, it is a good idea to implement a periodic review of user access especially the ones with administrative privileges.

Disgruntled employees may try to log in and do damage to your systems, and may even delete log files that would leave you incapable to investigate the incident. Privileged credentials may end up on electronic boards and chat rooms where stolen electronic information is traded. Even internal, disgruntled IT employees who still works for the company may use terminated user accounts to commit fraud, and other illegal activities.


4. Not using a baseline security configuration standard for new servers

The majority of vulnerabilities reported by scanners stems from bad default configuration of the operating systems. OS vendors deliver their products with these features turned on. This affects not only the performance, but also the security of the system. Services that become a liability because of security issues are set to start automatically, and configured to listen to certain known ports. To implement your security policy, your company should provide clear guidance on configurations that are aligned with the business requirements. SCAP, which stands for security automation protocol managed by NIST National institute of Standard and Technology, provides a checklist and set of baselines for various Operating Systems and applications as guidance to configure a multitude of products from web servers and office applications to web browsers. Several of these services if running, render your environment vulnerable, and can provide a way to unauthorized users.


5. Leaving telnet and FTP services enabled and not using secure remote protocols instead

Among the services installed on servers are ftp, telnet and terminal services. As we mentioned in the paragraph above, data sent over these protocols are sniffed using freely available tools. FTP and telnet periodically phone home or to the linked computer to re-authenticate. During the handshake process, user names and passwords are sent in clear texts and can be used by a third party. There are often valid business reasons to use those services, however there are secured versions of ftp, telnet and terminal sessions such as SFTP, IPSEC; for terminal session also called RDP (Remote Desktop Protocol), configure TLS 1.2 to require a certificate and provide authentication and encryption.


6. Using or not disabling weak ciphers suites such as RC4 and those using less than 56 bit encryption

There has been proof of concept, as well as successful exploits demonstrating the RC4 algorithm has weaknesses in the way it generates its cipher texts, where the randomness of the byte streams can provide a way for an intruder to convert the cipher texts into the actual encrypted data. Communications that occur over SSL/TLS may use the RC4 algorithm to encrypt data sent over the public domain if the configuration is not turned off. If intercepted, the data can be decrypted without having the required encryption key. Several versions of SSL/TLS have been deprecated for their use of the RC4 algorithm.


7. Not blocking the updated SMB during initial server configuration

It's important to upgrade to the latest SMB protocol that offers servers access over the Internet. SMB stands for server message block protocol and was introduced with Microsoft Windows 95 to allow users to read and write files at remote server locations. UNIX system used a similar protocol call Samba. These protocols are used on web servers serving resources to customers, and are also used on internal storage servers. The SMB service has had vulnerability for at least eighteen years and can be exploited with Man-in-the-Middle (MiTM) techniques. An attacker can use malware to redirect user requests in the browser for resources to a rogue file share, and in the process steal user names and passwords. These user names and passwords can be decrypted, and if hashed can be used in a replay attack. Because it's a security concern, Microsoft continuously releases patches for SMB, and users should deploy these patches as soon as they become available.


8. Not using Kerberos services instead of NTLM for authentication

Note: NTLM needs to be disabled so that the system will not use it as a fallback in case Kerberos fails.

Using NTLM as the basis for AD authentication is not safe. Most Active Directory infrastructure have the NTLM authentication turned on by default as a fail over if Kerberos is not available. I have come across several systems where Kerberos is not being used and the systems only rely on NTLM for authentication. The reason for this is that NTLM is integrated with other key protocols needed for email communications, such as POP3 and SMTP.

Microsoft has released patches for NTLM, however even the latest version NTLM v2 is vulnerable. Though Kerberos has its own security issues, it is safer to use in AD for user authentication.


See also:


Protect yourself against more MSP pitfalls with this eGuide


Yves Dorleans is Director of Information Security and Compliance at Continuum Managed services, he has been working in IT operations, compliance and security for over 15 years. Yves lead consulting teams for engagements with small, and medium sized businesses in the design of security and IT General Controls required for compliance, state, private and federal regulations. For several years at KPMG Yves was part of the advisory practice that was instrumental in helping companies adapt IT and security control frameworks, such as COBIT, NIST to support their internal business processes.

RMM 101: Must-Haves for Your IT Management Solution
MSP Guide to Managed Services SLAs  [white paper]
comments powered by Disqus