Arch Linux, rolling Linux distribution, would give you the newest stable software, with probably new application features, but you can use distrobox, podman-toolbox, VirtualBox, KVM (QEMU) or a live Linux cd image to play with Arch Linux every now and then, without having to install it :)
I used to “virtual distro hop” because I tried a lot of distros in VMs before dualbooting. I installed Tumbleweed and haven’t changed ever since.
I don’t regret keeping my distro, I’ve been curious, of course, but I think i already have it all:
Stability
The newest updates
I know my system very well
By knowing my system, I can fix most problems and I know where to go if I can’t.
I sometimes try distros in VMs, but with that and Distrobox I think I already have everything I could need to learn and try them in case I need to work with them in the future :)
As i see it, the term “firewall” was originally the neat name for an overall security concept for your systems privacy/integrity/security. Thus physical security is (or can be) as well part of a firewall concept as maybe training of users. The keys of your server rooms door could be part of that concept too.
In general you only “need” to secure something that actually is there, you won’t build a safe into the wall and hide it with an old painting without something to put in it or - could be part of the concept - an alarmsensor that triggers when that old painting is moved, thus creating sort of a honeypot.
if and what types of security you want is up to you (so don’t blame others if you made bad decisions).
but as a general rule out of practice i would say it is wise to always have two layers of defence. and always try to prepare for one “error” at a time and try to solve it quickly then.
example: if you want an rsync server on an internet facing machine to only be accessible for some subnets, i would suggest you add iptables rules as tight as possible and also configure the service to reject access from all other than the wanted addresses. also consider monitoring both, maybe using two different approaches: monitor the config to be as defined as well as setup an access-check from one of the unwanted, excluded addresses that fires an alarm when access becomes possible.
this would not only prevent those unwanted access from happening but also prevent accidental opening or breaking of config from happen unnoticed.
here the same, if you want monitoring is also up to you and your concept of security, as is with redundancy.
In general i would suggest to setup an ip filtering “firewall” if you have ip forwarding activated for some reason. a rather tight filtering would maybe only allow what you really need, while DROPping all other requests, but sometimes icmp comes in handy, so maybe you want ping or MTU discovery to actually work. always depends on what you have and how strong you want to protect it from what with what effort. a generic ip filter to only allow outgoing connections on a single workstation may be a good idea as second layer of “defence” in case your router has hidden vendor backdoors that either the vendor sold or someone else simply discovered. Disallowing all that might-be-usable-for-some-users-default-on-protocols like avahi & co in some distros would probably help a bit then.
so there is no generic fault-proof rule of thumb…
to number 5.: what sort of “not trusting” the software? might, has or “will” have: a. security flaws in code b. insecurity by design c. backdoors by gov, vendor or distributor d. spy functionality e. annoying ads as soon as it has internet connection f. all of the above (now guess the likely vendors for this one)
for c d and e one might also want to filter some outgoing connection…
one could also use an ip filtering firewall to keep logs small by disallowing those who obviously have intentions you dislike (fail2ban i.e.)
so maybe create a concept first and ask how to achieve the desired precautions then. or just start with your idea of the firewall and dig into some of the appearing rabbit holes afterwards ;-)
Linux Mint is my daily driver. I enjoy tinkering, but I also want a distro that doesn’t need it when I get home from work and just want a vodka tonic and some memes.
“Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface. All the systemd “cloud of daemons” is tightly coupled by dbus interfaces that enable an attacker to move from one exploited system service to the next. Even if the attacker doesn’t manage to find an exploit in another system service, DoS is easily possible because the DBUS interfaces are quite fragile. Even as a benevolent admin it is easily possible to get the system into a state where e.g. clean shutdown is no longer possible because systemctl doesn’t want to talk to systemd any longer and you cannot fix that. systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors. At the very least I would, for hardening, recommend not using any network-facing systemd functionality.
And lines of code are not ridiculous, they are the best first-order estimate available. Of course an actual inspection of the code is better for a comparison, but that is a huge task. sloccount is quick and easy.”
err, why would a forum post single-handed prove that the entire linux enterprise world are being stupid, and how you can prove that he is even correct?, he is alone, against the entire world, red hat sell that shit, if it wasn’t secure companies wouldn’t buy it
I am not saying this proves single-handedly that systemd has vulnerabilities but it is one of probably many out there. I am not saying enterprise is stupid but I could definitely see some sacrifice being possibly made to spend less time setting up utilities on every systemd machine for enterprise work.
I could definitely see some sacrifice being possibly made to spend less time setting up utilities on every systemd machine for enterprise work.
I’m not sure how much time do you think anyone spends setting up systemd utilities… but as a home admin systemd has saved me a ton of time over the ragtag collection of shell scripts we had in the past. And a lot of that is because of its vastly improved logging.
I suppose if you consider logs to be “bloat” you won’t understand though. I consider them to be essential services.
I was saying that you do spend less time cause it is already there. Also you can have logs on other init systems, what I said on the post is that if later I wanted logs I could just setup instead of being already there (and the other utilities, not just the logs of course).
s6/66 simplifies dependency of running/starting, automatically enables an s6-log for each service/daemon/bundle it is much faster and smaller than systemd (by a factor of 10 maybe), and once it is up and running it is virtually impossible to bring down without its own routine. Servers have run consistenly for a decade with s6, including skarnet.org
OP said they were not looking for Ubuntu or Arch derivatives, and that they were not afraid to get their hands dirty to figure things out. Slackware + Flatpaks can give a stable base while giving you up-to-date applications when SBo doesnt have the build files. This would give OP a system that just works OOTB. Tho it is KDE OOTB, one can put gnome or cinnamon on it.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.