On 2023-04-29 08:54, Per Jessen wrote:
Carlos E. R. wrote:
Ah, found where I got the trick for acrobat:
] Date: Sun, 17 Apr 2005 18:52:27 +0200 ] From: nordi ] To: suse-security@ ] Subject: Re: [suse-security] How to block Acroread 7 with SuSE FW2? ] ] In order to block that traffic you could make the acroread executable ] SGID 'acro' and then block all traffic coming from group 'acro'. ] Iptables has an option for doing this by using the --gid-owner option. ] Of course that works only with a local firewall.
Interesting. Well, thanks for the explanation, at least you can get rid of that now.
Yep. I had forgotten about it. Still, we can find out how it is translated to firewalld.
Oh sure, I understand that, but it is nonetheless why you have ended up with something utterly unmaintainable. In my opinion, of course.
Look at it this way.
I just wanted to trust machine at 192.168.1.5 for syslog and icmp. I simply told the firewall script in the approved manner to do it. How it did do it, is not my business.
Of course - the question is _why_ you chose to be so restrictive with traffic between your _own_ machines. I too restrict certain (groups of) machines, e.g. unknown wifi devices, but I would never go to the level of restricting individual intrnal machines.
Oh, I said that before: because I did not trust Telefónica router. In fact, at some point, the firewall not only was disabled by default, but the firewall option was hidden from the menu and had to be enabled by saving the config to file, editing it by hand, then loading it back. They considered NAT to be all that was needed. And the second reason, I wanted to learn how to do it. Oh, I forgot the third machine: in case I got guest machines, specially those running windows and possibly malware unknown to the owner.
And why icmp? because it was probably spamming the log, and probably some feature of the router or switch or whatever it was did not work unless I allowed that packet to pass.
I think I would have chose a different method to stop something spamming a logfile, but never mind - the issue is that your solution from 1725 has been turned into a jungle of rules in 2023. Time to reassess.
:-DD LOL I'm feeling older, thanks :-)
I suggest you just accept all icmp, for ipv4 you can even skip the ping-flood protection. After 24 hours, check your logs to see if any have been filled up.
Ok, I'll purge the zone file of that <icmp-block name="address-unreachable"/> <icmp-block name="bad-header"/> <icmp-block name="beyond-scope"/> <icmp-block name="communication-prohibited"/> <icmp-block name="destination-unreachable"/> <icmp-block name="echo-reply"/> <icmp-block name="failed-policy"/> <icmp-block name="fragmentation-needed"/> <icmp-block name="host-precedence-violation"/> <icmp-block name="host-prohibited"/> <icmp-block name="host-redirect"/> <icmp-block name="host-unknown"/> <icmp-block name="host-unreachable"/> <icmp-block name="ip-header-bad"/> <icmp-block name="network-prohibited"/> <icmp-block name="network-redirect"/> <icmp-block name="network-unknown"/> <icmp-block name="network-unreachable"/> <icmp-block name="no-route"/> <icmp-block name="packet-too-big"/> <icmp-block name="parameter-problem"/> <icmp-block name="port-unreachable"/> <icmp-block name="precedence-cutoff"/> <icmp-block name="protocol-unreachable"/> <icmp-block name="reject-route"/> <icmp-block name="required-option-missing"/> <icmp-block name="source-route-failed"/> <icmp-block name="time-exceeded"/> <icmp-block name="timestamp-reply"/> <icmp-block name="timestamp-request"/> <icmp-block name="tos-host-redirect"/> <icmp-block name="tos-host-unreachable"/> <icmp-block name="tos-network-redirect"/> <icmp-block name="tos-network-unreachable"/> <icmp-block name="ttl-zero-during-reassembly"/> <icmp-block name="ttl-zero-during-transit"/> <icmp-block name="unknown-header-type"/> <icmp-block name="unknown-option"/> -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)