Monday, September 30, 2019

ISP internal vulnerability scanning

Looking for some insight on how other Network engineers handle vulnerability testing.

Some history I work at a mid-size ISP that offer FTTH services via Adtran TA5000 and 5004s. Our network security team (who primarily come from government sector backgrounds) feel the need to be scanning all of our core transport equipment. This has not necessarily been a big deal, other than they wreak havoc on our alarm log with the hundreds of failed login attempts. Last week, though, we came in to find about 14 of our 65 nodes refusing telnet and SSH connections. After 12 hours of troubleshooting with Adtran we finally discovered that all of the 384 TCP listening slots were locked up. We rebooted the System controller to clear all the connections and all was good. Over the next few days and several troubleshooting instances with Adtran we discovered the list of IPs that were holding the TCP connections. They were all from our Network Security Teams probes. It came to light that their scans had discovered a bug in Adtran's firmware that in a very specific set of port scanning would allow port 77 to get locked in the Syn-received state and would not time out the connection. Each scan would grab any where from 3-7 connections on this port, so after a few months all available connections are used.

All of this to be said what do other engineers at ISPs do as far as handling Vulnerability scanning. I've talked to someone I know at another ISP, and they thought it was ridiculous to be Scanning the core equipment. Their mindset was all of the transport equipment should be behind a firewall and have no public access so there is not reason to be scanning it. My team feels the same way, but the Security guys don't agree, and will not stop scanning even though they are killing us on this management issue.

If anyone has some white papers, or any kind of information one way or another that would be extremely helpful.



No comments:

Post a Comment