@Kalcifer@sh.itjust.works avatar

Kalcifer

@Kalcifer@sh.itjust.works

All of this user’s content is licensed under CC BY 4.0.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

Kalcifer, (edited )
@Kalcifer@sh.itjust.works avatar

Technologically, there’s a little more to it than only that, but, in practice, that’s essentially what it does.

Kalcifer, (edited )
@Kalcifer@sh.itjust.works avatar

UnifiedPush, itself, is just the standard; services like Ntfy then implement it.

Kalcifer,
@Kalcifer@sh.itjust.works avatar

Because the people that wrote it decided to make it that way.

Sure, but it still feels like a strange design decision.

If you don’t like it, just remove firewalld and manage your iptables/nftables directly

This is essentially what I ended up doing.

Kalcifer, (edited )
@Kalcifer@sh.itjust.works avatar

Do they impact your firewall efficiency?

No – it just seems unnecessary to force the user to have the default ones – just allow the user to create the zones that they want/need.

Kalcifer, (edited )
@Kalcifer@sh.itjust.works avatar

Because it aligns with most people’s use case.

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.

Kalcifer, (edited )
@Kalcifer@sh.itjust.works avatar

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.

just use iptables directly.

This is essentially what I ended up doing.

Kalcifer,
@Kalcifer@sh.itjust.works avatar

Maybe you should take it up with the maintainers.

See the linked GitHub issue.

Kalcifer,
@Kalcifer@sh.itjust.works avatar

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?

Kalcifer,
@Kalcifer@sh.itjust.works avatar

You always need a firewall, no other answer’s.

Okay, but why? That’s kind of the point of why I made this post, as is stated in the post’s body.

Kalcifer,
@Kalcifer@sh.itjust.works avatar

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.

Kalcifer,
@Kalcifer@sh.itjust.works avatar

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).

Kalcifer,
@Kalcifer@sh.itjust.works avatar

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?

Fair point!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • localhost
  • All magazines
    •
    Loading…
    Loading the web debug toolbar…
    Attempt #