Firewall not needed on non-server - correct?

[tomcloyd]

I just want to get confirmation of my understanding about this, from the wise heads in this community.

I am hosting nothing on my various boxes; I am led to believe by various things I've read that I therefore have no real need for a firewall.

Correct - or not?

Thanks!

[claydoh]

If you are using a router, you are extremely likely using a firewall already (if you haven't disabled it)
If not, you would be better to run one, or rather configure the one that comes with Ubuntu.

Much debate is possible on this, so I don't think there is a firm answer that suits everyone.

This may help a bit on deciding:
https://help.ubuntu.com/community/DoINeedAFirewall
https://wiki.ubuntu.com/BasicSecurity

[tomcloyd]

If you are using a router, you are extremely likely using a firewall already (if you haven't disabled it)
If not, you would be better to run one, or rather configure the one that comes with Ubuntu.

Much debate is possible on this, so I don't think there is a firm answer that suits everyone.

This may help a bit on deciding:
https://help.ubuntu.com/community/DoINeedAFirewall
https://wiki.ubuntu.com/BasicSecurity

Thanks! I had forgotten about the firewall in the router. And your links are to some decidedly useful articles. I'm plowing through them and learning a number of useful things.

Very helpful - and much appreciated!

Tom

[SteveRiley]

https://help.ubuntu.com/community/DoINeedAFirewall

Ooooooh boy! There is much wrong in that article. Time for a deconstruction. (Disclosure: I have worked in information security for nearly 20 years, starting with building my own firewall in 1995.)

I have no open ports, so I don't need a firewall, right?
Well, not really. This is a common misconception. First , let us understand what an open port actually is. An open port is a port that has a service (like SSH) bound and listening to it. When the SSH client tries to communicate with the SSH server it will send a TCP SYN packet to the SSH port (22 by default), and the server will ACKnowledge it, thus creating a new connection.

Correct so far.

The misconception in how a firewall can help you begins here. Some users assume that since you are running no services, a connection can not be made. So you do not need a firewall.

Everything except the first sentence is correct. Everything that follows the fourth sentence is wrong -- as we shall see.

If these were the only things you needed to think about, this would be perfectly acceptable. However, this is only part of the picture. There are two additional factors that come into play there. One, if you do not utilize a firewall on the basis that you have no open ports, you are crippling your own security because if an application that you do have is exploited and code execution occurs a new socket can be created and bound to an arbitrary port.

While true, home users with routers (wihch constitute the vast majority) are protected -- the NAT router has no knowledge that the computer now has a service listening on an arbitrary port. If someone on the outside tried to connect to the affected computer, the router would block this. It is necessary to create a rule in the router to pass inboud traffic.

The other important factor here is that if you are not utilizing a firewall you also have no outbound traffic control whatsoever. In the wake of an exploited application, instead of a new socket being created and a port being bound, another alternative an attacker can utilize is to create a reverse connection back to a malicious machine. Without any firewall rules in place this connection will go through unhindered.

At this point, your computer has already been p3wned. So why do you care about some kind of built-in firewall? Outbound control is security theater: I explain why in my article about the Windows Vista firewall (I worked in Microsoft's Trustworthy Computing Group for 11 years). A hacked computer can't be trusted; the firewall is no longer under your control; it could be doing one thing and telling you another. I've seen this first hand.

Article demonstrating how different types of firewall rules can be bypassed by an attacker.

Link rot.

If you were setting up a desktop system with best practices in mind you would want both strict inbound and strict outbound firewall rules. This would minimize the impact of either a listening service being bound or a reverse connection being initiated.

Adding such complexity to a desktop or laptop is a bad idea. First, it's unnecessary or doesn't work, as I've already stated. Second, it's more stuff you have to remember to manage. Being human, you are likely to make occasional mistakes or forget to do something. This adds to the system's brittleness -- that is, it makes the system easier to break.

Strong Outbound Rules for UFW Strong Outbound rules using UFW, GUFW or iptables

I've already explained why outbound rules will not stop an attacker.

You just said I have no services listening so then how can an application become compromised?
You need to understand what I (and others) mean when we say a listening service. When we are saying listening service we are referring to a persistent service listening for incoming connections, examples would be SSH, Apache, MySQL, FTP, VNC, and a myriad of other services you may have running.

OK, you've defined listening sockets. If it's one you want to accept traffic on, your firewall will have an opening. If it's one you don't, stop the service. If there's one you don't know about, your NAT router won't pass traffic anyway. What else?

However, you are exposed to creating a new connection to your system many times every single day. In fact, the act of loading this post alone created no less than 1 new connection to your machine, possibly more.

Wait, now the context is different -- here, the "new connection" is not "new" at all! The "act of loading this post":

1. Creates an outbound socket on LOCAL_IP : EPHEMERAL_PORT/tcp
2. Connects from that socket to UBUNTU_SERVER : 80/tcp
3. Asks the server to send some information
4. Receives that information from UBUNTU_SERVER : 80/tcp to LOCAL_IP : EPHEMERAL_PORT/tcp

There is no "new connection" opened here. The information coming to your PC is a reply to your request, and while it is a new flow, it uses the existing path established by your PC to load the page.

Now for a moment, assume that this wasn't Ubuntu Forums, and that it was a malicious site you accidentally visited. If this site were crafted in such a way that it could take advantage of a flaw in your browser, it could be used to execute malicious code on your machine. If this occurs a possible outcome would be to open a connection to another machine,

This is a completely different scenario than reading web pages. Malware got on my machine. That's possible these days via web browers, yeah. The malware makes a new connection, sure. It even follows the same generic outline as above. But it's the malware causing the problem as described next -- not simply the act of browsing.

so that machine could remotely access yours.

This is a remote access trojan (RAT). You will not typically know that the RAT is on your machine. It makes an outbound connection to some control server using a well-known protocol like HTTP, and the server replies -- again following the same basic sequence above. Software on the control server is designed to manipulate various elements of your machine as it makes replies over the path created by the RAT on your PC.

Strong firewall rules in some cases can help to mitigate that risk. If the packets used to create that connection are filtered by your firewall, the connection will never happen.

Here the argument returns to security theater. Any decent RAT will manipulate the firewall, too. That way, the RAT can make its connection without raising an alert. And remember: if your PC has malware, the game is already over.

Another example that you are likely exposed to would be maliciously crafted media files, or perhaps a malicious ODT or PDF file. These are all common vectors of attack, and something you are relatively likely to encounter. As we can see our firewall can mitigate some of this, however there are ways around it. If you read the article in the section about inbound and outbound rules it demonstrated how even a strong firewall can be bypassed. A firewall is a great tool for stopping automated exploitation, but as the article showed a dedicated attacker will find a way around this.

A host firewall is a terrible tool for stopping automated exploitation, because it's so easy to get around.

Thankfully we have a number of tools at our disposal to help mitigate risk further. We can contain what our applications can do utilizing mandatory access controls through applications like Apparmor. Apparmor can essentially harden your applications against a zero day exploit. Limiting what an exploited application can do, to its core functionality. Even if your application were compromised the attacker in theory would only be able to execute the innate functionality of the application.

Apparmor is path based (providing an escape mechanism for malware) and becomes relatively easy to circumvent. If you want to have an effective mandatory access control (MAC) policy, SELinux is the way to go. Yes, it's more difficult to configure, but it can be nearly entirely automated, thus eliminating concerns about mistakes from complexity. The nature of a MAC is to provide fine-grained control. A simplified mechanism like Apparmor, which interestingly enough isn't automated. is litte better than none at all. In fact, MAC tools on home machines probably have no benefit anyway.

[tomcloyd]

Steve, this looks like a serious contribution. Thank you for taking the time to work through it. Now, a request, please:

I (and others like me, now and in the future) have a seriously limited understanding of the basic elements of this discussion. Worse, this situation will not change, simply because my known major risks lie elsewhere: I'm in a demanding profession that literally absorbs just about all the time I can ever beg, borrow, or steal from the universe. Put simply, I can only ever do so much, and the people who depend on me expect that I will saturate myself with information OTHER than that which I need to fully grasp what you are talking about.

So, to make your contribution useful to as broad a spectrum of folks as possible, could you please reduce it to a procedure for us to follow? I could try to do this myself, but I don't really know enough to know that I have it right.

Just tell us what we need to do, if you can take just a little more time. "Do this - don't do that." THAT would be incredibly useful to me and us. I thank you for even considering my request. I'm here, frankly, because of the help of those who know far more than I ever will, and they've kept me in the game with Kubuntu. I'm VERY grateful, as this helps me help my customers, who are folks who really, really need help (I treat severe psychological trauma).

[GreyGeek]

There’s an important axiom of security that you must understand: protection belongs on the asset you want to protect, not on the thing you’re trying to protect against.
--Steve Riley

Great post (and article), Steve!

[tomcloyd]

Great post (and article), Steve!

That quote re: where protection belongs, alone, is the single most valuable idea I've gotten from all the reading I've been doing. I'm busy encrypting everything I need to be secure. This just solves so many problems, relative to data, anyway.

Of course, when what you're trying to protect is your CPU - that's a different issue.

[GreyGeek]

... Of course, when what you're trying to protect is your CPU - that's a different issue.

True. But, where are most computers made? And what is to prevent them from burning their own variation of the CPU microcode, even it is just to add a back door?
Open Source is no guarantee. Take the C compiler, for example: http://scienceblogs.com/goodmath/200...nis-ritchie-a/

[tomcloyd]

True. But, where are most computers made? And what is to prevent them from burning their own variation of the CPU microcode, even it is just to add a back door?
Open Source is no guarantee. Take the C compiler, for example: http://scienceblogs.com/goodmath/200...nis-ritchie-a/

Oh, but I leave it to the NSA to detect and howl about such issues!

My concern was more mundane: you can encrypt your data, but prevention of your CPU's being controlled by aliens...well, that's about firewalls and malware detection routines, yes? Now that I have the data problem solved (I hope) via encryption, I'm focusing on the CPU protection problem.

And as far as guarantees - I live in a Baysian universe. There are only probabilities. As a psychologist, I can assure you that decent research indicated that only about 30% of the population (highly educated folks included) can actually make and use decent representations of probability in their brain. Translation: the other 2/3 are susceptible to the belief that they can actually win at a casino! As for me, I only play gambles I think I really can win. This whole security jag I'm currently on is about improving probabilities, pure and simple.

[SteveRiley]

@tom, @GG: thanks for your kind words.

@GG: at some point, we as users of technology have to trust something. For most of us, it's the hardware and the compiler. If you don't trust your compiler, Google will help you find guidance for bootstrapping your own compiler. But the hardware? It's nearly all the equivalent of a closed black box.

@tom: A guide to easy security is good idea. I'll start putting together a few thoughts.

[tomcloyd]

@tom: A guide to easy security is good idea. I'll start putting together a few thoughts.

No no, not a guide to easy security. An easy guide to hard security. Maybe even hardened?



Thanks Steve. I'll be very interested to see what you come up with, and will, you may be assured, make the best possible use of it. I hope it can be made easily accessible for others, as well.

Tom

[SteveRiley]

A case of misplaced modifiers! Better: An easy guide to effective security. I'll post it to KFN for everyone to read.

[Goeroeboeroe]

Such a guide would really be great! I've found information on a lot of places, but I find it very difficult to judge if that information is without mistakes.