Learning about attack vectors nftables, appamor, etc protect against?

DocPrinter · 2026-08-10 19:02:27

Hi all,

I'm looking to understand the problems better, so I can appreciate the solutions. For example I think fully encrypted drives are primarily protecting against unauthorised data access - and potentially full access if using bios/boot vunerabilities - after someone has gained physical access to your system.

Just hone through my second and third arch installs picking uo quite a bit as I went through.

After these installs I wanted to learn a bit more about security best practices and I found it very hard to read through descriptions of things like apparmor without a base understanding of the attact vector that it is trying to negate. Likewise I understand that open ports with no software behind them is bad, but don't really understand how that can make a system vunerable. In a simplistic (& wrong) view of it would be nothing there to answer the port so messge simply ignored. That wouldn't be much of security problem though.

Where are the best places to read up on this generally, and not pages of posts discussing fixes in fine detail for specific problems?

I've been relying on Linux being the less targeted system a bit too much and now want to make ammends!

Thanks.

seth · 2026-08-10 19:43:46

https://wiki.archlinux.org/title/Security
https://wiki.archlinux.org/title/Nftables
https://wiki.archlinux.org/title/AppArmor
https://wiki.archlinux.org/title/Data-a … encryption

nftables is about remote access attacks (firewall), apparmor about local privilege escalation (jailing), "fully encrypted drives" are data at rest protection (hardware access denial, I can steal your notebook, but I still can't boot some live distro and be defacto root in your system)

"open ports with no software behind" is not a thing - a port is open because something's listening there.

loqs · 2026-08-10 22:51:44

seth wrote:

"open ports with no software behind" is not a thing - a port is open because something's listening there.

For completeness ports only exist at the transport layer and above. Protocols that stay on layer 3 such as ICMP/IGMP/ESP do not use ports.

dimich · 2026-08-11 06:32:01

Also for completeness, people sometimes confuse logical port state and visibility.
For example:
Nothing listens on port, no firewall (or accept action): port is closed. However, IP stack replies with ICMP "destination port unreachable", so host reveals it's presence. Sometimes people call it "open".
A process listens on port but drops unauthorized datagrams: port is opened but unreachable for unauthorized peers. Nmap shows "open|filtered".
A process listens on port but firewall drops packets destinated to this port: port is opened but people call it "closed".
Nothing listens on port but firewall drops packets destinated to this port: ports is closed but nmap also shows it as "open|filtered".

In short, to avoid confusion the context needs to be clarified.

Last edited by dimich (2026-08-11 06:40:27)

DocPrinter · 2026-08-11 06:50:13

Thanks for the links. I'd read through a lot of them but found them confusing as the assumed level of knowlege of the target audience is greater than my own.

For example (non exhaustive list):
* It assumes the reader understands the issue with malloc that creates the need for hardened malloc.
* It introduces run0 and sudo-rs as alternatives for sudo without explaining in much detail what the issue with sudo is.
* Discussion about going SUID-free without really discussing how SUID was leveraged to access a system, and gives vague warnings about some programs may need SUID.

I'll go in search of some better explanations of typical linux architechtures. Fortuitously I've just stumbled on this site which may help fill a few blanks:

https://www.hackingarticles.in/linux-pr … -binaries/

I've adopted arch in my systems as it forces me to learn more about linux, but understandably the topic is vast. I've been using linux for over 15 years but at a level a bit more advanced than the average office worker running windows. There's a bit of a casm between user level and administrator/developer level.

I'm going to ask my local bookshop to get the 3 books by William D Brown Arch linux in.

With regards to my open port comment so no issue with a router for example forwarding a specific port to a local machine with nothing listening to that port on the local machine? I always struggled to understand why software listening to ports often don't fail safe.

seth · 2026-08-11 07:15:08

The wiki provides an oversight, an exhaustive document on the topic would fill two libraries.
You'll be constantly hardening the system and it will never be hard.
This is however typically not required or useful for Joe User's desktop.

* https://github.com/GrapheneOS/hardened_malloc explains a bit about the malloc situation

* The problem w/ sudo is in its complexity, ie. chances you're gonna fuck up some non-trivial configuration and open the system are relatively high. It also make it more prone to bugs in interpreting/implementing the rules.
Not that it's a SUID binary.
* The problem w/ suid is not the suid processes you know about but the ones you don't (ie. suid allows a malicious binary to "silently" run w/ elevated privileges)
* The problem w/ run0 is that this has always been BS propaganda, https://github.com/systemd/systemd/issues/32757
* run0 (which was introduced as shortcut to a feature systemd provided long before that publicity stunt) has implications beyond privilege escalation (notably the context isolation)
* you can also look into https://archlinux.org/packages/extra/x86_64/opendoas/ as a simpler alternative to sudo (polkit is *at least* as complex as sudo)

no issue with a router for example forwarding a specific port to a local machine with nothing listening to that port

I'm not sure what you envision here but you could exhaust the package buffer on either end depending on how you misconfigure it.
But if you configure port forwarding on your router (eg. send cold inbound on #22 to 192.168.1.16 but ssh simply isn't running on 192.168.1.16 or 192.168.1.16 isn't even up) that port isn't "open" and leaving aside glaring bugs in your router, there's no harm to any party involved.
Can you detail an example setup and what you're worried might happen there? Or provide a reference to the source of your assumption?

dimich · 2026-08-11 07:21:42

DocPrinter wrote:

With regards to my open port comment so no issue with a router for example forwarding a specific port to a local machine with nothing listening to that port on the local machine?

There are potential flaws, assuming no bugs and backdoors in network stack implementation itself on router and local machine.
If someone scans your router from outside, and there is no firewall configured (or misconfigured) on router and on local machine, local machine replies with ICMP "destination port unreachable". This reply forwards back to scanner's host, so it becomes clear that there is something alive on your router's IP address. In some cases this is not desirable.
If someone floods this port from outside, it floods LAN and local machine as well. Moreover, "destination port unreachable" multiplies that flood.
If for any reason local addresses changed and some other local machine got that local address and has something listening on that port, it becomes accessible from outside.

DocPrinter wrote:

I always struggled to understand why software listening to ports often don't fail safe.

Because it's hard to prove formally that software always correctly handles malformed incoming traffic.

seth · 2026-08-11 07:38:12

If for any reason local addresses changed and some other local machine got that local address and has something listening on that port, it becomes accessible from outside.

That's unrelated to the port state, though?

If someone floods this port from outside

assuming no bugs and backdoors in network stack implementation itself on router

If somebody floods your network the port configuration borderline doesn't matter (because at some point the LAN host will go down and re-create the situation of an unhandled port anyway)
But even consumer routers frequently provide filters for this https://www.tp-link.com/de/support/faq/1533/

dimich · 2026-08-11 07:57:18

seth wrote:

That's unrelated to the port state, though?

Actually it's related to port state on "new local machine" with address of "old local machine with nothing listening to that port". Of course, it's consequence of misconfiguration and pretty unlikely. I mentioned it answering to "so no issue with a router forwarding to a local machine with nothing listening" because I've encountered such a situation once

But even consumer routers frequently provide filters for this

That's why there is "if ... there is no firewall configured (or misconfigured) on router ...".

seth · 2026-08-11 10:11:05

because I've encountered such a situation once

Do you have records of the details of that case?
If an unexpecting host becomes active destination of port forwarding you're in deep poo-poo, but I don't quite get how the intended host becomes relevant here - you'll not just "take over" an open connection and if there previously was unconditional forwarding to a closed port the remote (attacker) would just have gone from unreachable… unreachable… unreachable… oh, look: an unprotected ssh login!

killertofus · 2026-08-11 10:26:33

related xkcd's https://xkcd.com/1200/ https://xkcd.com/538/ https://xkcd.com/936/

dimich · 2026-08-11 11:12:19

seth wrote:

Do you have records of the details of that case?

I forwarded external port to local machine for downloading artifacts from remote lab. I.e. I start https server, download artifacts, stop server if it's not needed for today. In a year or two after that project was already done, weird logs apeared on another local machine with https server. That server was purposed for LAN only but requests were from random global addresses. It turned out that this machine started obtaining the same address as previous one (which no longer existed). Of course, this wouldn't have happened if "new" machine had configured some filtering etc, or if I hadn't forgotten to turn off port forwarding on the router.

seth wrote:

if there previously was unconditional forwarding to a closed port the remote (attacker) would just have gone from unreachable… unreachable… unreachable… oh, look: an unprotected ssh login!

That's what I'm talking about. "Forwarding a specific port to a local machine with nothing listening to that port on the local machine" makes no sense in general. Why to forward itfp? It's safe if "nothing listening" is guaranteed. But never can be sure that something not start to listen in the future. And of course, never rely on NAT as a protection

DocPrinter · 2026-08-11 15:25:05

Thanks, those comments and different synarios help the understanding.

Yes my unused port was a very similar situation. As it happens I don't think it caused any issues bit I recently mirrored all settings for one home broadband router to another and saw I had ports being forwarded that I completely forgot about.

So when writing nftables rules is it bast to make the rejected connections to any external connections fail quietly so attackers don't sniff a port being listened to?

Last edited by DocPrinter (2026-08-11 15:25:52)

loqs · 2026-08-11 15:31:59

DocPrinter wrote:

So when writing nftables rules is it bast to make the rejected connections to any external connections fail quietly so attackers don't sniff a port being listened to?

Does whatever is listening allow connections without authentication?

Last edited by loqs (2026-08-11 15:32:13)

dimich · 2026-08-11 18:33:38

DocPrinter wrote:

So when writing nftables rules is it bast to make the rejected connections to any external connections fail quietly so attackers don't sniff a port being listened to?

If the goal is to hide your host from scanning and discovering services, then yes, it makes sence to drop incoming packets. Although in this case there will be no "rejected connections" because nothing to reject.

Arch Linux

#1 2026-08-10 19:02:27

Learning about attack vectors nftables, appamor, etc protect against?

#2 2026-08-10 19:43:46

Re: Learning about attack vectors nftables, appamor, etc protect against?

#3 2026-08-10 22:51:44

Re: Learning about attack vectors nftables, appamor, etc protect against?

#4 2026-08-11 06:32:01

Re: Learning about attack vectors nftables, appamor, etc protect against?

#5 2026-08-11 06:50:13

Re: Learning about attack vectors nftables, appamor, etc protect against?

#6 2026-08-11 07:15:08

Re: Learning about attack vectors nftables, appamor, etc protect against?

#7 2026-08-11 07:21:42

Re: Learning about attack vectors nftables, appamor, etc protect against?

#8 2026-08-11 07:38:12

Re: Learning about attack vectors nftables, appamor, etc protect against?

#9 2026-08-11 07:57:18

Re: Learning about attack vectors nftables, appamor, etc protect against?

#10 2026-08-11 10:11:05

Re: Learning about attack vectors nftables, appamor, etc protect against?

#11 2026-08-11 10:26:33

Re: Learning about attack vectors nftables, appamor, etc protect against?

#12 2026-08-11 11:12:19

Re: Learning about attack vectors nftables, appamor, etc protect against?

#13 2026-08-11 15:25:05

Re: Learning about attack vectors nftables, appamor, etc protect against?

#14 2026-08-11 15:31:59

Re: Learning about attack vectors nftables, appamor, etc protect against?

#15 2026-08-11 18:33:38

Re: Learning about attack vectors nftables, appamor, etc protect against?

Board footer