What are you doing to prepare for the next “scanning malware” and “Internet Worm?”
Barry Greene @ email@example.com
Updates for this Best Common Practice (BCP) are maintained on this page: Filtering Exploitable Ports and Minimizing Risk from the Internet and from Your Customers
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. This will minimize risk to the Operator’s infrastructure, the Operator’s Customers, and Proactively minimize risk to the collective Internet & Telecommunications network. Customers who need access to their ports can request 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. New versions of this document can be found here: http://senki.mystagingwebsite.com/operators-security-toolkit/filtering-exploitable-ports-and-minimizing-risk-to-and-from-your-customers/
Why filter the “Exploitable” Ports to and from your Customers?
Protocols and ports opened to the Internet do get exploited. Some of these ports are common like TCP port 445. Other ports are specific like the SQL Slammer Worm in 2003 with UDP port 1434. Ports are also open to spoofing. It is common to have Threat Actor use exploitable ports to reflect attacks off of open ports to attack other targets using spoofed source (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 attack pose a risk to the Operator. Infected customers cause unnecessary damage, generates 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 be exploring options to reduce the business risk to their infrastructure and their customers. This is why the risk reductions gained by the anti-spoof/source address validation filters AND anti-exploit port filters are critical to the Operator’s business. Deploying Exploitable Port filters on the customer edge minimizing the risk to and from the customers (customer infected with malware are a threat to the business). Applying these same filters within 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 an 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 have 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 is 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 with 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 point 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 any one 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 <firstname.lastname@example.org> 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 upgrades. 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 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.
- SANs Internet Storm Center uses dshield and other sinkhole sources to monitor the ports scanning and exploits. https://isc.sans.edu/trends.html
- Gibson Research Corporation (GRC) maintains a list of vulnerabilities per port. Online data for any Internet port within the range from 0 through 65535 may be accessed through the port Jump links at the bottom of any port database page, or directly with a URL of this form:
. . . 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 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 provide 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.
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.
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 are 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 are 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 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 which are allocated for the source ports of protocol process. At times, applications which consistently allocate to ephemeral ports are targeted. For example, UDP port 1900 for SSDP has been targeting 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 with Operators who have deployed over the last decade is that deployment reduces risk to their business, their operations, and their customers while saving money with reduced customer support issues.
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 are a collection of examples. Notice that there are different ways to approach this requirement. Each approach is tuned to the Operator’s customers and 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 are a selection of 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 integrates their public statement on port filtering into their “Network Management Disclosure.” http://www.cableone.net/legal/network-management The statement (at the time of this document) states:
“As described above, 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 black hole in an effort to minimize the risk to their customers.
Centurylink has a long, comprehensive, public disclosure of their policies and practices. The detail is excellent with everything on one page.
CenturyLink is also a member of the Broadband Internet Technical Advisory Group (BITAG). 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 to the customer what is happening and becomes a tool for their customer support to interact with the customer. Additional ‘exploited’ ports can be added over time.
Find out which ports are blocked by XFINITY and Comcast services, and why.
Find the Reasons for Blocking Listed Below
|Port||Transport||Protocol||Direction Downstream/ Upstream to CPE||Reason for Block||IP Version|
|0||TCP||N/A||Downstream||Port 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|
|25||TCP||SMTP||Both||Port 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|
|67||UDP||BOOTP, DHCP||Downstream||UDP 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|
|TCP/UDP||NetBios||Both||NetBios 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|
|161||UDP||SNMP||Both||SNMP is vulnerable to reflected amplification distributed denial of service (DDoS) attacks.||IPv4/IPv6|
|445||TCP||MS-DS, SMB||Both||Port 445 is vulnerable to attacks, exploits and malware such as the Sasser and Nimda worms.||IPv4/IPv6|
|520||UDP||RIP||Both||Port 520 is vulnerable to malicious route updates, which provides several attack possibilities.||IPv4|
|547||UDP||DHCPv6||Downstream||UDP 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|
|1080||TCP||SOCKS||Downstream||Port 1080 is vulnerable to, among others, viruses, worms, and DoS attacks.||IPv4/IPv6|
|1900||UDP||SSDP||Both||Port 1900 is vulnerable to DoS attacks.||IPv4/IPv6|
Cox Communications has 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:
Cox is able to state the reason upfront, in a way that 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 from 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 against attacks on other computers by way of the Internet. In addition to being in our best interests for protecting our bandwidth, Cox considers preventing the abuse of our network as its responsibility.
Recommendation: Operators do not need to do only one Public Statement for how they do Exploitable Port Filtering and SAV. There can be a page for legal disclosure along with a page focused on Customer Service Excellence (i.e. empower the customer and call deflection).
Other Example 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.
“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 login, 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
“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
“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.
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 on-line.
The key points with FICORA regulation:
- 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 in my network” is an excuse.
- 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.)
The following references are provided to help Operators with their exploited port filtering and Source Address Validation (SAV) deployments.
- Mutually Agreed Norms for Routing Security (MANRS)
- ISOC Anti-Spoofing Reference Page
- Broadband Internet Technical Advisory Group (BITAG) Uniform Agreement Report on Port Blocking (https://www.bitag.org/documents/Port-Blocking.pdf). A comprehensive guide for Operators to deploy ACLs to minimize the risk to Exploitable Ports.
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 make 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 <email@example.com>, Damian Menscher <firstname.lastname@example.org>, 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 email@example.com. 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 mean time, stay connected to the Senki Community to get updates on new empowerment and security insights..