• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

My Semi-Managed Switch – TL-SG2008

07/10/2016 By Andrew Roderos 2 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

I bought three of the TL-SG2008 the same day I bought my EdgeRouter Lite. I’ve always wanted some form of managed switch at home to satisfy my wants and to segregate my lab environment.

tl-sg2008

In my old setup, I had three unmanaged switches and all-in-one router (with switch and access point built-in). While they worked fine, I wanted some SMB features – LACP, IEEE 802.1Q, etc. That said, I needed to buy some form of managed switches.

I checked for used Cisco Catalyst 3560CG on eBay but they are still expensive. I also checked for used prices of Cisco SMB products and they are also expensive for my needs. By then, I realized that I should look at other vendors.

The search begins

I checked Netgear and Linksys product pages because they are popular manufacturers in SOHO and SMB space. I found potential products but I wanted more options. That said, I also checked other manufacturers like D-Link, ZyXEL, and TP-LINK. After few days, I narrowed the potential products into two: TL-SG108E and TL-SG2008.

I like the TL-SG108E because of the price and meet my requirements. However, I did not like the fact that I can only configure the switch with a Windows machine because of the application that they provide. The CLI access, SNMP, etc. are the features I like to have so I went with the TL-SG2008.

Amazon review

When I was looking at TL-SG2008, there is a 1-star review in Amazon that caught my eye. The person who wrote the negative review is calling himself/herself as Mandrake. The review stated that the product includes security vulnerabilities and claimed that the company will not issue firmware to address them. The company, however, released a firmware that claims that they improved the security level. To me, this signals that the company patched the security vulnerabilities found in this report. This assumption is later confirmed by one of the commenters in Mandrake’s review.

While the company seems to have addressed the security vulnerabilities, reading the notes further reveals that they are still using weak security protocols. For example, the recent firmware includes SSLv3 and TLSv1 that addressed the security vulnerabilities of SSLv2. For general users, this might indicate that they’ve improved security but far from truth. Sure, removing SSLv2 does improve security level. However, replacing it with old or deprecated protocol does not.

SSLv3 is not sufficiently secure according to RFC 7568. With the release of POODLE type of attack, one should definitely disable this protocol. However, disabling SSLv3 means that we have to use TLSv1. This protocol, however, is no longer acceptable in new implementations per PCI DSS v3.2 document. The document also states that entities should start working towards migrating to new TLS version. Hopefully, TP-LINK will release new firmware that will remove SSLv3 completely and add TLSv1.2.

Vulnerability Reports

Knowing that the firmware is using outdated security protocols, I decided to run Kali Linux – just used it last month. Kali has a lot of security tools pre-installed that hopefully I can play with in the future. For now, I used it to install and run Nessus Home and OpenVAS to check for security vulnerabilities.

I did two scans for each of the vulnerability scanners: one default configuration for both HTTPS and SSH settings and then I made changes. Note: The switch comes with HTTP and Telnet as the default protocols for management. Users will have to configure the switch to use the secure protocols. Using non-secure protocols by default for management is bad practice. Did they really improve security level?

First vulnerability scan

The first vulnerability scan is my baseline. At this time, I enabled HTTPS and SSH then disabled HTTP and Telnet for management. I left the other settings alone in the HTTPS and SSH configuration section.

HTTPS

In HTTPS configuration section, there are two sections one could play with and these are: cryptographic protocols and cipher suite. For the cryptographic protocol section, we must use at least one protocol.

TL-SG2008(config)#ip http secure-protocol
 ssl3                 - Protocol levels (versions): SSLv3
 tls1                 - Protocol levels (versions): TLS1.0

For the cipher suite section, there are four ciphers that we can choose from. In order for HTTPS to work, we must enable at least one cipher. I actually tried disabling the all of them except 3DES-EDE-CBC-SHA but I lost connectivity using Chrome.

TL-SG2008(config)#ip http secure-ciphersuite
 3des-ede-cbc-sha     - Encryption type ssl_rsa_with_3des_ede_cbc_sha
                         ciphersuite
 rc4-128-md5          - Encryption type ssl_rsa_with_rc4_128_md5
                         ciphersuite
 rc4-128-sha          - Encryption type ssl_rsa_with_rc4_128_sha
                         ciphersuite
 des-cbc-sha          - Encryption type ssl_rsa_with_des_cbc_sha
                         ciphersuite

SSH

In the SSH configuration section, there are three sections one could play with and these are: version, encryption, and finally the data integrity. The output below shows the settings available for us to configure.

For the first configuration section, we must use at least one.

TL-SG2008(config)#ip ssh version
 v1                   - Protocol version v1
 v2                   - Protocol version v2

For the second section, we have six encryption algorithms to choose from. We must use at least one.

Lastly, we have two data integrity algorithm available to choose from: HMAC-SHA1 or HMAC-MD5. We must use at least one.

TL-SG2008(config)#ip ssh algorithm
 <algorithm>          - Enable SSH algorithm, AES128-CBC | AES192-CBC |
                         AES256-CBC | Blowfish-CBC | Cast128-CBC |
                         3DES-CBC | HMAC-SHA1 | HMAC-MD5

Results

Both Nessus and OpenVAS report summary shows seven medium severity vulnerabilities. If one does not read the report, one might conclude that both of the scanners reported the same thing. However, reading the report shows their similarities and differences.

Here is the Nessus summary report

Nessus Before Changes Summary

Here is the OpenVAS summary report

OpenVAS Before Changes Summary

I have uploaded both the reports. Click here for Nessus report and here for OpenVAS report. Feel free to view the documents if you want to follow along.

In the Nessus report, two of the vulnerabilities point to self-signed certificate used by SSL/TLS. Self-signed certificates pose a security risk because of man-in-the-middle attacks. However, I think this is fine in a home environment so I do not consider it being that bad. Though, security professionals may disagree with this thinking.

As mentioned earlier, SSLv3 is vulnerable to POODLE type of attack. Both Nessus and OpenVAS reports this vulnerability as well. As a reminder, SSLv3 does not provide sufficient security in this day and age.

I do not want to enumerate everything in this post, but I want to mention one more thing that is in the OpenVAS report. The vulnerability does not only affect TP-LINK but multiple manufacturers as well. The security vulnerability that I am talking about is the one that says “Known SSH Host Key”. You can find more information here. Unfortunately, there is no way around this because of TP-LINK did not include a way for users to generate new keys. Being able to generate new keys is a common practice in configuring networking devices.

Last vulnerability scan

In this last vulnerability scan, I disabled some settings so I can lessen the security vulnerabilities of my switches. With the current firmware, I will never able to reach zero security vulnerability.

HTTPS

In the HTTPS configuration section, I disabled SSLv3 and two RC4-based ciphers. Though, the two left are also weak ciphers in today’s standards. Today, TLS implementations are using stronger ciphers like AES in GCM mode, AES in CTR mode, or ChaCha20.

ip http secure-protocol tls1
ip http secure-ciphersuite des-cbc-sha 3des-ede-cbc-sha

SSH

In the SSH configuration section, I disabled the following lines. Any device with SSH should no longer use SSHv1. The manufacturer should have not included this version if they want to improve security level.

no ip ssh version v1

For the encryption algorithm, I disabled three of them. Though, all of the encryption algorithms available to us are weak anyway so it may not buy us anything. Encryption algorithm using Cipher Block Chaining (CBC) mode is weak. As a result, we will see that OpenVAS and Nessus will report that we are still using weak SSH ciphers.

no ip ssh algorithm Blowfish-CBC
no ip ssh algorithm Cast128-CBC
no ip ssh algorithm 3DES-CBC

For the data integrity algorithm, I disabled MD5 because it is vulnerable to collision attack as described in this paper. Though, SHA1 is also vulnerable to an attack as described in this paper.

no ip ssh algorithm HMAC-MD5

Results

As you can see below, I was able to reduce the number of medium severity vulnerabilities by disabling some settings. Interestingly enough, the OpenVAS increased to three low vulnerabilities. Again, I uploaded both of the reports. Click here if you want to see Nessus report and here for OpenVAS.

Here is the Nessus summary report

nessus.after.summary.report

Here is the OpenVAS summary report

openvas.after.summary.report

Things I like

There are few things I like about this switch that other smart switches don’t have

  • CLI access is big for me
  • SNMP/RMON is pretty cool to have for monitoring purposes
  • LACP support
  • 802.1X support (though, quite limited)

Things I don’t like

Aside from the security vulnerabilities, there are few things I do not like about this switch.

  • Lack of password complexity
  • No RADIUS support for device authentication
  • Lost configs after upgrading the firmware

Thoughts

I think it is unfair to for the reviewer to rate it as 1-star purely based on security vulnerabilities. Don’t get me wrong though. Security is very important and would probably lose one or two stars but giving it 1 out of 5 seems to be unfair. If one cannot eliminate the security vulnerabilities then mitigation becomes important. In this case, I was able to reduce the number of security vulnerabilities by turning off settings. In addition, I can reduce the number of medium severity vulnerabilities by disabling HTTPS for management. Speaking of management, the switch offers ACL capability so one can configure it to limit computer(s) that can access it.

Is it better to buy another product that does not include these security vulnerabilities? Sure. Will I return the product? Unfortunately, I will not be able to return them because I’ve had them for more than six months now. If I was able to return them, will I? I have to say no. I haven’t had any issues with the switch and I really like a switch that has CLI access. I have not seen one in the same price range that offers this feature. There is a possibility that I am not looking hard enough though. Will I recommend it? Sure, so long as the buyer is aware and understand the vulnerabilities that come with it.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Filed Under: General Tagged With: Switch

About Andrew Roderos

I am a network security engineer with a passion for networking and security. Follow me on Twitter, LinkedIn, and Instagram.

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use