If you’re running a laptop with a local web server for development, you wouldn’t want other devices in i.e. the coffee shop WiFi to be able to connect to your (likely insecure) local web server, would you?
This is a fair point that I hadn’t considered for the mobile use-case.
Imagine a family member visits you and wants internet access in their Windows laptop, so you give them the WiFi password. Do you want that possibly malware infected thing poking around at ports other than 80 running on your server?
Fair point!
note that you likely do have applications listening on ports you didn’t know about. Take a look at sudo ss -utpnl.
Interesting! In my case I have a number of sockets from spotify, and steam listening on port 0.0.0.0. I would assume, that these are only available to connections from the LAN?
It’s rather the other way around; you don’t want the outside world to be able to talk to untrusted software on your computer. To be a classical “door”, the application must be able to listen to connections.
OTOH, smarter malware can of course be something like a door by requesting intrusion by itself, so outbound filtering is also something you should do with untrusted applications.
It could also be malicious software that simply makes a request to a remote server – perhaps even siphoning your local data.
If it turned out your window could easily be opened from the outside, you’d rather have razor fence in front until you can replace the window, would you?
That’s a strange law. That’s like saying one should be held responsible for a thief stealing their car and then running over someone with it (well, perhaps an argument could be made for that, but I would disagree with it).
Seriously, unless you are extremely specialized and know exactly what you are doing, IMHO the answer is: Always
In what capacity, though? I see potential issues with both server firewals, and client firewalls. Unless one wants their devices to be offline, there will always be at least one open port (for example, inbound on a server, and outbound on a client) which can be used as an attack vector.
Tell the computer explicitly which ports it can and cannot open.
Isn’t this all rather moot if there is even one open port, though? Say, for example, that you want to mitigate outgoing connections from potential malware that gets installed onto your device. You set a policy to drop all outgoing packets in your firewall; however, you want to still use your device for browsing the web, so you then allow outgoing connections to DNS (UDP, and TCP port 53), HTTP (TCP port 80), and HTTPS (TCP port 443). What if the malware on your device simply pipes its connections through one of those open ports? Is there anything stopping it from siphoning data from your PC to a remote server over HTTP?
I see. I guess my point was they exist for a reason, as the default target of one zone handsover to the next zone (target) and then its target, in order to handle traffic not in your zone rules.
Yes, I am aware of that. Just allow the user to specify the zones though. Why force the default ones?
but it is not causing “bloat”.
It is if it’s saving alternative configuration that will never be used.
Sure, that is why we have defaults, but why force them? Why not create the defaults, and then allow the user to remove them if they wish?
You’re free to patch it out if you’re so inclined.
This is somewhat of a non-answer. Technically, yes, it is possible for a user to patch OSS as they see fit, but that does not excuse poor design desicions, nor is it necessarily fair to expect the user to do that.
I believe you may have misinterpereted my post. I wasn’t asking why zones exist, I was asking specifically why one cannot delete the default zones in Firewalld.
I’m not exactly sure what the previous issue was, but it appears that, possibly, the previous bridge that was in use was broken in some way. I have since switched the primary router to one that supports WDS, and created a WDS bridge between the two, and now everything is working as expected.
when I installed Ubuntu, it was installed on a partition (sda2) rather than a primary drive (sda)
The exact meaning of the language in use is somewhat context dependent. It is technically possible to use a block device (e.g. /dev/sda) [source] as a filesystem, but it is generally discouraged – afaik, this is generally because of compatibility reasons. As to the meaning of a statement that looks something like “Install Ubuntu to /dev/sda” this could be interpereted as essentially just rewriting the existing partition table that exists on that drive with a new one, where, for example, partition 1 (e.g. /dev/sda1) is for the boot partition, and partition 2 (e.g. /dev/sda2) is where Ubuntu lives. In that example, technically Ubuntu is only resides in /dev/sda2, but, for the whole installation process, the user can interpret it as essentially installing it all to /dev/sda.
I’ve read that when GRUB is installed, if it gets installed to /dev/sda2 rather than /dev/sda it can cause issues with dual booting as the BIOS will read in a sequential order, and it may miss a partition if it’s “far enough down the list”
It’s worth understanding the boot process of a system (this is more taylored to an average Linux system, but can be generally applied, if one is careful):
The machine powers on
The BIOS chip on the motherboard comes to life, it gets copied into RAM, and the CPU starts executing it.
It finds the first device in the BIOS boot list
It looks at the first sector (512 bytes) of that drive (this generally only applies if the drive uses MBR, and can be a little bit different with GPT, but the general process is pretty much the same, afaik), which contain the location of the bootloader on that drive, and copies it to RAM at address 0x7C00
The bootloader (e.g. Grub) springs to life and it takes over the boot process from the BIOS
In the case of your average linux installation, Grub will then initialize something called the “initramfs” which is sort of like an extremely small Linux OS that gets loaded into RAM
Initramfs essentially bootstraps the actual Linux distro into booting – this is required as booting the desired Linux distro may depend on things that run on Linux which can’t exist before Linux is loaded (e.g. LVM’s, LUKS encryption, etc.).
Now that the OS is loaded into ram, it boots, and the process is complete.
So, back to your statement, the actual program of Grub could reside in /dev/sda2, but the “bootloader bootsrapping” program, which resides in the first 512 bytes of the disk, could be thought of as being installed to /dev/sda.
I guess I must have gotten my preconceptions wrong, or perhaps I misread something. From my impression, certain things can be installed on the primary drive such as boot loaders, but I could be wrong.
As I outlined above, this is sort of a technicality in language that depends on context.
Finale 2012c is the main software I needed.
I’m not sure if this is exactly equivalent to that software, but perhaps you would be interested in MuseScore – it’s open source.
I’ve heard it can be pretty challenging to get into Arch, is this true?
This has been somewhat exaggerated through memes by the community, and strange elitism. It’s a bit tough to separate oneself from their curse of knowledge, but if one possesses the motivation to learn, it’s really not that complicated. Depending on one’s existing knowledge, it may initially appear daunting, but the community is quite good, from my experience, and the Arch Wiki is extremely useful. Installation is essentially a matter of just following the installation guide step-by-step.
I don’t know if I’ll ever be a “script kiddie” as it were.
Imo, arch has nothing to do with that. If one wants to be a part of that then prob lurking around the Kali Linux communities would be a start. Do note that I am not speaking about Kali Linux from experience, just hearsay, so take that with a grain of salt. But, yeah, Arch is more for people that want more fine-grained control over their system without wanting to get into the full-time job that is something like Gentoo 😜.
I don’t know how much I like the idea of having to hand-craft my OS from bare metal.
Imo, that’s not really what arch is – even Gentoo isn’t like that. The closest to that would probably be something like Linux From Scratch. Arch just gives you more freedom to choose the base software that your system is using – stuff like your DE, your networking utils, display server, audio server, etc.
I would like to emphasize that this kind of choice exists with virtually all Linux distros – as in you can essentially make any distro “look” like any other (there may be some intricacies that I am unaware of that may get in the way of changing some things without having to alter others); Arch Linux simply gives you most of the choice right up front.