Filtering Exploitable Ports and Minimizing Risk from the Internet and from Your Customers

Barry Greene @ bgreene@senki.or Version 1.3 TLP: CLEAR 

What are you doing to prepare for the next “scanning malware” and “Internet Worm?”


Recommendation: Operators (CSPs, ISPs, Cloud Companies, and Hosting Companies) are strongly encouraged to deploy Port Filtering on the known Exploitable ports and Source Address Validation (SAV) on their customer edge of the network as a default configuration. Filtering Exploitable Ports will minimize risk to the Operator’s infrastructure and Customers and Proactively minimize risk to the collective Internet and telecommunications network. Customers who need access to their ports can request a bypass through the Operator’s customer support.

This document is a consultation and education tool for those Operators who have yet to deploy Exploitable Port Filtering. The document is maintained for the community.

Why filter the “Exploitable” Ports to and from your Customers?

Protocols and ports opened on the Internet do get exploited. Some of these ports are common, like TCP port 445. Other ports are specific to the SQL Slammer Worm in 2003 with UDP port 1434. Ports are also open to spoofing. It is common to have Threat Actors use exploitable ports to reflect attacks off of open ports to attack other targets using spoofed sources (the spoofed source is the target). Some of these ports amplify, others do not. Ports are also constantly scanned, looking for ports like Telnet port 23 for devices with default passwords. In May of 2017, we had another example of an exploited port with the WannaCry Ransomware attack. This attack exploits port 445.

All these scans, probes, and attacks pose a risk to the Operator. Infected customers cause unnecessary damage, generate calls to the Operator’s help desk, pose a risk to the Operator’s other customers, and increase the chance of damage to the Operator’s core infrastructure. Risk reduction is logical for any Operator. The Operator will always explore options to reduce the business risk to their infrastructure and customers. This is why the risk reductions gained by the anti-spoof/source address validation and anti-exploit port filters are critical to the Operator’s business. Deploying Exploitable Port filters on the customer edge minimizes the risk to and from the customers (customers infected with malware threaten the business). Applying these same filters to the Operator’s network (protecting the Operator’s staff and infrastructure) adds additional risk reduction. Finally, monitoring the volume of exploitable port traffic on the peering edge keeps a temperature to the Threat Actor’s interest in the ports.

Will Port Filtering Scale and Work on the Customer Edge?

In short yes. We have decades of experience with Operators who have deployed this type of filtering. In some countries, this is mandated (i.e. Canada). In large providers like Comcast, it is transparent (see Comcast’s Customer Page for Blocked Internet Ports). In all cases, this proactive port and Source Address Validation (SAV) filtering is not a replacement for the customer’s own firewall or defensive ACLs. Customers should still employ firewall devices to protect their network, thus by working with Operator(s) they are creating a multi-level protection system. The function is to reduce risk to the Operator through proactive filtering on known exploitable ports.

In summary, we know based on the experience of Operators who have deployed filtering on their customer edge for “exploit ports” and SAV that the following are true:

  • Vendor’s Network Gear should not be a problem. Customer Edge “Exploit Port” and SAV filtering has scaled on the customer edge. Some of the older hardware might have limits on the number of ports filters that can be applied. Yet, these requirements have been core to the network vendors for decades. Today (2017), we know that this core requirement will not impede the Operator’s ability to deliver their contracted Packets Per Second (PPS) and Bandwidth obligations to their customers.
  • Provisioning and Deployment are Scriptable. Modern provisioning and management tools have the capabilities to deploy and manage the customer-specific Access List (ACLs). Some tools offer the capability to generate these ACLs.
  • Customers Rarely Complain. Transparency is key to customers. Posting a “port filtering” and SAV guide for the customer so they know that their Operator is taking precautions to protect them has been the #1 “call deflection tool.”
  • Acceptable Use Policy (AUP) Updates. Customer AUPs need to be validated to clear the path to protect the network. This protects the Operator from specific customer complaints. Many AUPs already authorize the use of this type of port filtering, but it is best to check with the Operator’s internal counsel.

Return on Investment for Exploit Port Filtering

Operators who have deployed ACLs on their customer edge to filter the commonly exploited ports along with Source Address Validation (SAV) have all claimed that it pays off. SAV is also referred to anti-spoof filtering and BCP-38 (IETF Best Common Practice for Internet Operations). The task of filtering exploitable ports can be combined with “BCP-38.”

  • The customer complaints that their ports are filtered have never been more than expected. Always less with most of them handled by the Operator’s customer support team by pointing them to a public page on the exploit port filtering and SAV policy.
  • Protecting customer from reflection attacks, worms, and malware exploitation can be considered as “class deflection” for the Operator’s Customer Support Team. During an incident like WannaCry, the Customer Support Team can estimate the number of Microsoft Window users on their network, apply the Donelan PrincipleFOOTNOTE: Footnote and take 60% of that MS Windows user base to estimate how many people might have called if port 445 was open and WannaCry Ransomware locked up the machines. This would determine the value saved through “call defection” to the operator’s customer support.

What is the “Donelan Principle” states that for anyone security vulnerability, 40% of the people will patch right away, 40% will patch within the first month, and 20% will most likely never patch? Sean DoneIan <sean@donelan.com> illustrated this principle at a NANOG meeting in 2004. It has generally held true over the years through other empirical work on patching and security vulnerabilities. There will always be issues around what devices can and cannot be upgraded. While rapid upgrades and automatic upgrades are strongly encouraged, reality must be faced. Expect the 20% that cannot upgrade.

Recommendation: Empirically Measure if you have a problem with Spoofed IP addresses. Download the Spoofer Project tools and use throughout your network, not just on your customers. The Spoofer Project is an industry-supported activity managed by a neutral Internet research organization – Center for Applied Internet Data Analysis (CAIDA). Minimizing the risk on your network to spoofed source IPs is now measured by the industry. Your customers will be encouraged to deploy Spoofer on your network, which would then provide data the industry will use to determine which organizations impost a risk to the Internet collective.

Which Ports are “exploitable?”

The internal discussion within the Operator to determine which ports are “exploitable” and need “proactive filtering” will be controversial. There are will be a dialog that will explore the operational impact, the operational cost, the impact on the customer, the legal implication, the customer support impact, and the sales impact (is this type of filtering a sales benefit or hindrance).

Step one would be to collect live data on the ports that are being exploited. The following sites are public information sources that can be used by Operators to help them understand the risk to each of the ports and data on the current scans/exploit attempt on these ports.

Note: If asked, several of these groups will provide data directly to an Operator.

http://www.grc.com/port_port.htm

. . . where the port is a decimal number in the range 0 through 65535. For example, https://www.grc.com/port_445.htm will provide details on port 445.

  • Speedguide.net provides a detailed list of known vulnerabilities and exploitations per port. It is an excellent collection of threat vectors and known risk to ports. Operators can view the complete list of ports on Speedguide.net’s Ports Database. For example, a long list of exploits and vulnerabilities are listed for TCP Port 445 (see https://www.speedguide.net/port.php?port=445#). This list can help for the Operator’s discussion on which ports to filter.
  • NetLab 360 provides active scanning monitoring and sinkhole for huge sections of the Internet. Given that Qihoo 360 is based in China, it provides more comprehensive “point of view” of the Internet’s current scanning. For example, port 445 scans would list out note only the volume, but the source and other details.
  • Shadowserver.org scans for open port with known malware and other vulnerabilities. The reports for the scanning is aggregated and reported on Shadowserver’s Internet Scanning Project Page. Each ASN can submit to Shadowserver to get daily Email report based on this scanning (see Get Reports On Your Network). This report is useful to any ASN. It provides a safe “outside in” view of exploitable ports on their network.
  • Source Address Validation (Anti Spoofing) ASN Checks. The CAIDA Spoofer Project deploys tools which measure the IPv4 and IPv6 spoof source address capabilities and then reports on them via ASN Stats Page. This provides a tool for Operators to understand if their SAV deployments are working or the issues with the lack of SAV in their network. Operators are encouraged to deploy the Spoofer Project clients in their network and use the project’s resources to monitor the effectiveness of their SAV deployments.

Responding to Active Exploits

Active Exploits is one of the most cost-effective benefits of having Exploitable Porter Filters deployed. Operators will take notices when the notice goes out that “a service on port XYZ allows for a 100x amplification attack and bogs down the reflecting server.” (If they don’t take notice, their customer will when their network is abused and impacted by reflection attacks). A deployed Exploitable Port Filter allows the Operator to look at the port, explore the risk, explore collateral impact (does it block a service that is needed), and then deploy without worry to their customer experience.  

Let us take an example. The week of February 26th, 2018 saw an increase reflection exploitation of the memcache (UDP/TCP ports 11211). JPCERT put the first security advisory out – Attention on memcached access control – JPCERT-AT-2018-0009.  If Operators had exploitable port filters deployed in their network, they can quickly do the risk assessment, then push out an update that blocks all port 11211 on UDP/TCP on their network. They can do this on the ingress (coming into the network) and egress (going out of the network). If they are logging or tracking the counters, they would be able to see if someone is poking, scanning, or trying to abuse port 11211. 

Benefits and Drawbacks of deploying Active Exploit Filters

The key benefits of deploying active exploits filters  are:

  • The Operator – it keeps their network from being impacted people who will use their infrastructure and customers as DOS amplification servers. 
  • The Operator’s Customers – it keeps their systems from getting abused and impacted. This gives them time to patch. 
  • The Internet – It keeps your network from being used to attack others on the Internet. Telecoms & the Internet are a collective that requires everyone to look out for each other. 

The main drawback for deploying active exploit filters is the blocking of scanning by Whitehat organizations. There are groups who will scan for vulnerable systems and provide you reports. Blocking an active exploit port will also block the whitehat scanning. In that case, it might be worth considering setting up a “vulnerable port scanning system” in your network to find customers (and your own systems) which might be a vulnerability. There are commercial and open source tools available. The Whitehat scanning groups would be a place to start (ask them which code they use). 

When do you remove Active Exploit Filters?

Many times you will never be able to remove active exploit filters. Remember the Donelan Principle. There will always be a percentage of customers who will never patch a vulnerability – even if there is an active exploit. This will get worse with IoT and M2M devices that have no one looking after them. So yes, there might be cases when a port that is used for an active exploit can be removed from the “exploitable filter list.” But, historically, this is rare. 

Directional Filtering

Each port and exploitability to that port would determine the direction of the filter. Some would require filing traffic to the customer. Others will require traffic from the customer (SAV is an example). For most ports, filtering into and out of the customer would be the best way to minimize risk. One of the huge mistakes Operators will make in their security profile is the belief that their customers are part of their network and under their control. Customers are separate networks under separate security controls. Each of them makes network choices. Those network choices allow Threat Actors to exploit them. They then become as much of a threat to the Operator’s network as threats from the Internet. Given this, Operators are strongly recommended to view the exploitable port filtering on the egress (from customers) as part of the tools they use to protect their business from threats which victimize their customers.

Direction Threats.png

The “IoT” Threat

The Internet of Things (IoT) has always been part of the Internet. The threat of embedded devices which are connected to the Internet has always been there. Let use an example from the past, the 2002 SNMP Protos vulnerability. The SNMP Protos vulnerability was a single packet “crash the device” vulnerability expressed in CVE-2002-0012 and CVE-2002-0013. It was one of the most dangerous vulnerabilities experienced by the industry that required a wide collaboration in the FIRST community. The efforts facilitated by FIRST was one of the first examples of massive join vulnerability mitigation and remediation. In 2002 during the SNMP Protos vulnerability, a whole university campus had to restructure all of their heating and cooling system’s security because the vulnerable SNMP ports were exposed. There was no way to upgrade the devices, so they needed to be isolated from the rest of the campus network. This 2002 example is typical with IoT. There will be many times where patching is not possible. The “prevention” will require permanent port filtering that may or may not be required on the Operator’s Exploitable Ports filter.

By 2016, IoT has become simple for anyone to innovate and deploy. That means more devices, more interconnectivity, and more vulnerable systems. Given this, the IoT threat vectors will be one of the review exercises Operators must add to their regular Exploitable Ports filters.

Operator Filtering “Exploit Ports” Best Practices

Deploying customer edge exploit port and SAV will take planning and effort. Knowing that there are others who have already gone through this journey will help the Operator learn from other’s deployment experiences. Operators are strongly encouraged to reach out to their peers at Internet Network Operations meetings to gain insight. What will be found is a willingness to share. As stated, the reason why an Operator will deploy these customer edge filters is to protect their infrastructure, protect their customers, and protect the Internet. Hence, it is only logical to have other Operators who have already deployed these filters to share their experiences with others.

Several Operators have already collaborated on Exploit Port Filtering BCPs. The Broadband Internet Technical Advisory Group (BITAG) pooled their collective wisdom and published a uniform agreement report on Port Blocking (http://www.bitag.org/documents/Port-Blocking.pdf). This is a comprehensive guide for Operators to deploy ACLs to minimize the risk to Exploitable Ports. The key BCP recommendation for BITAG’s Port Blocking BCPs is paraphrased as:

“[Operators] should avoid port blocking unless they have no reasonable alternatives available for preventing unwanted traffic and protecting users. Further, if port blocking is deemed necessary, it should only be used for the purposes of protecting the implementing [Operator’s] network and users. Port blocking should not be used for ongoing capacity management, to enforce non-security terms of service, or to disadvantage competing applications.” (BITAG Port Blocking (https://www.bitag.org/documents/Port-Blocking.pdf Executive Summary)

In other words, these exploitable port filters should not be used to filter Whatsapp, PtP, or other applications that related to net neutrality, content, censorship, and OTT filtering. The objective is security risk reduction.

Operators should publicly disclose their port blocking policies. The information should be readily available to both customers and non-customers alike and should be as informative and concise as possible. For example, port blocking policies could be provided on the [Operator’s] public-facing website, on a page dedicated to summarizing or describing the respective [Operator’s] network management practices. For persistent port blocks the information should include: (1) port numbers, (2) transport protocol (e.g., TCP or UDP), (3) the application(s) normally associated with the port(s), (4) the direction of the block – whether inbound or outbound, (5) a brief description of the reason(s) for the block, and (6) if opt-out provisions are available and how to request such. (BITAG Port Blocking (https://www.bitag.org/documents/Port-Blocking.pdf Executive Summary)

The public posting of the exploitable port filters is essential for the Operator’s customer Service call deflection.

ISPs should make communications channels available for feedback about port blocking policies. Applications providers and consumers should have communications channels or other clear methods to discuss impacts caused by port blocking and to consider possible mitigations. (BITAG Port Blocking (https://www.bitag.org/documents/Port-Blocking.pdf Executive Summary)

ISPs that can reasonably provide to their user’s opt-out provisions or exceptions to their port blocking policies should do so. Whether opt-out provisions can be supported may depend on the particulars of the access network technology, the location port blocking is implemented in the network, administrative complexity, cost, and other factors. (BITAG Port Blocking (https://www.bitag.org/documents/Port-Blocking.pdf Executive Summary)

ISPs should revisit their port blocking policies on a regular basis and reassess whether the threats that required the port blocking rules continue to be relevant. Some security threats are permanent and some are transitory or short-lived. Items such as spam prevention by blocking TCP port 25 from the customer are expected to last quite some time, while others such as blocks to prevent certain types of malicious software may be temporary. (BITAG Port Blocking (https://www.bitag.org/documents/Port-Blocking.pdf Executive Summary)

Port blocking (or firewall) rules of consumers’ devices should be user configurable. It is recommended that the documentation provided with each unit inform the consumer that port blocking or firewall rules have been implemented, which ports are blocked by default, and how consumers can modify those rules. (BITAG Port Blocking (https://www.bitag.org/documents/Port-Blocking.pdf Executive Summary)

While many Operators will at first think of “user configuration” as a tedious exercise with no ROI, the advent of virtual CPE (vCPEs) in the Network Feature Virtualization (NFV) architectures will open new doors to consider. Many times the best way to deploy security defenses is through the use of a service.

It must also be noted that many of the vendor deployments available to Operators do not have the capability to have per subscriber configurations. At most, there would be “groups” and “profiles” but not “per subscriber.” The “should be user configurable” would be an aspiration and a requirement on the vendors for future products/features.

FAQ for Best Practices

My Customers are using NATs. Do I need to deploy the Exploited Port filtering and SAV?

Some would think no SAV or Exploited Port filtering is needed on customer CPE’s that have NAT enabled. From a risk reduction point of view, this would not be a safe assumption. Operators have seen that even with CPE/NATs, infected customers will still send out the spoofed source and destination traffic on these exploited ports. It would be safer to assume that the customer’s NAT is not in-place. This will become more important as IPv6 adoption continues.

Should the “filter” use IPv4 only or also include IPv6?

Assume IPv4 & IPv6. Be mindful that in many places, there is no NAT around IPv6. Plus, it takes a while to review, approve, test, and then push up the provisioning for the exploited port/SAV ACLs. It would be operationally beneficial to have both deployed the same time.

Should we deploy Exploited Port Filtering on Ephemeral Ports?

Ephemeral ports are temporary assignments allocated for the protocol’s source ports. At times, applications that consistently allocate to ephemeral ports are targeted. For example, UDP port 1900 for SSDP has been targeted in the past. UDP port 1900 is ephemeral on some operating systems. On others, 1900 is not. Some Operators have deployed UDP port 1900 to their exploited port filtering rules with no customer complaint increase. These are all factors determined by the specific Operator. The key is for exploited port filtering to be deployed and not be blocked by “perceived risk” to customer impact. The general consensus among Operators who have deployed over the last decade is that deployment reduces risk to their business, operations, and customers while saving money with reduced customer support issues.

If you are looking for more details on the ephemeral port ranges for each operating system, thank John Kristoff @ Team CYMRU. John compiled a list of ephemeral port number ranges along with the port selection strategies for most of the operating systems:  Ephemeral Source Port Selection Strategies. This is a good reference for teams working on their own port filtering strategies. 

Operator’s Public Statements on Port Filtering

As mentioned, it is strongly recommended for all Operators who deploy exploited ports filtering and SAV to publish details. This publication would be used for interaction with customers. In fact, it might also be recommended for the Operators who choose to NOT filter, to also publish their reasons. The following is a collection of examples. Notice that there are different ways to approach this requirement. Each approach is tuned to the Operator’s customers and is most likely measured by the Customer Support feedback from these customers. Hence, the only “right way” is the way that evolves through internal consultation by the Operator’s key stakeholders.

Here is a selection of the Operator’s public statements. They are provided as a reference to give the community an idea of how others have accomplished the task and to illustrate that the recommendation to filter exploitable ports is the mainstream best common practice that reduces risk.

Cable One

Cable One integrates its public statement on port filtering into its “Network Management Disclosure.” http://www.cableone.net/legal/network-management The statement (at the time of this document) states:

“As described above, the Company reserves the right to employ network management practices, e.g., to prevent the distribution of viruses or other malicious code, as well as to block, in accordance with applicable law, transfer of unlawful content such as child pornography or the unlawful transfer of content. As such, Cable One blocks ports 135, 136, 137, 138, 139 & 448. SMTP Port 25 is restricted to Cable One Mail servers for residential customers.”

This allows Cable One flexibility to respond to immediate risk. For example, if there is a new IoT Exploit vector, Cable One would be able to legitimately filter and blackhole to minimize the risk to their customers.

Lumen/Centurylink has a long, comprehensive public disclosure of its policies and practices. The detail is excellent, with everything on one page.

Internet Service Disclosure (Long)

Lumen/CenturyLink is also a Broadband Internet Technical Advisory Group (BITAG) member. The BITAG Port Filtering recommendations can be seen in Centurylink’s disclosure.

Comcast/XFINITY Customer “Blocked Internet Port List” Example

Comcast provides an excellent example of customer transparency for their proactive port filtering. The system communicates what is happening to the customer and becomes a tool for their customer support to interact with them. Additional ‘exploited’ ports can be added over time.

https://customer.xfinity.com/help-and-support/internet/list-of-blocked-ports/?MAR=HOME_AX06.16

Find out which ports are blocked by XFINITY and Comcast services and why.

Find the Reasons for Blocking Listed Below

PortTransportProtocolDirection Downstream/ Upstream to CPEReason for BlockIP Version
0TCPN/ADownstreamPort 0 is a reserved port, which means it should not be used by applications. Network abuse has prompted the need to block this port.IPv4/IPv6
25TCPSMTPBothPort 25 is unsecured, and Botnet spammers can use it to send spam. This does not affect XFINITY Connect usage. We recommend viewing Configure Your Email Settings to Comcast Email to use port 587.IPv4/IPv6
67UDPBOOTP, DHCPDownstreamUDP Port 67, which is used to obtain dynamic Internet Protocol (IP) address information from our dynamic host configuration protocol (DHCP) server, is vulnerable to malicious hacks.IPv4
135- 

139

TCP/UDPNetBiosBothNetBios services allow file sharing over networks. When improperly configured, ports 135-139 can expose critical system files or give full file system access (run, delete, copy) to any malicious intruder connected to the network.IPv4/IPv6
161UDPSNMPBothSNMP is vulnerable to reflected amplification distributed denial of service (DDoS) attacks.IPv4/IPv6
445TCPMS-DS, SMBBothPort 445 is vulnerable to attacks, exploits and malware such as the Sasser and Nimda worms.IPv4/IPv6
520UDPRIPBothPort 520 is vulnerable to malicious route updates, which provides several attack possibilities.IPv4
547UDPDHCPv6DownstreamUDP Port 547, which is used to obtain dynamic Internet Protocol (IP) address information from our dynamic host configuration protocol (DHCP) server, is vulnerable to malicious hacks.IPv6
1080TCPSOCKSDownstreamPort 1080 is vulnerable to, among others, viruses, worms, and DoS attacks.IPv4/IPv6
1900UDPSSDPBothPort 1900 is vulnerable to DoS attacks.IPv4/IPv6

Cox Communications

Cox Communications has an FAQ page set up by their customer support team. This approach allows for dynamic update, a knowledge base of Q&A, and lots of detail:

Internet Ports Blocked or Restricted by Cox is the official article by Cox. There is more in their support channel: “Which incoming ports are not open for Cox residential users?“

http://www.cox.com/residential/support/internet/article.cox?articleId=cacf82f0-6407-11df-ccef-000000000000

Cox can state the reason upfront so customers will see, understand, and not call the help desk (call deflection). At the time of this document, Cox provides the following for their customers:

Reasons For Filtering Ports

Protecting customers – Certain ports are filtered to protect our customers. They can protect against certain common worms and dangerous services on our customers’ computers that could allow intruders access.

Protecting upstream bandwidth – Upstream bandwidth to a cable plant is limited. If customers overuse their upstream bandwidth by running high-traffic servers or becoming infected with a worm or virus, it can affect the service of other customers in their area.

Protecting the rest of the Internet – Some filters prevent attacks on other computers by way of the Internet. In addition to being in our best interests to protect our bandwidth, Cox considers preventing the abuse of our network as its responsibility.

Other Examples of Operators Deploying “Exploitable Port Filtering:”

Recommendation: Operators do not need to make only one Public Statement about how they do Exploitable Port Filtering and SAV. There can be a page for legal disclosure and a page focused on Customer Service Excellence (i.e., empower the customer and call deflection).

Other Examples of Operator’s Public Statements on Exploitable Port Filtering

The following is a collection of other Operator’s Public statements. As any Operator knows, these are subject to change. It is best to use the URL and go to the source.

Recommendation: If you have yet to deploy port filtering on the exploitable ports, seek out your peers in the community. All of these examples are also examples of peers who might spend time with you to help with your organization’s journey. As mentioned, one of the side benefits of this type of port filtering is a safer Internet. Hence, it is in your peer’s best interest to help you succeed in a safer, more secure Internet.

Altice

https://www.optimum.net/pages/Terms/Internet/Open-Internet-Disclosure.html

“Network and End-User Security – Altice reserves the right to protect the integrity of its network and resources by any lawful means it deems appropriate. Altice takes steps to protect the security of its network and its Subscribers which include e-mail virus scanning, denying email from certain domains, spam detection techniques, and putting limits on e-mail based on the relevant service. In order to further protect our Subscribers, Altice blocks a limited number of ports and protocols that are commonly used to send spam, launch malicious attacks, or steal a user’s information. In addition, in order to protect against Denial of Service (DoS) or other malicious attacks, Altice enforces limits on the number of transactions per second that Subscribers can send or receive with respect to log in, SMTP, DNS, DHCP and other transactions that could impact the security or performance of Altice’s network. Altice also makes available certain security tools for use by our Subscribers.”

Blue Ridge Networks

http://www.brctv.com/disclosure

“Specific network management tools and techniques may include detecting and curtailing malicious traffic patterns, preventing the distribution of viruses or other malicious code, measuring subscriber bandwidth usage, prioritizing certain traffic such as network control packets, limiting the aggregate bandwidth available for certain usage protocols, regulating the delivery speed of mass emails, rejection, or removal of “spam” or otherwise unsolicited bulk email, detecting and preventing the distribution of viruses and other malware, traffic prioritization and other tools and techniques as BRC may from time to time determine to be appropriate. Additionally, IP traffic sent to customers on ports TCP 25, TCP 80, TCP 443, TCP 445, TCP 1080, TCP 6667-6669, TCP 1433-1434, TCP & UDP 135-139, TCP & UDP 67 is blocked for security and network management reasons to minimize customer’s computers from being virus infected through well-known vulnerabilities and/or to avoid infected or hostile computers from affecting other users’ computers.”

Central Texas Communications

Click to access CTC-Open-Internet-Policy.pdf

“Central Texas Communications Inc. does take measures to protect its network and ensure that its AUP is enforced. For example, ISP has deployed measures to prevent spam, viruses, and other malware and to monitor and prevent denial of service attacks. Central Texas Communications Inc. does not generally interfere with or manage the use of specific protocols or ports. However, in the interests of network security, the following ports may be blocked or unavailable” (ports 135-139 and 445)

Telecommunication and Internet Regulations

While many in the Internet and Telecommunications community push back on regulations, there are some regulations that are not unreasonable and ensure that everyone’s collective action results in a collective benefit. The following are examples of national regulation and recommendations related to exploited port filtering.

Finland

Finnish Communications Regulatory Authority (FICORA) has long required standard Internet hygiene. For example, in Chapter 3 of the regulation (https://www.viestintavirasto.fi/attachments/maaraykset/M67A_2015_EN.pdf) you find two key statements:

Section 10 Closure of unnecessary services and protocols. The telecommunications operator must ensure that no services or protocols that are unnecessary for the provided communications service are enabled in the components or the associated ports of communications networks or services in the operator’s interconnection or customer interfaces.

This allows the Finish Operators to deploy any and all exploitable port filtering. And then there is Source Address Validation (SAV) by law:

Section 12 Prevention of IP traffic in customer interfaces. The telecommunications operator must filter any traffic from a customer interface to the communications network with a source address that is not assigned to the customer interface in question. The telecommunications operator must apply filtering in the network element that is closest to the customer interface and when it is technically the most appropriate to apply the filtering. As a milder alternative to the traffic filtering referred to in subsection 1, the customer may be contacted for the purpose of solving the situation that poses a threat to information security.

More detailed explanatory notes to Regulation 67 <https://www.viestintavirasto.fi/attachments/maaraykset/M67A_MPS_2015_EN.pdf> can be found online.

The key points with FICORA regulation:

  1. Exploitable Port Filtering and Source Address Validation (SAV) is a requirement for all Telecommunications Operators and ISPs. That means the equipment, tools, management, and other factors needed to operationally deploy and maintain these tools work with mainstream vendors and practices. “It will not work on my network” is an excuse.
  2.  
  3. Finland is known for being one of the most “connected” countries on the planet. Given this, the Finish citizens will not tolerate these security practices being deployed if there is an adverse impact on their “connected” life. “It will make my customers upset” is also, just another excuse. (See http://www.internetworldstats.com/top25.htm and other searches for Finland’s latest % connected data.)

Reference Documents

The following references are provided to help Operators with their exploited port filtering and Source Address Validation (SAV) deployments.

Contributors

Recommendations, guidance, and operational experience provided in this document would not be possible if not for the collective contributions from various Trust Groups and individuals. Sharing and collaboration are hallmarks of what makes the Internet Operations Community enjoyable and special. Some of the noted contributors help craft this into a better document include Matt Carothers <Matt.Carothers@cox.com>, Donald Smith <donald.smith@centurylink.com>, Damian Menscher <damian@google.com>, and many others. Given that this is a living document, more contributors will be added.

Need Security Advice?

If you find your organization needs help and worry about the FUD from the industry, reach out and ask for help. You can reach me at bgreene@senki.org. Start with the Operator’s Security Toolkit. It is the no-nonsense security for all Operators. It provides details to help them build more security resilient networks. In the meantime, stay connected to the Senki Community to get updates on new empowerment and security insights.  [mc4wp_form id=”1732”].