You asked three questions:
- Requested general understanding of firewalls
- How do stateful firewalls protect against non-udp-tcp protocols?
- Can data exfiltration occur over non-udp-tcp protocols?
Understanding firewalls background
Firewalls (as opposed to routers with access-lists) are stateful devices. When a socket is initiated in one direction, the firewall remembers the socket and allows the return traffic without a return-traffic permit rule.
A basic firewall can understand the following socket information:
- IPv4 versus IPv6
- IP protocol (0-255, 1=icmp, 6=tcp, 17=udp)
- Source IP
- Destination IP
- Source Port (for tcp and udp only!)
- Destination Port (for tcp and udp only!)
Lets say you want to permit Wi-Fi calling (UDP/4500) outbound from your network (192.0.2.0/24). With a stateless router ACL you would do this:
permit udp 192.0.2.0/24 any eq 4500 // implied source port any
permit udp any eq 4500 192.0.2.0/24 gt 1023
That is the best you can do. And it's AWFUL. Now any outsider can probe your network with UDP just by setting their source port to 4500. You mitigated the problem by denying the low ports, but there are vulnerable applications listening on higher ports.
With a stateful firewall you can do this:
permit udp 192.0.2.0/24 any eq 4500
no rule needed thanks to stateful firewall!
Return traffic on sockets initiated outbound will be permitted.
Traffic initiated inbound will be denied.
TCP ingress with a stateless ACL is much easier to protect than UDP. Lets say you want to permit your internal users to ssh to the internet:
permit tcp 192.0.2.0/24 any eq 22
permit tcp any any established ! more maintainable
permit tcp any eq 22 192.0.2.0/24 established ! more specific, less maintainable
The bad guys may be able to manually set established bits and get them into your network, but they won't be able to complete any 3-way handshakes inbound.
Protecting against non-udp-tcp protocols:
A well configured firewall will have "deny by default" configured on ingress:
[a bunch of specific ingress permits as needed for the business here]
deny ip any any
That matches all 256 inbound protocols. So a correctly configured firewall protects your network from other protocols inbound.
One complexity is ICMP. You want to permit ICMP MTU-exceeded inbound, but deny ICMP echo-request inbound. There have been ICMP exploits in the past (ping-of-death). Stateful firewalls are smart enough to permit icmp-echo-reply ingress, but MTU-exceeded is harder.
Blocking "unknown" protocols outbound is also common. You permit icmp, tcp, udp, and some VPN-related protocols initiated outbound. Block other protocols outbound until someone calls the helpdesk. Then (networking + infosec) decide whether to permit the other protocol based on the business need.
Data exfiltration over non-UDP-TCP protocols
Yes. Data can be exfiltrated over non-udp-tcp protocols. Especially ICMP. PCI expressly forbids unrestricted access to the Internet. The first thing a PCI auditor will do is try to ping an internet host from an in-scope PCI system. If the ping succeeds, that requires remediation. If the PCI host can websurf unrestricted, that's also a fail.
Normal network practice is to deny-by-default egress to the Internet from datacenter hosts. If a host needs to access a specific internet server (a credit card provider for example) that's ok: but make the permit specific to the destination.
Desktop hosts usually can surf the internet (egress) without restriction. Just don't let your desktop hosts get to your datacenter hosts without good authentication (I like having a restricted VPN service for the datacenter).
I sometimes wonder about data exfiltration via DNS request. For example: the hacker on your compromised database server does a DNS-lookup for www.evildomain.com/123456789abcd where that's a credit card number.
One warning about blocking non-icmp-udp-tcp protocols: don't forget to permit the routing protocols (OSPF for example) if needed. But that's just at the link-layer: no need for a "permit ospf any any".
Firewall DDOS weakness
While stateful firewalls are useful, if hostiles can fill up their state table they can inflict a denial-of-service. So I recommend putting stateless ACLs in front of the public-facing website loadbalancers (where you are expecting unrestricted inbound connections anyway).