0

From what I can see, most firewalls seem to focus on tcp and udp. Why is that? Is it impossible or at least very unlikely for malware to use other protocols/custom protocols?

DevShark
  • 331
  • 1
  • 10

2 Answers2

4

In order to use a different protocol, your program must be able to open a socket of that type.

Typically, only TCP and UDP sockets can be opened by non-system programs.

When you try to open e.g. an ICMP socket as non-root, that will simply fail. Also, even if you could, chances are the network stack will just not know what to do with your packets and drop them on incoming.

Nor will routers even route these packets to you.

So, there's no attack or exfiltration surface here, because someone able to open a non-TCP or UDP socket can typically also reconfigure the firewall running on the same computer.

Non-TCP or UDP packets are typically not forwarded by routers, so that's kind of an inherent "drop all" firewall. ICMP is an exception, but that being pretty well-covered by firewalls, too.

There's a few speciality protocols (SCTP comes to mind) that are in use but neither TCP nor UDP, but honestly, when you're configuring your computer to allow a non-superuser to open such sockets, you might as well add specific rules to your firewall to allow these packets through: you're likely operating a backbone network.

Marcus Müller
  • 5,843
  • 2
  • 16
  • 27
  • Thanks for your answer! I am still not sure if I should discard this risk. I could imagine 1) a malware on the machine opens a tcp or udp socket, but then uses that socket to send data not on tcp or udp. 2) a malware can run as a superuser but is not targeting specifically the firewall. – DevShark Jan 18 '20 at 01:28
  • @DevShark when you open a UDP or TCP socket, then you only have the freedom to define what's transported via UDP or TCP. And you only receive packets for the matching UDP or TCP socket in the other direction. Your fear therefore stems from a lack of understanding of how the layers of your network stack operate. If your malware is running as superuser, it's game over. Nothing to protect anymore. Again, sure, that malware can open an SCTP socket, and then send data that your router will simply discard. Again, there's nothing to do here. – Marcus Müller Jan 18 '20 at 01:31
  • I see, ok thanks. – DevShark Jan 18 '20 at 07:09
  • _"Nor will routers even route these packets to you"_ Do routers (true routers, not stateful firewalls) really check things above the network layer? – multithr3at3d Jan 18 '20 at 15:24
  • @multithr3at3d well, by strict definition of the word routing, you're right, they're working a level below TCP; but, I really meant in the context of a system where a network is connected to the rest of the world through a router, that router kind of inherently gets the role of a firewall (it takes a kind of bigger network to demand for a separate firewall appliance) – Marcus Müller Jan 18 '20 at 16:08
2

Here’s the Cisco ASA “IP access-list extended” syntax when no ports or ICMP types are involved. You can specify a number from 0-255 in the “protocol-argument” to completely block that protocol.

access-list access_list_name [ line line_number ] extended { deny | permit } protocol_argument [ user_argument ] [_group_argument ] source_address_argument [ security_group_argument ] dest_address_argument [ log [[ level ] [ interval secs ] | disable | default ]] [ time-range time_range_name ] [ inactive ]

It is common to block IP-in-IP and IPv6-in-IPv4 and GRE in both directions to decrease the risk of unauthorized tunnels into an enterprise network.

The firewall also usually has a default “deny IP any any” applied to ingress traffic which blocks all IP protocols unless expressly permitted.

Darrell Root
  • 1,462
  • 1
  • 7
  • 8