Is blocking UDP and TCP sufficient to prevent unwanted network activity?

Question

I want to be 100% sure that my machine only connects where and when I want it to. If I use a firewall that blocks all UDP and TCP packets but those that I explicitly allow to pass, can I be 100% sure that my machine does not connect anywhere without my approval?

For example, if I did not know about UDP at all and only specified TCP rules on the firewall, I would still be vulnerable to malware and nasty spyware exploiting UDP packets. So technically speaking, is there any other means/protocols apart from UDP and TCP that can be used to communicate with a computer using wired/wireless network connections? Also, can UDP and TCP packets bypass firewalls?

The question has arisen when I installed Little Snitch on my Mac with OS Mavericks and noted that my machine tries to connect to various Apple and third party servers even though I told it that I did not want any info to be collected and sent. Some of the connections were obviously fine (e.g. ntp time syncs), but others were questionable to say the least. I know that hard/software manufacturers potentially can embed backdoors and snitches and so I am trying to figure out how feasible it is in theory (and practice) to have reliable/robust "border control" on my machine.

Answer 1

You said "I want to be 100% sure that my machine only connects where and when I want it to", but do you have a strategy for covering what is sent?

Blocking ports is always a good idea, but to browse the web you'd want to be able to connect out on port 80, and at that point malware has a way to communicate out. You realise this, so you block all IP address destinations too except ones that you allow; great, that should do it. You like stackexchange and want to post there, so you open up to the SE servers, and you probably want Google and some others. At this point you are already vulnerable because malware could send data from your machine to an account on stackexchange, google, or elsewhere by logging in to a specific account and storing base 64'd encrypted data in the account profile for later extracting. Having content filtering might work, but it could be hard to configure. Of course you'll be on the lookout for your firewall alerting to transfers at a time you didn't expect, but smart malware could wait until it sees you sending or receiving data from stackexchange, for example, and send data at the same time to appear to be part of your traffic. Would you then notice the extra connection and traffic, or just assume that it was your browser opening up more than one connection, which it will tend to do anyway?

I've deliberately painted a bleak picture that while improbable, is entirely possible, and so the answer to your question has to be a "No". The only sure fire safe thing is never to connect it to the Internet.

Answer 2

The following is only valid if an attacker is not able to control parts of your network, e.g. DNS servers or routers; if so, you are doomed anyway :)

If I use a firewall that blocks all UDP and TCP packets but those that I explicitly allow to pass, can I be 100% sure that my machine does not connect anywhere without my approval?

While you can be sure that your machine doesn't connect to servers/ports you did not allow, you cannot be sure that no back channel to attackers exists. If your machines have DNS allowed, the foot-in-the-door might be a covert DNS channel, even if you allow your own DNS servers only.

For an intro to covert channels, see "Detecting DNS-Tunnels" and "Covert Channels" by SANS Reading Room.

For example, if I did not know about UDP at all and only specified TCP rules on the firewall, I would still be vulnerable to malware and nasty spyware exploiting UDP packets. So technically speaking, is there any other means/protocols apart from UDP and TCP that can be used to communicate with a computer using wired/wireless network connections?

See SCTP, but this must be available on your machine (don't know about defaults).

Also, can UDP and TCP packets bypass firewalls?

Usually no, but if you have IPv4 and IPv6 enabled and configured your firewall for IPv4 only, then packets might get out via IPv6.

Otherwise, I don't know a way to bypass a packet filter.

Answer 3

cat /etc/protocols (on Linux) will show you all possible protocols; though it is likely (?) your kernel won't support all of them.

However the good news is that iptables, by default, acts on all protocols. So this line, which often comes at the end of your iptables.rules,

-A FIREWALL-INPUT -j REJECT --reject-with icmp-host-prohibited

rejects packets not just on all tcp/udp ports that were not explicitly allowed but on all protocols that were not explicitly allowed.

This all assumes no mis-configuration, or kernel bugs. It also doesn't consider devices that are not controlled by your kernel. E.g. a USB stick might look like a filesystem to the O/S, but use bluetooth or wifi under the surface. (Either as a public feature, or without your knowledge.) (Other people have already mentioned tunnelling.)

Answer 4

A lot of misinformation in these answers.

If your firewall is blocking TCP for IPv4 / UDP for IPv4 then all it is paying attention to are IPv4 packets where TCP or UDP are specified. Most firewalls require further settings to block TCP and UDP for IPv6.

So we know about TCP and UDP, what about the rest of the IP protocols? Well here's a list of other protocols that your firewall may let through that all use IP and are valid for your router to send on.

Sure TCP and UDP are the most common, but even if you block all the other known IP protocols, what's to stop me using another protocol? How about the IPv4 Protocol 253, the Matthew protocol. So long as there's a valid IP destination it would still go to the right IP address.

Jumping into the world of tin foil hats, say you block IPv4 and IPv6 on your Firewall (you're worried about the Matthew protocol and all other IP protocols). Finally, what's to stop me just making an app that sends arbitrary data out from your network card and have something else on your network that interprets it? What's to stop me making a network card driver that writes raw 0s and 1s that I then decode elsewhere on your wire? Or writing Ethernet frames. Realistically to get past your router of course it would have to be speaking some form of IPv4 or IPv6 as routers tend to drop everything else (apart from replying to some ARP Ethernet frames).

I recently spotted Broadcomm using their own weird ARP frames on my local adapter (presumably for network teaming functionality) but weird never the less.

Answer 5

You've hit upon the reason why systems are air gapped. The main point is to stop someone siphoning data off your network, and it is easiest to classify the methods broadly and to realize that a holistic approach would be better.

1. Endpoint identification - includes whitelist of endpoints, dns/IP consistency
2. Wire protocol correctness - tunneling, non standard port/protocol, inconsistent packet sizes, signaling through non standard means
3. Application correctness - consistent application behavior.
4. User usage patterns - consistent user patterns

The main takeaway is: blocking is just the tip of the iceberg. You'll have to decide which posture to adopt based on the amount of time/effort/money you want to apply.

Answer 6

Blocking all TCP and UDP traffic is the equivalent of pulling the network cable out of the back of your computer.

Yes blocking TCP and UDP will stop unwanted connections from being made.... but its going to stop a lot of connections you do want.