In networking, protocols are like laws, contracts or agreements which specify how aspects within systems are designed and agreed to work. This is so that those that abide by them can utilise the mutual assurances such as “Confidentiality, Integrity and Availability” of data (Pawar et al, 2015).
Changing the rules so to speak and therefore breaking protocol rules affects those assurances and allows the instigator an unauthorised and unfair advantage, usually at the expense of others - and often illegally.
In law, just as in cyber security, being technically able to break the rules is no the justification for doing so. For instance, in the Computer Misuse Act 1990, it is explicitly stated that Unauthorised access and/or manufacturing of ‘articles’ (such as Trojans, Viruses etc) that may aid in breaking the rules carry hash penalties, irrespective of the means in which it was conducted. I will briefly discuss how some of the protocol and network rules are broken by attackers and what is in place to try prevent these circumventions of policy.
Many network attacks are based on weaknesses and “vulnerabilities of allowed protocols” (Anderson et al, 1997), and are exploited based on “packet forging” techniques where irregular, custom authored packets are injected into the network which cause systems to malfunction jeopardising the previously mentioned assurances (Hoque, et al, 2013).
Attacks of this nature include ARP cache poisoning, VLAN hopping and MAC Flooding - where manipulating packets by spoofing sender or recipient details(or embedding additional content) - instruct systems to send undesignated data to the attacker’s machine (Confidentiality).
Other similar packet-based ‘Denial of Service’ attacks, introduce rogue packets into the network which are out of sequence, irregular and lead to overloading target systems resources, disrupting normal service (Availability). Examples of which include, “flooding, smurf, fraggle, jolt, land and ping-of-death” (Hoque et al, 2013) as well as DNS amplification/ reflection and DHCP starvation attacks.
In addition to these attacks, packets can be crafted to contain embedded payloads of malicious intent such as malware like viruses, trojans, worms and user-crafted scripts, code and attachments, which can infiltrate network nodes and operate from them.
At almost every layer in the OSI model, protocols are vulnerable to these types of attacks (Bransad, 1986) however traditionally they concentrate on IP or layer 3 (Umasuthan, 2016)
Growth and dependence on Firewalls
Firewalls play a key and increasingly (Nacht, 1998) important part in protecting against some these types of attacks, specifically protecting against unauthorised internal and external access, Compromising authentication, Spoofing, Session stealing and Tunnelling and can limit the amount of damage caused by an attacker (Anderson et al, 1997)
Firewalls, fail however at protecting against other attacks such as denial of service attacks, embedded payloads such as malware - fundamentally falling to understand the underlying intention, legitimacy and context of packet traffic when comes to detecting malevolent traffic and“ill-suited to handle executable content” (Anderson et al, 1997).
Many of these shortcomings are purposefully addressed by Intrusion Prevention and Detection systems (IPS/IDS) which, unlike network firewalls analyse the contents and context of packets for malicious payloads and abnormal transmission behaviour.
One interesting, however worrying, aspect of these systems is that they designed to protect you from the past - using previous attack signatures, behaviours and indicators for future attacks mitigation. However, as any economist knows, the past is no predictor of the future and they do little against “Day zero” attacks (Samtani et al, 2017). On the other hand as Mark Twain said once, "For the majority of us, the past is a regret, the future an experiment" and it of this future and experimentation I now turn your attention.
It is increasingly becoming important to understand the nature of the new attack before it happens.
For example, research indicates that gathering information(which could arguably be used in IDS/IPSs learning algorithms) on what attackers are talking about now, what they are sharing with each other and analysing their content: discussions, keywords and the code exchanged and hosted on hacking forums can go some way in detecting and predicting zero-day attacks, especially if combined with IDS/IPS systems. (Samtani et al, 2017)
While IPS/IDS and “Firewalls do not prevent external attacks on a network” (Anderson et al, 1997), layer 2 security can - by preventing those obtaining access to the network in the first place - through 802.1X port security and other layer 2 mitigations.
Network switches must be protected against being targets: It’s important to restrict malicious requests such as gratuitous ARP requests - which flood switch CAM tables, by implementing measures like Dynamic ARP Inspection or limiting known/trusted MAC address(port security) and preventing untrusted sources of network services such as DHCP being deployed on the network. That latter can be prevented through implementing mitigations like DHCP Snooping and maintaining a credible list of source addresses through IP Source guard -which can help against mitigating the spoofing of network packets, and being certain where known devices and services originate from.
An interesting perspective on the problem of network security is design. It is an important factor as indicated by the fact that “most key internet protocols such as ICMP, TCP, TELNET and HTTP have bugs.” (Hoque, 2017). Others were not originally designed with security in mind at all like TELNET and DNS and like the latter has been unable to adapt with ever changing security lanscape, perhaps in part due to failed attempts to retrofit security as is the case with DNSSEC (Hertzberg, 2014).
Furthermore, misconfiguration of security systems such as ACLs used to setup IPSEC and firewall policies can “…result in illegitimate traffic being allowed into the network” and “increasing the network vulnerability to various network attacks such as port scanning and denial of service” (Hamed et al, 2006).
Reliance on firewalls for network security is a partial solution, understanding design, context and forward thinking coupled with and the ability to adapt and introduce flexibility is key to protecting against the future. The majority of attacks occur when the attacker is already on the network and protecting against physical access can mitigate all these kinds of attacks and so must be considered in any network security policy
[1020]
Umasuthan, V. (2016) ‘Protecting the Communications Network at Layer 2’, in 2016 IEEE/PES Transmission and Distribution Conference and Exposition (T&D). IEEE, pp. 1–5. doi: 10.1109/TDC.2016.7519889.
Anderson, J. . et al. (1997) ‘Firewalls: an expert roundtable’, IEEE Software. IEEE, 14(5), pp. 60–66. doi: 10.1109/52.605932.
Nacht, M. (1998) ‘The spectrum of modern firewalls’, Computers & Security. Elsevier Ltd, 17(1), pp. 54–56. doi: 10.1016/S0167-4048(97)80250-7.
Branstad, D. K. (1987) ‘Considerations for security in the OSI architecture’, IEEE Network. IEEE, 1(2), pp. 34–39. doi: 10.1109/MNET.1987.6434189.
Samtani, S. et al. (2017) ‘Exploring Emerging Hacker Assets and Key Hackers for Proactive Cyber Threat Intelligence’, Journal of Management Information Systems. Routledge, 34(4), pp. 1023–1053. doi: 10.1080/07421222.2017.1394049.
Pawar, M. V. and Anuradha, J. (2015) ‘Network Security and Types of Attacks in Network’, Procedia Computer Science. Elsevier B.V, 48(C), pp. 503–506. doi: 10.1016/j.procs.2015.04.126.
Hoque, N. et al. (2014) ‘Network attacks: Taxonomy, tools and systems’, Journal of Network and Computer Applications. Elsevier Ltd, 40(1), pp. 307–324. doi: 10.1016/j.jnca.2013.08.001.
Herzberg, A. and Shulman, H. (2014) ‘Retrofitting Security into Network Protocols: The Case of DNSSEC’, IEEE Internet Computing. IEEE, 18(1), pp. 66–71. doi: 10.1109/MIC.2014.14.
Hamed, H. and Al-Shaer, E. (2006) ‘Taxonomy of conflicts in network security policies’, IEEE Communications Magazine. IEEE, 44(3), pp. 134–141. doi: 10.1109/MCOM.2006.1607877.