[oS-en] Testing the new configuration of firewalld
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <5bf6502a-a6a1-9cf4-dce1-355b4d5b564b@Telcontar.valinor> Hi, (This is a thinking aloud post, so of course there is conflict in what I say) So I converted my miniserver to use firewalld instead of SuSEfirewalld, using "susefirewall2-to-firewalld" script. I added the rule to block incoming packets from the router. The resulting config is: Isengard:/etc/firewalld/zones # firewall-cmd --list-all external (active) target: default icmp-block-inversion: no interfaces: eth0 wlan0 sources: services: dns http https mountd nfs nfs3 ntp rpc-bind ssh ports: 12854/tcp 50000/tcp 12858/udp 47981/udp 38059/tcp 56517/udp 40399/tcp protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: address-unreachable bad-header beyond-scope communication-prohibited destination-unreachable echo-reply failed-policy fragmentation-needed host-precedence-violation host-prohibited host-redirect host-unknown host-unreachable ip-header-bad network-prohibited network-redirect network-unknown network-unreachable no-route packet-too-big parameter-problem port-unreachable precedence-cutoff protocol-unreachable reject-route required-option-missing source-route-failed time-exceeded timestamp-reply timestamp-request tos-host-redirect tos-host-unreachable tos-network-redirect tos-network-unreachable ttl-zero-during-reassembly ttl-zero-during-transit unknown-header-type unknown-option rich rules: rule family="ipv4" source address="192.168.1.55/32" port port="5556" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="2908" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.1.57/32" accept rule family="ipv4" source address="192.168.1.14/32" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="80" protocol="tcp" accept rule family="ipv4" source address="192.168.1.0/24" port port="80" protocol="tcp" accept rule family="ipv4" source address="192.168.1.5/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.1.14/32" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4080" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4080" protocol="tcp" accept rule family="ipv4" source address="192.168.1.7/32" port port="137" protocol="tcp" accept rule family="ipv4" source address="172.26.0.0/16" protocol value="udp" accept rule family="ipv4" source address="192.168.1.126/32" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4243" protocol="tcp" accept rule family="ipv4" source address="192.168.1.54/32" port port="4243" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="53" protocol="tcp" accept rule family="ipv4" source address="192.168.1.7/32" protocol value="udp" accept rule family="ipv4" source address="192.168.1.7/32" port port="139" protocol="tcp" accept rule family="ipv4" source address="192.168.1.127/32" port port="873" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" port port="162" protocol="udp" accept rule family="ipv4" source address="192.168.1.55/32" accept rule family="ipv4" source address="192.168.1.0/24" port port="111" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="5000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8080" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4001" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="25" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" port port="50000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="445" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="5353" protocol="tcp" accept rule family="ipv4" source address="192.168.1.56/32" port port="5556" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4120" protocol="udp" accept rule family="ipv4" source address="192.168.1.126/32" port port="873" protocol="tcp" accept rule family="ipv4" source address="192.168.1.0/24" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4242" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4243" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="1252" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4243" protocol="udp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8081" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="9090" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="2049" protocol="tcp" accept rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept rule family="ipv4" source address="192.168.1.1/32" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.1.128/32" port port="1625" protocol="tcp" accept rule family="ipv4" source address="192.168.1.127/32" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4080" protocol="tcp" accept rule family="ipv4" source address="192.168.1.54/32" accept rule family="ipv4" source address="192.168.1.128/32" port port="137" protocol="udp" accept rule family="ipv4" source address="192.168.1.0/24" port port="2049" protocol="udp" accept rule family="ipv4" source address="192.168.1.7/32" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="9090" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="162" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.50/32" port port="53" protocol="tcp" accept rule family="ipv4" source address="192.168.1.0/24" port port="111" protocol="udp" accept rule family="ipv4" source address="192.168.1.7/32" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.1.5/32" port port="162" protocol="udp" accept rule family="ipv4" source address="192.168.1.14/32" port port="514" protocol="tcp" accept rule family="ipv4" source address="192.168.1.7/32" port port="5353" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="873" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4754" protocol="udp" accept rule family="ipv4" source address="192.168.1.128/32" port port="53" protocol="tcp" accept rule family="ipv4" source address="192.168.1.56/32" port port="5558" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4001" protocol="tcp" accept rule family="ipv4" source address="192.168.1.15/32" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" protocol value="udp" accept rule family="ipv4" source address="192.168.1.0/24" port port="22" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="6666" protocol="udp" accept rule family="ipv4" source address="192.168.1.54/32" port port="5558" protocol="tcp" accept rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept rule family="ipv4" source address="192.168.1.50/32" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.1.7/32" port port="3553" protocol="udp" accept rule family="ipv4" source address="192.168.1.54/32" port port="5556" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.1.7/32" port port="515" protocol="tcp" accept rule family="ipv4" source address="192.168.1.5/32" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.1.128/32" port port="138" protocol="udp" accept rule family="ipv4" source address="192.168.1.56/32" accept rule family="ipv4" source address="192.168.1.128/32" port port="139" protocol="tcp" accept rule family="ipv4" source address="192.168.1.55/32" port port="5558" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="8081" protocol="tcp" accept rule priority="10" source mac="ROUTER_MAC" reject Isengard:/etc/firewalld/zones # So, I want to try the access to apache and ssh from outside. I connect via ssh to a Friend's machine, and try. Ipv4 first. carlos@Friend:~ $ curl http://isengard_rmt_dns ^C carlos@Friend:~ $ No response on port 80, good. carlos@Friend:~ $ curl http://isengard_rmt_dns:50000 <html><body><h1>Hola tio.</h1></body></html>carlos@Friend:~ $ Correct response on a high port. carlos@Friend:~ $ ssh cer@isengard_rmt_dns ^C carlos@Friend:~ $ No response on port 22, correct. carlos@Friend:~ $ ssh -p 51000 cer@isengard_rmt_dns The authenticity of host '[isengard_rmt_dns]:51000 ([IPv4_ADDR]:51000)' can't be established. ECDSA key fingerprint is SHA256:ILyba.... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[isengard_rmt_dns]:51000,[IPv4_ADDR]:51000' (ECDSA) to the list of known hosts. cer@isengard_rmt_dns: Permission denied (publickey). carlos@Friend:~ $ Expected response on a high port. Notice that on IPv4 the router intervenes with translations (virtual server). Incoming to port 51000 is sent to Isengard on LAN, port 22. Incoming to port 50000 is sent to port Isengard on LAN, port 50000. (not the actual ports, I edited them for privacy; but close). The Virtual Server config of the router doesn't work on IPv6 - correct, it is a NAT hack. Apache on IPv6 and high port: carlos@Friend:~ $ curl http://[Ipv6_ADDR]:50000 <html><body><h1>Hola tio.</h1></body></html>carlos@Friend:~ $ This is correct. carlos@Friend:~ $curl http://[Ipv6_ADDR] <html><body> <h1>Welcome to Isengard</a></h1> <h3>Letras: \ | @ # € </h3> <h2> <a href="/ficheros" title="Ficheros">[ficheros]</a> <br> <a href="/ficheros/mirrors" title="Mirrors">[Mirrors]</a> <br> <a href="/data/hoard/TheHoard/jd">[Shared J]</a> <br> <a href="/data/hoard/">[Data]</a> <br> <a href="/data/waterhoard/Fusion/Videos">[Fusion]</a> <br> <a href="/data/My_Book/Fusion/Videos">[Fusion MyBook]</a> <br> <!-- <a href="/usr/share/doc">Doc</a> <br> --> <!-- Ver Alias y Directory en "/etc/apache2/httpd.conf.local" para dar acceso a nuevos directorios --> </h2> </body></html> carlos@Friend:~ $ Now, this is not correct, it is the response expected INSIDE the LAN. That means a problem in the Apache configuration for virtual hosts, but also that port 80 is not closed on IPv6. ssh on IPv6 and default port: carlos@Friend:~ $ ssh cer@Ipv6_ADDR The authenticity of host 'Ipv6_ADDR (Ipv6_ADDR)' can't be established. ECDSA key fingerprint is SHA256:ILyba. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'Ipv6_ADDR' (ECDSA) to the list of known hosts. cer@Ipv6_ADDR: Permission denied (publickey). carlos@Friend:~ $ Well, this is not correct, it should be denied by the rich rule. Obviously, computers have their own mind, but I'm not familiar with the firewalld "mind". And I'm getting a headache. There is this rule: rule family="ipv4" source address="192.168.1.1/32" port port="50000" protocol="tcp" accept which might conflict with: rule priority="10" source mac="ROUTER_MAC" reject but it is for Ipv4 only, so it shouldn't. It seems that: services: dns http https mountd nfs nfs3 ntp rpc-bind ssh takes precedence over the rich rule denying packets via router. [headache] Obviously, being a server, both ssh and http have to be open even if the packet is incoming from the router, but not on the 22 and 80 ports, but on the high ports only. So maybe I have to remove the line services: dns http https mountd nfs nfs3 ntp rpc-bind ssh move all that to rich rules that open those ports on IPv4 only, and open generically ports 50000 and 51000 only. Wait, ssh comes from the router on port 22, it is translated. Making sshd listen on 51000 is not that easy. So, generically open port 50000. Open port 22 on IPv4, close on IPv6? Or open generically. Ideas? (Can I write comments in xml file /etc/firewalld/zones/external.xml?) - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEg+2Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVN8kAnjDt2n+lyVtMRz7zT+Ih EiOCzJ8mAJ4pxKkBZj3nxuRjOT9DM7TClL87Tg== =tCZ9 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2023-04-25 at 23:22 +0200, Bengt Gördén wrote:
On 2023-04-25 22:58, Carlos E. R. wrote:
rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept
I have this comment on my "/etc/sysconfig/SuSEfirewall2" file, from which they werre translated to the above two lines: # fe80::/64,udp,5353 - autoconf broadcast from printer #fc00 # Posible entrada desde internet al ssh FW_SERVICES_ACCEPT_EXT="192.168.1.14/24,_rpc_,nfs 192.168.1.15/24,_rpc_,nfs 192.168.1.129/24,_rpc_,nfs \ fe80::/64,udp,5353 fc00::/64,udp,5353 \ 192.168.1.0/24,tcp,80 192.168.1.0/24,tcp,22 \ 0/0,tcp,22,,hitcount=3,blockseconds=100,recentname=ssh" Ie, I wrote that probably to silence noise in the log from a printer broadcast, or to have some autoconf feature from the printer working.
Whats the output of ip6tables-save
Isengard:/etc/firewalld/zones # ip6tables-save # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *raw :PREROUTING ACCEPT [14175:19377794] :OUTPUT ACCEPT [9470:17375360] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *security :INPUT ACCEPT [12058:19236084] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *nat :PREROUTING ACCEPT [2050:136843] :INPUT ACCEPT [18:1343] :OUTPUT ACCEPT [37:4315] :POSTROUTING ACCEPT [37:4315] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *mangle :PREROUTING ACCEPT [14175:19377794] :INPUT ACCEPT [14089:19371371] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] :POSTROUTING ACCEPT [9475:17375810] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *filter :INPUT ACCEPT [14033:19362332] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] - -A INPUT -p udp -m udp --dport 546 -j ACCEPT - -A INPUT -p udp -m udp --dport 5353 -m pkttype --pkt-type multicast -j ACCEPT COMMIT # Completed on Wed Apr 26 02:17:33 2023 Isengard:/etc/firewalld/zones # - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEhwKhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfViOoAn3xz/8HFm65pDigqM8uu VsDrKLDIAJ0fTXHqWYtddI+Gkgl17nz4yrBoTw== =r3T6 -----END PGP SIGNATURE-----
On 2023-04-26 02:28, Carlos E. R. wrote:
On Tuesday, 2023-04-25 at 23:22 +0200, Bengt Gördén wrote:
On 2023-04-25 22:58, Carlos E. R. wrote:
rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept
I have this comment on my "/etc/sysconfig/SuSEfirewall2" file, from which they werre translated to the above two lines:
# fe80::/64,udp,5353 - autoconf broadcast from printer #fc00 # Posible entrada desde internet al ssh FW_SERVICES_ACCEPT_EXT="192.168.1.14/24,_rpc_,nfs 192.168.1.15/24,_rpc_,nfs 192.168.1.129/24,_rpc_,nfs \ fe80::/64,udp,5353 fc00::/64,udp,5353 \ 192.168.1.0/24,tcp,80 192.168.1.0/24,tcp,22 \ 0/0,tcp,22,,hitcount=3,blockseconds=100,recentname=ssh"
Ie, I wrote that probably to silence noise in the log from a printer broadcast, or to have some autoconf feature from the printer working.
Whats the output of ip6tables-save
Isengard:/etc/firewalld/zones # ip6tables-save # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *raw :PREROUTING ACCEPT [14175:19377794] :OUTPUT ACCEPT [9470:17375360] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *security :INPUT ACCEPT [12058:19236084] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *nat :PREROUTING ACCEPT [2050:136843] :INPUT ACCEPT [18:1343] :OUTPUT ACCEPT [37:4315] :POSTROUTING ACCEPT [37:4315] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *mangle :PREROUTING ACCEPT [14175:19377794] :INPUT ACCEPT [14089:19371371] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] :POSTROUTING ACCEPT [9475:17375810] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *filter :INPUT ACCEPT [14033:19362332] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] -A INPUT -p udp -m udp --dport 546 -j ACCEPT -A INPUT -p udp -m udp --dport 5353 -m pkttype --pkt-type multicast -j ACCEPT COMMIT # Completed on Wed Apr 26 02:17:33 2023 Isengard:/etc/firewalld/zones #
Now I don't know firewalld but from ip6tables-save I don't see that you reject or drop anything. Shouldn't the last filter rule be to drop everything? Like this: *filter :INPUT ACCEPT [14033:19362332] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] -A INPUT -p udp -m udp --dport 546 -j ACCEPT -A INPUT -p udp -m udp --dport 5353 -m pkttype --pkt-type multicast -j ACCEPT -A INPUT -j DROP COMMIT Of course your ipv6 rules need to accept rules port 80 and anything else you want to be able to get through. -- /bengan
On 2023-04-26 10:26, Andrei Borzenkov wrote:
On Wed, Apr 26, 2023 at 10:59 AM Bengt Gördén <bengan@bag.org> wrote:
Now I don't know firewalld but from ip6tables-save I don't see that you reject or drop anything.
Google for "nftables"
Yes I know. But that doesn't mean that nftables is used. For instance: linux-jrxm:~ # grep FirewallBackend /etc/firewalld/firewalld.conf # FirewallBackend FirewallBackend=nftables linux-jrxm:~ # iptables-save # Generated by iptables-save v1.8.9 on Wed Apr 26 10:43:10 2023 <snip> # Completed on Wed Apr 26 10:43:10 2023 linux-jrxm:~ # iptables-nft-save # Warning: iptables-legacy tables present, use iptables-legacy-save to see them -- /bengan
Carlos E. R. wrote:
(This is a thinking aloud post, so of course there is conflict in what I say)
I didn't see any conflicts, maybe I need to look again :-)
Isengard:/etc/firewalld/zones # firewall-cmd --list-all [snip - 80 rich rules] rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept
1) isn't that the kind of rule - family="ipv6" - that made your firewalld explode yesterday? 2) 5353 is for mdns - you won't see any of that on fe80::. Are you actually using fc00:: ? 3) Personally, I would be unhappy with such a setup, 86 rich rules. I appreciate it is due to the conversion script, but a pile of "rich rules" is not much better than my old well-structured iptables script, with comments. Anyway, just an observation.
carlos@Friend:~ $curl http://[Ipv6_ADDR] <html><body> <h1>Welcome to Isengard</a></h1> <h3>Letras: \ | @ # € </h3> [snip]
Now, this is not correct, it is the response expected INSIDE the LAN. That means a problem in the Apache configuration for virtual hosts, but also that port 80 is not closed on IPv6.
You were presumably expecting the last rich rule rule priority="10" source mac="ROUTER_MAC" reject to cause that to be blocked.
Obviously, computers have their own mind, but I'm not familiar with the firewalld "mind".
My computers do _exactly_ what they are told :-)
It seems that:
services: dns http https mountd nfs nfs3 ntp rpc-bind ssh
takes precedence over the rich rule denying packets via router.
Aha, okay. (I didn't know the meaning of that line).
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines. -- Per Jessen, Zürich (6.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Wed, Apr 26, 2023 at 9:46 AM Per Jessen <per@opensuse.org> wrote:
It seems that:
services: dns http https mountd nfs nfs3 ntp rpc-bind ssh
takes precedence over the rich rule denying packets via router.
Aha, okay. (I didn't know the meaning of that line).
Yes, rich rules with positive priorities are ordered after all other automatically generated rules. So the rule to allow connection to ssh port wins. Which is exactly what has been requested - SSH had to be open to the Internet.
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
These files are modified by GUI and CLI so I am not sure these comments will be preserved.
Andrei Borzenkov wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
These files are modified by GUI and CLI so I am not sure these comments will be preserved.
That is a good point. The XML file is presumbly not intended as a user interface, so why keep comments. Unless the GUI/CLI permits adding comments, somehow. -- Per Jessen, Zürich (14.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-26 12:44, Per Jessen wrote:
Andrei Borzenkov wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
These files are modified by GUI and CLI so I am not sure these comments will be preserved.
That is a good point. The XML file is presumbly not intended as a user interface, so why keep comments. Unless the GUI/CLI permits adding comments, somehow.
I see easier to edit the file by hand to purge the excess of rules, but I need comments to know what is the purpose of this or that. SuSEfirewall2 accepted comments. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-26 12:44, Per Jessen wrote:
Andrei Borzenkov wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
These files are modified by GUI and CLI so I am not sure these comments will be preserved.
That is a good point. The XML file is presumbly not intended as a user interface, so why keep comments. Unless the GUI/CLI permits adding comments, somehow.
I see easier to edit the file by hand to purge the excess of rules, but I need comments to know what is the purpose of this or that.
Yeah I would too, but the whole idea of tools such as firewalld is to make manual editing superfluous. Wrap everything in a nice GUI abstracting from the tedious technical detail.
SuSEfirewall2 accepted comments.
So does my bash script :-) If you google it, e.g. "adding comments in firewalld", there are interesting hits. https://serverfault.com/questions/893112/migrating-from-iptables-to-firewall... How can we comment each firewalld rules for description? https://access.redhat.com/solutions/6822451 https://www.golinuxcloud.com/firewalld-cheat-sheet/#1_Add_comment_to_firewal... -- Per Jessen, Zürich (13.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Wed, Apr 26, 2023 at 2:31 PM Per Jessen <per@opensuse.org> wrote:
How can we comment each firewalld rules for description? https://access.redhat.com/solutions/6822451
Can you access it?
Andrei Borzenkov wrote:
On Wed, Apr 26, 2023 at 2:31 PM Per Jessen <per@opensuse.org> wrote:
How can we comment each firewalld rules for description? https://access.redhat.com/solutions/6822451
Can you access it?
No ..... I realised too late, sorry. -- Per Jessen, Zürich (14.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Andrei Borzenkov wrote:
On Wed, Apr 26, 2023 at 2:31 PM Per Jessen <per@opensuse.org> wrote:
How can we comment each firewalld rules for description? https://access.redhat.com/solutions/6822451
Can you access it?
No ..... I realised too late, sorry.
The mention of adding '-m comment --comment "" ' to rules suggests there is an XML element for such comments - might be worth looking into, to maybe add comments manually. -- Per Jessen, Zürich (14.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-26 13:42, Per Jessen wrote:
Per Jessen wrote:
Andrei Borzenkov wrote:
On Wed, Apr 26, 2023 at 2:31 PM Per Jessen <> wrote:
The mention of adding '-m comment --comment "" ' to rules suggests there is an XML element for such comments - might be worth looking into, to maybe add comments manually.
/etc/firewalld/direct.xml:
<?xml version="1.0" encoding="utf-8"?> <direct> <rule ipv="ipv4" table="filter" chain="INPUT" priority="0">-p tcp -m tcp -s 10.10.10.60 --dport=80 -j ACCEPT -m comment --comment 'Accept ip 60'</rule> <passthrough ipv="ipv4">-t filter -A INPUT -p udp -m udp --dport 5353 -m pkttype --pkt-type multicast -j ACCEPT</passthrough> <passthrough ipv="ipv6">-t filter -A INPUT -p udp -m udp --dport 546 -j ACCEPT</passthrough> <passthrough ipv="ipv6">-t filter -A INPUT -p udp -m udp --dport 5353 -m pkttype --pkt-type multicast -j ACCEPT</passthrough> </direct> Definitely not what I want.
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-26 13:42, Per Jessen wrote:
Per Jessen wrote:
Andrei Borzenkov wrote:
On Wed, Apr 26, 2023 at 2:31 PM Per Jessen <> wrote:
The mention of adding '-m comment --comment "" ' to rules suggests there is an XML element for such comments - might be worth looking into, to maybe add comments manually.
/etc/firewalld/direct.xml:
<?xml version="1.0" encoding="utf-8"?> <direct> <rule ipv="ipv4" table="filter" chain="INPUT" priority="0">-p tcp -m tcp -s 10.10.10.60 --dport=80 -j ACCEPT -m comment --comment
Yeah, Andrei already said so. -- Per Jessen, Zürich (15.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-26 13:31, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 12:44, Per Jessen wrote:
Andrei Borzenkov wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
These files are modified by GUI and CLI so I am not sure these comments will be preserved.
That is a good point. The XML file is presumbly not intended as a user interface, so why keep comments. Unless the GUI/CLI permits adding comments, somehow.
I see easier to edit the file by hand to purge the excess of rules, but I need comments to know what is the purpose of this or that.
Yeah I would too, but the whole idea of tools such as firewalld is to make manual editing superfluous. Wrap everything in a nice GUI abstracting from the tedious technical detail.
Yes. But when you have to change 50 rules, the command become cumbersome. So, once I know how the rule is written to the file, for such a job I prefer to edit the file. The first link you posted comments on this, precisely.
SuSEfirewall2 accepted comments.
So does my bash script :-)
If you google it, e.g. "adding comments in firewalld", there are interesting hits.
https://serverfault.com/questions/893112/migrating-from-iptables-to-firewall...
How can we comment each firewalld rules for description? https://access.redhat.com/solutions/6822451
https://www.golinuxcloud.com/firewalld-cheat-sheet/#1_Add_comment_to_firewal...
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote:
(This is a thinking aloud post, so of course there is conflict in what I say)
I didn't see any conflicts, maybe I need to look again :-)
Isengard:/etc/firewalld/zones # firewall-cmd --list-all [snip - 80 rich rules] rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept
1) isn't that the kind of rule - family="ipv6" - that made your firewalld explode yesterday?
Yes, but a different rule. family="ipv6" source mac="MAC..." reject
2) 5353 is for mdns - you won't see any of that on fe80::. Are you actually using fc00:: ?
You ask details I don't remember :-D My notes in "/etc/sysconfig/SuSEfirewall2" say: # fe80::/64,udp,5353 - autoconf broadcast from printer
3) Personally, I would be unhappy with such a setup, 86 rich rules.
Me too.
I appreciate it is due to the conversion script, but a pile of "rich rules" is not much better than my old well-structured iptables script, with comments. Anyway, just an observation.
Yes, I intend to clear them, but time is limited and I have to decide how. If rich rules accepted multiple IPs or multiple ports, it would be easier. Maybe I have to apply them to the entire LAN range.
carlos@Friend:~ $curl http://[Ipv6_ADDR] <html><body> <h1>Welcome to Isengard</a></h1> <h3>Letras: \ | @ # € </h3> [snip]
Now, this is not correct, it is the response expected INSIDE the LAN. That means a problem in the Apache configuration for virtual hosts, but also that port 80 is not closed on IPv6.
You were presumably expecting the last rich rule
rule priority="10" source mac="ROUTER_MAC" reject
to cause that to be blocked.
Yep.
Obviously, computers have their own mind, but I'm not familiar with the firewalld "mind".
My computers do _exactly_ what they are told :-)
Mine too, but what they are actually told is not exactly what I meant to tell them :-p Do wwat I mean, not what I say DWIMNWIS Turn left! No, the other left! :-)
It seems that:
services: dns http https mountd nfs nfs3 ntp rpc-bind ssh
takes precedence over the rich rule denying packets via router.
Aha, okay. (I didn't know the meaning of that line).
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
Ah. Thanks. Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
Ah. Thanks.
Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.
It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept. -- Per Jessen, Zürich (13.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-26 12:47, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
Ah. Thanks.
Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.
It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept.
Then the file should have a machine written comment at the top: do not edit, automatically generated file. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-26 12:47, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
Ah. Thanks.
Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.
It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept.
Then the file should have a machine written comment at the top: do not edit, automatically generated file.
Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO. -- Per Jessen, Zürich (14.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-26 13:18, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 12:47, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
Ah. Thanks.
Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.
It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept.
Then the file should have a machine written comment at the top: do not edit, automatically generated file.
Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.
Other software produce precisely that line. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-26 13:18, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 12:47, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote: > (Can I write comments in xml file > /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
Ah. Thanks.
Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.
It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept.
Then the file should have a machine written comment at the top: do not edit, automatically generated file.
Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.
Other software produce precisely that line.
In XML ? -- Per Jessen, Zürich (15.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-26 15:39, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 13:18, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 12:47, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 08:45, Per Jessen wrote: > Carlos E. R. wrote: >> (Can I write comments in xml file >> /etc/firewalld/zones/external.xml?) > > Yes, use "<!-- comment -->". Can span multiple lines.
Ah. Thanks.
Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.
It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept.
Then the file should have a machine written comment at the top: do not edit, automatically generated file.
Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.
Other software produce precisely that line.
In XML ?
I don't remember all the file types where I saw this. /usr/share/mobile-broadband-provider-info/apns-conf.xml <?xml version="1.0"?> <!-- Automatically generated from serviceproviders.xml --> /usr/share/flightgear/Aircraft/Instruments-3d/mk-viii/caution0.xml <?xml version="1.0"?> <!--automatically generated, do not edit--> :-) (I found them using 'mc' ;-) ) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-26 15:39, Per Jessen wrote:
Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.
Other software produce precisely that line.
In XML ?
I don't remember all the file types where I saw this.
Thank goodness we are only discussing XML.
/usr/share/mobile-broadband-provider-info/apns-conf.xml
<?xml version="1.0"?> <!-- Automatically generated from serviceproviders.xml -->
/usr/share/flightgear/Aircraft/Instruments-3d/mk-viii/caution0.xml
<?xml version="1.0"?> <!--automatically generated, do not edit-->
Gee, thanks for that - one(!) exception to prove the rule. I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment. -- Per Jessen, Zürich (18.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-26 18:23, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 15:39, Per Jessen wrote:
Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.
Other software produce precisely that line.
In XML ?
I don't remember all the file types where I saw this.
Thank goodness we are only discussing XML.
/usr/share/mobile-broadband-provider-info/apns-conf.xml
<?xml version="1.0"?> <!-- Automatically generated from serviceproviders.xml -->
/usr/share/flightgear/Aircraft/Instruments-3d/mk-viii/caution0.xml
<?xml version="1.0"?> <!--automatically generated, do not edit-->
Gee, thanks for that - one(!) exception to prove the rule.
Actually, it is many files in flightgear, I just copied one :-p
I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment.
Maybe they should, if they can not be edited ;-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-26 20:07, Carlos E. R. wrote:
On 2023-04-26 18:23, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 15:39, Per Jessen wrote:
Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.
Other software produce precisely that line.
In XML ?
I don't remember all the file types where I saw this.
Thank goodness we are only discussing XML.
/usr/share/mobile-broadband-provider-info/apns-conf.xml
<?xml version="1.0"?> <!-- Automatically generated from serviceproviders.xml -->
/usr/share/flightgear/Aircraft/Instruments-3d/mk-viii/caution0.xml
<?xml version="1.0"?> <!--automatically generated, do not edit-->
Gee, thanks for that - one(!) exception to prove the rule.
Actually, it is many files in flightgear, I just copied one :-p
Found another. /home/cer/tmp/initrd/etc/splashy/config.xml <!-- Automatically generated by splashy_config. Do not edit --> I think it is inside the initrd archive. And this reference: /home/cer/bin/lazarus/lazarus_usrlib/docs/xml/lcl/lresources.xml <!-- constant Visibility: default --> <element name="LRSComment"> <short>Text of the "automatically generated..." warning in resource files. </short> <descr/> <seealso/> </element> which means that Lazarus automatically inserts the text in the resource files it creates. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Found another.
/home/cer/tmp/initrd/etc/splashy/config.xml
<!-- Automatically generated by splashy_config. Do not edit -->
I think it is inside the initrd archive.
See what Dave Howorth said about that situation :-)
And this reference:
/home/cer/bin/lazarus/lazarus_usrlib/docs/xml/lcl/lresources.xml
Oh no, the evidence is growing :-) -- Per Jessen, Zürich (18.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-27 13:34, Per Jessen wrote:
Carlos E. R. wrote:
Found another.
/home/cer/tmp/initrd/etc/splashy/config.xml
<!-- Automatically generated by splashy_config. Do not edit -->
I think it is inside the initrd archive.
See what Dave Howorth said about that situation :-)
I know, so it is strange to see the notice inside.
And this reference:
/home/cer/bin/lazarus/lazarus_usrlib/docs/xml/lcl/lresources.xml
Oh no, the evidence is growing :-)
You will be assimilated (into the Borg). -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wed, 26 Apr 2023 18:23:58 +0200 Per Jessen <per@opensuse.org> wrote:
I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment.
Eh, an LO document should just be a single file (.ods, .odt etc) surely? Anything else would be a nightmare to copy etc.
Dave Howorth wrote:
On Wed, 26 Apr 2023 18:23:58 +0200 Per Jessen <per@opensuse.org> wrote:
I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment.
Eh, an LO document should just be a single file (.ods, .odt etc) surely? Anything else would be a nightmare to copy etc.
Yes, to the casual observer, an LO document certainly appears to be a single file. An LO document is a zip file, in a style similar to a jar file: per@office64:~> unzip -l Documents/surbl-stats.ods Archive: Documents/surbl-stats.ods Length Date Time Name -------- ---- ---- ---- 46 07-24-09 06:44 mimetype 423142 07-24-09 06:44 content.xml 6168 07-24-09 06:44 styles.xml 914 07-24-09 06:44 meta.xml 9768 07-24-09 06:44 Thumbnails/thumbnail.png [snip] 9069 07-24-09 06:44 settings.xml 1873 07-24-09 06:44 META-INF/manifest.xml -------- ------- 450980 15 files -- Per Jessen, Zürich (12.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-27 08:58, Per Jessen wrote:
Dave Howorth wrote:
On Wed, 26 Apr 2023 18:23:58 +0200 Per Jessen <per@opensuse.org> wrote:
I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment.
Eh, an LO document should just be a single file (.ods, .odt etc) surely? Anything else would be a nightmare to copy etc.
Yes, to the casual observer, an LO document certainly appears to be a single file. An LO document is a zip file, in a style similar to a jar file:
An archive. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Thu, 27 Apr 2023 08:58:44 +0200 Per Jessen <per@opensuse.org> wrote:
Dave Howorth wrote:
On Wed, 26 Apr 2023 18:23:58 +0200 Per Jessen <per@opensuse.org> wrote:
I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment.
Eh, an LO document should just be a single file (.ods, .odt etc) surely? Anything else would be a nightmare to copy etc.
Yes, to the casual observer, an LO document certainly appears to be a single file. An LO document is a zip file, in a style similar to a jar file:
per@office64:~> unzip -l Documents/surbl-stats.ods Archive: Documents/surbl-stats.ods Length Date Time Name -------- ---- ---- ---- 46 07-24-09 06:44 mimetype 423142 07-24-09 06:44 content.xml 6168 07-24-09 06:44 styles.xml 914 07-24-09 06:44 meta.xml 9768 07-24-09 06:44 Thumbnails/thumbnail.png [snip] 9069 07-24-09 06:44 settings.xml 1873 07-24-09 06:44 META-INF/manifest.xml -------- ------- 450980 15 files
Right, but there are no XML files there that could be accidently edited, so no need for any warnings about editing them :) So a poor choice of counterexample?
Dave Howorth wrote:
On Thu, 27 Apr 2023 08:58:44 +0200 Per Jessen <per@opensuse.org> wrote:
per@office64:~> unzip -l Documents/surbl-stats.ods Archive: Documents/surbl-stats.ods Length Date Time Name -------- ---- ---- ---- 46 07-24-09 06:44 mimetype 423142 07-24-09 06:44 content.xml 6168 07-24-09 06:44 styles.xml 914 07-24-09 06:44 meta.xml 9768 07-24-09 06:44 Thumbnails/thumbnail.png [snip] 9069 07-24-09 06:44 settings.xml 1873 07-24-09 06:44 META-INF/manifest.xml -------- ------- 450980 15 files
Right, but there are no XML files there that could be accidently edited, so no need for any warnings about editing them :) So a poor choice of counterexample?
Yeah I admit it, it was a slightly poor example :-) Still, the key message remains the same - excluding certain common examples, XML files are not for human processing, accidentally or otherwise. When they are made human-readable with newlines and indentation, it is for debugging purposes. Maybe these are better examples ? /var/lib/wicked/ (three XML files) all openSUSE repodata (1270 files on my mirror) -- Per Jessen, Zürich (18.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-27 13:12, Per Jessen wrote:
Dave Howorth wrote:
On Thu, 27 Apr 2023 08:58:44 +0200 Per Jessen <per@opensuse.org> wrote:
per@office64:~> unzip -l Documents/surbl-stats.ods Archive: Documents/surbl-stats.ods Length Date Time Name -------- ---- ---- ---- 46 07-24-09 06:44 mimetype 423142 07-24-09 06:44 content.xml 6168 07-24-09 06:44 styles.xml 914 07-24-09 06:44 meta.xml 9768 07-24-09 06:44 Thumbnails/thumbnail.png [snip] 9069 07-24-09 06:44 settings.xml 1873 07-24-09 06:44 META-INF/manifest.xml -------- ------- 450980 15 files
Right, but there are no XML files there that could be accidently edited, so no need for any warnings about editing them :) So a poor choice of counterexample?
Yeah I admit it, it was a slightly poor example :-) Still, the key message remains the same - excluding certain common examples, XML files are not for human processing, accidentally or otherwise. When they are made human-readable with newlines and indentation, it is for debugging purposes.
I'm right now editing the Isengard:/etc/firewalld/zones/external.xml, to reduce the number of rules, and it is right tedious. With commands it would be unthinkable. Looking at the official documentation: https://firewalld.org/documentation/zone/examples.html it is all XML, not commands, so they do intend people to edit them directly. By the way, looking at that site, I do not see a documentation section on "rules" :-? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2023-04-27 at 14:15 +0200, Carlos E. R. wrote:
On 2023-04-27 13:12, Per Jessen wrote:
Dave Howorth wrote:
Yeah I admit it, it was a slightly poor example :-) Still, the key message remains the same - excluding certain common examples, XML files are not for human processing, accidentally or otherwise. When they are made human-readable with newlines and indentation, it is for debugging purposes.
I'm right now editing the Isengard:/etc/firewalld/zones/external.xml, to reduce the number of rules, and it is right tedious. With commands it would be unthinkable.
Looking at the official documentation:
https://firewalld.org/documentation/zone/examples.html
it is all XML, not commands, so they do intend people to edit them directly.
By the way, looking at that site, I do not see a documentation section on "rules" :-?
https://firewalld.org/documentation/zone/options.html https://firewalld.org/documentation/man-pages/firewalld.richlanguage I got the modified file working with just one error :-) Isengard:/etc/firewalld # firewall-cmd --reload success But: Isengard:/etc/firewalld/zones # firewall-cmd --list-all external (active) target: default icmp-block-inversion: no interfaces: eth0 wlan0 sources: services: ssh ports: protocols: forward: no masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules: Isengard:/etc/firewalld/zones # it had actually failed. One has to do this: Isengard:/etc/firewalld/zones # firewall-cmd --check-config Error: INVALID_ZONE: 'external.xml': not a valid zone file: not well-formed (invalid token): line 59, column 18 Isengard:/etc/firewalld/zones # mcedit external.xml It did not like this: <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept limit value="3/m" /> </rule> I had to change it to: <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept> <limit value="3/m"/> </accept> </rule> Isengard:/etc/firewalld/zones # firewall-cmd --list-all external (active) target: default icmp-block-inversion: no interfaces: eth0 wlan0 sources: services: ports: 12854/tcp 53792/tcp 12858/udp 47981/udp 38059/tcp 56517/udp 40399/tcp protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: address-unreachable bad-header beyond-scope communication-prohibited destination-unreachable echo-reply failed-policy fragmentation-needed host-precedence-violation host-prohibited host-redirect host-unknown host-unreachable ip-header-bad network-prohibited network-redirect network-unknown network-unreachable no-route packet-too-big parameter-problem port-unreachable precedence-cutoff protocol-unreachable reject-route required-option-missing source-route-failed time-exceeded timestamp-reply timestamp-request tos-host-redirect tos-host-unreachable tos-network-redirect tos-network-unreachable ttl-zero-during-reassembly ttl-zero-during-transit unknown-header-type unknown-option rich rules: rule family="ipv4" source address="192.168.0.0/16" service name="https" accept rule family="ipv4" source address="192.168.1.128/32" port port="2908" protocol="udp" accept rule family="ipv4" source address="192.168.1.57/32" accept rule family="ipv4" source address="192.168.1.54/32" accept rule family="ipv4" source address="192.168.1.5/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.0.0/16" service name="http" accept rule family="ipv4" source address="192.168.0.0/16" service name="nfs" accept rule family="ipv4" source address="192.168.0.0/16" service name="dns" accept rule family="ipv4" source address="192.168.1.129/32" port port="9090" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="8080" protocol="tcp" accept rule family="ipv4" source address="172.26.0.0/16" protocol value="udp" accept rule family="ipv4" source address="192.168.1.128/32" port port="1252" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="5556" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4000" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="137-139" protocol="udp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8000" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="22" protocol="tcp" accept rule family="ipv4" source address="192.168.1.7/32" protocol value="udp" accept rule family="ipv4" source address="192.168.1.14/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.0.0/16" port port="873" protocol="tcp" accept rule family="ipv4" source address="192.168.1.55/32" accept rule family="ipv4" source address="192.168.1.128/32" port port="4754" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="4080" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" service name="ssh" accept limit value="3/m" rule family="ipv4" source address="192.168.1.129/32" port port="5000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4001" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="25" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" port port="53792" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" service name="mountd" accept rule family="ipv4" source address="192.168.0.0/16" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="80" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="5353" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4000" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="137-139" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" protocol value="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4001" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="6666" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="5558" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4120" protocol="udp" accept rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="111" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="4243" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4242" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="445" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="162" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="4243" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" service name="nfs3" accept rule family="ipv4" source address="192.168.0.0/16" service name="rpc-bind" accept rule family="ipv4" source address="192.168.1.7/32" port port="3553" protocol="udp" accept rule family="ipv4" source address="192.168.1.1/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.1.7/32" port port="515" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="53" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8081" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="9090" protocol="tcp" accept rule family="ipv4" source address="192.168.1.56/32" accept rule family="ipv4" source address="192.168.0.0/16" port port="111" protocol="tcp" accept rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="8081" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="1625" protocol="tcp" accept rule priority="10" source mac="CC:..." reject Isengard:/etc/firewalld/zones # I have not dared to write comments, though. I want to change as many port numbers to services when I can. It is tyring. I had to change the initial block: <service name="ssh"/> <service name="dns"/> <service name="http"/> <service name="https"/> <service name="mountd"/> <service name="nfs"/> <service name="nfs3"/> <service name="rpc-bind"/> <service name="ntp"/> to rules instead, in order to accept them only for IPv4. <?xml version="1.0" encoding="utf-8"?> <zone> <short>External</short> <description>For use on external networks. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description> <port port="12854" protocol="tcp"/> <port port="53792" protocol="tcp"/> <port port="12858" protocol="udp"/> <port port="47981" protocol="udp"/> <port port="38059" protocol="tcp"/> <port port="56517" protocol="udp"/> <port port="40399" protocol="tcp"/> I don't understand what the next block is. Do I really need it? <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"/> <rule priority="10"> <source mac="CC:..."/> <reject/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept> <limit value="3/m"/> </accept> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="dns"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="http"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="https"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="mountd"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="nfs"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="nfs3"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="rpc-bind"/> <accept/> </rule> <rule family="ipv4"> <source address="172.26.0.0/16"/> <protocol value="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="22" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="53" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="53" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="80" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="111" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="111" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="137-139" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="137-139" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="162" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="445" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="514" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="873" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="2049" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="4080" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="4243" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="4243" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="5353" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="5556" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="5558" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="8080" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="2908" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.5/32"/> <protocol value="icmp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.7/32"/> <protocol value="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.54/32"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.55/32"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.57/32"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.1/32"/> <protocol value="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.1/32"/> <protocol value="icmp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.1/32"/> <port port="53792" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.7/32"/> <port port="515" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.7/32"/> <port port="3553" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <protocol value="icmp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="25" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="4000" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="4001" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="4242" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="6666" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="8000" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="8081" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="9090" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="4120" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="1252" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="1625" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="4000" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="5000" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="9090" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="8081" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="4754" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="4001" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.56/32"/> <accept/> </rule> <rule family="ipv6"> <source address="fe80::/64"/> <port port="5353" protocol="udp"/> <accept/> </rule> <rule family="ipv6"> <source address="fc00::/64"/> <port port="5353" protocol="udp"/> <accept/> </rule> <interface name="eth0"/> <interface name="wlan0"/> </zone> And now I have a headache. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEr6Ghwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVeNsAnisz2fc+U2vKXziUbqQs mnA1l2AFAJ4zbtZGvL7JGVytI1MFJ5CBP/vUeg== =14sB -----END PGP SIGNATURE-----
Carlos E. R. wrote:
It did not like this:
<rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept limit value="3/m" /> </rule>
Obviously - an experienced XML editor will spot that immediately :-)
rich rules: rule family="ipv4" source address="192.168.0.0/16" service name="https" accept rule family="ipv4" source address="192.168.1.128/32" port port="2908" protocol="udp" accept rule family="ipv4" source address="192.168.1.57/32" accept rule family="ipv4" source address="192.168.1.54/32" accept [snip 50 rules]
I have to admit, for a local network it certainly seems overly complex. You should be happy you only have a few machines ....
I have not dared to write comments, though.
As long as they were syntactically correct, they would have been fine, even if short-lived.
I want to change as many port numbers to services when I can. It is tyring.
I had to change the initial block to rules instead, in order to accept them only for IPv4:
<service name="ssh"/> <service name="dns"/> <service name="http"/> <service name="https"/> <service name="mountd"/> <service name="nfs"/> <service name="nfs3"/> <service name="rpc-bind"/> <service name="ntp"/>
This is based on a) the ipv6 firewall in your router not working, hence b) you need to block things on the local machines ? Why do you want to block ssh, dns, http/s and ntp? As for nfs, that also seems somewhat unnecessary when your nfs server presumably only exports to known ipv4 hosts.
I don't understand what the next block is. Do I really need it?
<icmp-block name="this-and-that"/>
I presume it was migrated from your SFW2 setup, so I guess you needed it previously. I have nothing like it - I don't know why you would need to block all of those, individually. If (!) there are some unwanted ICMPs, block those, then allow the rest. [snip 366 lines that might have been better put on paste.o.o] -- Per Jessen, Zürich (13.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-28 09:04, Per Jessen wrote:
Carlos E. R. wrote:
It did not like this:
<rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept limit value="3/m" /> </rule>
Obviously - an experienced XML editor will spot that immediately :-)
Well, the manual wasn't clear for a non experienced editor. Still, that was the single error, and I reduced the file from 12812 to 9609 bytes :-)
rich rules: rule family="ipv4" source address="192.168.0.0/16" service name="https" accept rule family="ipv4" source address="192.168.1.128/32" port port="2908" protocol="udp" accept rule family="ipv4" source address="192.168.1.57/32" accept rule family="ipv4" source address="192.168.1.54/32" accept [snip 50 rules]
I have to admit, for a local network it certainly seems overly complex. You should be happy you only have a few machines ....
A local network with a non working external firewall protecting it. I initially did it, long ago, for learning and because I did not trust the Telefónica firewall. I was right, old routers did not enable the firewall by default, they relied on NAT. Before them, modems did not have a firewall, but there was no LAN either.
I have not dared to write comments, though.
As long as they were syntactically correct, they would have been fine, even if short-lived.
I may write them; I can use the software to create some new rule, see what change they wrote to the file, then enact the old file with edited new rules instead. Some of the comments may come from the old SuSEfirewall2 file.
I want to change as many port numbers to services when I can. It is tyring.
I had to change the initial block to rules instead, in order to accept them only for IPv4:
<service name="ssh"/> <service name="dns"/> <service name="http"/> <service name="https"/> <service name="mountd"/> <service name="nfs"/> <service name="nfs3"/> <service name="rpc-bind"/> <service name="ntp"/>
This is based on
a) the ipv6 firewall in your router not working, hence b) you need to block things on the local machines ?
Right.
Why do you want to block ssh, dns, http/s and ntp? As for nfs, that also seems somewhat unnecessary when your nfs server presumably only exports to known ipv4 hosts.
I want to block them only on IPv6. For example, http access the wrong apache virtual host, the internal one, from outside. For now, it is easier to block it rather than find out why. For ssh, well, the intranet is on password, not keys. nfs, yes, right, only exports to some hosts. The others, I simply have not checked. Easier to block rather than check. The external nmap revealed opened ports. Later, I can open to IPv6 things that I know I need/want I'm still debating myself whether I want: rule priority="10" source mac="CC:..." reject with or without priority.
I don't understand what the next block is. Do I really need it?
<icmp-block name="this-and-that"/>
I presume it was migrated from your SFW2 setup, so I guess you needed it previously.
I never wrote those. They must be default rules.
I have nothing like it - I don't know why you would need to block all of those, individually. If (!) there are some unwanted ICMPs, block those, then allow the rest.
Me neither.
[snip 366 lines that might have been better put on paste.o.o]
Oops. That many? Well, only 26 Kb total. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Fri, Apr 28, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
I want to block them only on IPv6.
If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.
On 2023-04-28 13:13, Andrei Borzenkov wrote:
On Fri, Apr 28, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
I want to block them only on IPv6.
If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.
I expect^H^H^H^H^H^Hhope to have proper IPv6 one day... -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Op vrijdag 28 april 2023 13:18:47 CEST schreef Carlos E. R.:
On 2023-04-28 13:13, Andrei Borzenkov wrote:
On Fri, Apr 28, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
I want to block them only on IPv6.
If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.
I expect^H^H^H^H^H^Hhope to have proper IPv6 one day...
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
All global IPv6 addresses are 2000::/3 so you might block/drop all these addresses by using "firewall-cmd --zone=block --add-source=2000::/3" or "firewall-cmd --zone=drop --add-source=2000::/3", depending on if you want to reject (with an ICMP message) or drop the incoming IPv6 package from a global IPv6 address. You still can use private IPv6 addresses (link local or unique local addresses). -- fr.gr. member openSUSE Freek de Kruijf
On Fri, Apr 28, 2023 at 3:21 PM Freek de Kruijf <freek@opensuse.org> wrote:
Op vrijdag 28 april 2023 13:18:47 CEST schreef Carlos E. R.:
On 2023-04-28 13:13, Andrei Borzenkov wrote:
On Fri, Apr 28, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
I want to block them only on IPv6.
If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.
I expect^H^H^H^H^H^Hhope to have proper IPv6 one day...
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
All global IPv6 addresses are 2000::/3 so you might block/drop all these addresses by using "firewall-cmd --zone=block --add-source=2000::/3" or "firewall-cmd --zone=drop --add-source=2000::/3", depending on if you want to reject (with an ICMP message) or drop the incoming IPv6 package from a global IPv6 address. You still can use private IPv6 addresses (link local or unique local addresses).
This will block both external and internal IPv6, so will have more or less the same effect as "not using IPv6 internally". LL and ULA have been beaten to death previously.
On 2023-04-28 14:21, Freek de Kruijf wrote:
Op vrijdag 28 april 2023 13:18:47 CEST schreef Carlos E. R.:
On 2023-04-28 13:13, Andrei Borzenkov wrote:
On Fri, Apr 28, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
...
All global IPv6 addresses are 2000::/3 so you might block/drop all these addresses by using "firewall-cmd --zone=block --add-source=2000::/3" or "firewall-cmd --zone=drop --add-source=2000::/3", depending on if you want to reject (with an ICMP message) or drop the incoming IPv6 package from a global IPv6 address. You still can use private IPv6 addresses (link local or unique local addresses).
My own address starts with 2a02:... "firewall-cmd --zone=drop --add-source=2000::/3" Thinking. Zone=drop? That's new to me. Well, currently I have: rule priority="10" source mac="CC:..." reject which rejects packets coming through the router, except those that have an explicit "accept". -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Fri, Apr 28, 2023 at 3:33 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
Well, currently I have:
rule priority="10" source mac="CC:..." reject
which rejects packets coming through the router, except those that have an explicit "accept".
This rule is completely useless because those packages would have been rejected by default anyway. I know that I mentioned it, in my defense I corrected myself.
On 4/28/23 04:18, Carlos E. R. wrote:
If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.
I expect^H^H^H^H^H^Hhope to have proper IPv6 one day...
What will IPv6 actually do for you? It's a serious question, what will it give you that you don't already have with IPv4 and NAT? From my experience at work it's nothing but a PITA that reduces reliability. Regards, Lew
On 2023-04-28 17:06, Lew Wolfgang wrote:
On 4/28/23 04:18, Carlos E. R. wrote:
If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.
I expect^H^H^H^H^H^Hhope to have proper IPv6 one day...
What will IPv6 actually do for you? It's a serious question, what will it give you that you don't already have with IPv4 and NAT?
From my experience at work it's nothing but a PITA that reduces reliability. Well, it allows direct connection from outside to an internal computer, if wanted, without tricks.
This is interesting to gamers, for instance, or for direct VoIP. Or remote working. If a coworker needs files you have, you can just share them from your computer, no intermediate server needed. As it is, there are providers in Spain that do not give you a public IPv4 address, but one in the 10.*.*.* network. This directly blocks those people from accessing home from outside. All this are uses that were originally designed for Internet, but rendered impossible when NAT was implemented, because there were not enough addresses for everybody. This doesn't affect USAians as much as others. Nor Spaniards as much as Indians, for instance. Then came Telefónica with their stupidity of not issuing static addresses by default and against quelled the dreams. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 4/28/23 09:09, Carlos E. R. wrote:
On 2023-04-28 17:06, Lew Wolfgang wrote:
On 4/28/23 04:18, Carlos E. R. wrote:
If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.
I expect^H^H^H^H^H^Hhope to have proper IPv6 one day...
What will IPv6 actually do for you? It's a serious question, what will it give you that you don't already have with IPv4 and NAT?
From my experience at work it's nothing but a PITA that reduces reliability. Well, it allows direct connection from outside to an internal computer, if wanted, without tricks.
Allow direct outside connection to an internal computer? What could possibly go wrong!?
This is interesting to gamers, for instance, or for direct VoIP. Or remote working.
If a coworker needs files you have, you can just share them from your computer, no intermediate server needed.
Again, that's a security risk. Better to just forward ssh through your NAT router to the inside host.
As it is, there are providers in Spain that do not give you a public IPv4 address, but one in the 10.*.*.* network. This directly blocks those people from accessing home from outside.
That could be an issue, if you need outside access. You could bounce through an external proxy that you control if needed. I bet Per could offer one to you.
All this are uses that were originally designed for Internet, but rendered impossible when NAT was implemented, because there were not enough addresses for everybody. This doesn't affect USAians as much as others. Nor Spaniards as much as Indians, for instance.
IMHO NAT has worked remarkably well.
Then came Telefónica with their stupidity of not issuing static addresses by default and against quelled the dreams.
My ISP doesn't issue static address either, but it really doesn't matter to me with my current configuration. It's static anyway for long periods of time. Regards, Lew
Carlos E. R. wrote:
On 2023-04-28 09:04, Per Jessen wrote:
Carlos E. R. wrote:
It did not like this:
<rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept limit value="3/m" /> </rule>
Obviously - an experienced XML editor will spot that immediately :-)
Well, the manual wasn't clear for a non experienced editor.
Maybe recall a recent thread about the manual editing ... oh never mind :-)
I have to admit, for a local network it certainly seems overly complex. You should be happy you only have a few machines ....
A local network with a non working external firewall protecting it.
The latter should not affect the complexity, I would say. Most of your rich rules are unrelated to that. Afaict, you are restricting access internally?
I was right, old routers did not enable the firewall by default, they relied on NAT. Before them, modems did not have a firewall, but there was no LAN either.
We are talking quite a while back, late 1800s?
Why do you want to block ssh, dns, http/s and ntp? As for nfs, that also seems somewhat unnecessary when your nfs server presumably only exports to known ipv4 hosts.
I want to block them only on IPv6.
For example, http access the wrong apache virtual host, the internal one, from outside. For now, it is easier to block it rather than find out why. For ssh, well, the intranet is on password, not keys.
Oh I see.
I don't understand what the next block is. Do I really need it?
<icmp-block name="this-and-that"/>
I presume it was migrated from your SFW2 setup, so I guess you needed it previously.
I never wrote those. They must be default rules.
Maybe check one of your other machines still using SFW2. You ought to see a long list of rules targeting those icmps. -- Per Jessen, Zürich (16.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-28 14:34, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-28 09:04, Per Jessen wrote:
Carlos E. R. wrote:
It did not like this:
<rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept limit value="3/m" /> </rule>
Obviously - an experienced XML editor will spot that immediately :-)
Well, the manual wasn't clear for a non experienced editor.
Maybe recall a recent thread about the manual editing ... oh never mind :-)
I have to admit, for a local network it certainly seems overly complex. You should be happy you only have a few machines ....
A local network with a non working external firewall protecting it.
The latter should not affect the complexity, I would say. Most of your rich rules are unrelated to that. Afaict, you are restricting access internally?
The default is, I believe, all ports closed, except those explicitly opened. So I open those I need. Or needed, I don't remember what those ports were needed for.
I was right, old routers did not enable the firewall by default, they relied on NAT. Before them, modems did not have a firewall, but there was no LAN either.
We are talking quite a while back, late 1800s?
Year 1800? :-D
Why do you want to block ssh, dns, http/s and ntp? As for nfs, that also seems somewhat unnecessary when your nfs server presumably only exports to known ipv4 hosts.
I want to block them only on IPv6.
For example, http access the wrong apache virtual host, the internal one, from outside. For now, it is easier to block it rather than find out why. For ssh, well, the intranet is on password, not keys.
Oh I see.
I don't understand what the next block is. Do I really need it?
<icmp-block name="this-and-that"/>
I presume it was migrated from your SFW2 setup, so I guess you needed it previously.
I never wrote those. They must be default rules.
Maybe check one of your other machines still using SFW2. You ought to see a long list of rules targeting those icmps.
Oh, I have the file of this machine intact. Isengard:/etc/firewalld/zones # grep -i address-unreachable /etc/sysconfig/SuSEfirewall2 Isengard:/etc/firewalld/zones # The reference is not there, it has to be some default. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
I don't understand what the next block is. Do I really need it?
<icmp-block name="this-and-that"/>
I presume it was migrated from your SFW2 setup, so I guess you needed it previously.
I never wrote those. They must be default rules.
Maybe check one of your other machines still using SFW2. You ought to see a long list of rules targeting those icmps.
Oh, I have the file of this machine intact.
Isengard:/etc/firewalld/zones # grep -i address-unreachable /etc/sysconfig/SuSEfirewall2 Isengard:/etc/firewalld/zones #
The reference is not there, it has to be some default.
That is not a safe way to determine it. The issue is - if it is a default, it is in the migration script and that would be weird. Try running "iptables --list -n" and maybe grep for 'icmp' For comparison, from my opensuse mirror: jensen:~ # iptables --list -n| grep icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 2/sec burst 5 DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 -- Per Jessen, Zürich (15.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2023-04-28 at 18:29 +0200, Per Jessen wrote:
Carlos E. R. wrote:
I don't understand what the next block is. Do I really need it?
<icmp-block name="this-and-that"/>
I presume it was migrated from your SFW2 setup, so I guess you needed it previously.
I never wrote those. They must be default rules.
Maybe check one of your other machines still using SFW2. You ought to see a long list of rules targeting those icmps.
Oh, I have the file of this machine intact.
Isengard:/etc/firewalld/zones # grep -i address-unreachable /etc/sysconfig/SuSEfirewall2 Isengard:/etc/firewalld/zones #
The reference is not there, it has to be some default.
That is not a safe way to determine it. The issue is - if it is a default, it is in the migration script and that would be weird.
Try running "iptables --list -n" and maybe grep for 'icmp'
Telcontar:~ # iptables --list -n | grep -i icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED REJECT all -- 0.0.0.0/0 0.0.0.0/0 owner GID match 1011 reject-with icmp-port-unreachable ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 4 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 192.168.1.1 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.5 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.6 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.29 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.15 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.16 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED LOG icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-INext-DROP-DEFLT " ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 4 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 192.168.1.1 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.5 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.6 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.29 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.15 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.16 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED LOG icmp -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix "SFW2-INint-DROP-DEFLT " REJECT udp -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable Telcontar:~ #
For comparison, from my opensuse mirror:
jensen:~ # iptables --list -n| grep icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 2/sec burst 5 DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
- -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEv5hRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfViAgAoJTPnJDujIbzfJWixHU7 7v0wcZdAAJ9XU3oQIFwTMbk5p4G1DMZl0gEuaQ== =G0go -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The issue is - if it is a default, it is in the migration script and that would be weird.
Try running "iptables --list -n" and maybe grep for 'icmp'
Telcontar:~ # iptables --list -n | grep -i icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED REJECT all -- 0.0.0.0/0 0.0.0.0/0 owner GID match 1011 reject-with icmp-port-unreachable
That is an odd one, I don't think I have ever seen anything like that.
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 4 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 192.168.1.1 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.5 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.6 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.29 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.15 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.16 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED
Those were clearly added by yourself. I am a bit puzzled regarding 'ctstate' for ICMP traffic, but that is likely a personal shortcoming :-)
ACCEPT icmp -- 192.168.1.1 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.5 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.6 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.29 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.15 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.16 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED
That is more stuff that you have added. It looks to me as if you accept type 4 (weird, "source quench?" ) type 8 (ping request) I expect you didn't actually add those ICMP rules yourself, but the host addresses must have come from you. -- Per Jessen, Zürich (14.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 28.04.2023 20:19, Per Jessen wrote:
Those were clearly added by yourself. I am a bit puzzled regarding 'ctstate' for ICMP traffic, but that is likely a personal shortcoming :-)
Host/port unreachable in response to TCP SYN packet is "related". Echo request from outside is not but echo reply is.
Andrei Borzenkov wrote:
On 28.04.2023 20:19, Per Jessen wrote:
Those were clearly added by yourself. I am a bit puzzled regarding 'ctstate' for ICMP traffic, but that is likely a personal shortcoming :-)
Host/port unreachable in response to TCP SYN packet is "related".
Right, that one I knew.
Echo request from outside is not but echo reply is.
Ah, okay, I had never thought of that. -- Per Jessen, Zürich (14.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-28 19:19, Per Jessen wrote:
Carlos E. R. wrote:
The issue is - if it is a default, it is in the migration script and that would be weird.
Try running "iptables --list -n" and maybe grep for 'icmp'
I see I forgot to mention that I run the query in a computer that is still running SuSEfirewall2.
Telcontar:~ # iptables --list -n | grep -i icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED REJECT all -- 0.0.0.0/0 0.0.0.0/0 owner GID match 1011 reject-with icmp-port-unreachable
That is an odd one, I don't think I have ever seen anything like that.
I think I remember where that one may come from, but I do not remember it was icmp. in /etc/sysconfig/scripts/SuSEfirewall2-custom I have the following:
fw_custom_after_chain_creation() { # these rules will be loaded after the various input_* and forward_* chains # are created. # You can use this hook to allow/deny certain IP protocols or TCP/UDP # ports before the SuSEfirewall2 generated rules are hit.
#Cer iptables -A OUTPUT -m owner --gid-owner talker -j LOG --log-prefix 'Do not talk home: ' iptables -A OUTPUT -m owner --gid-owner talker -j REJECT
true }
and cer@Telcontar:/etc> grep talker /etc/group talker:x:1011: cer@Telcontar:/etc> This was used on acroread. That program run with that GID, and thus had it network connections denied. No talking back home. The script is dated 2012, it is probably older.
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 4 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 192.168.1.1 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.5 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.6 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.29 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.15 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.16 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED
Those were clearly added by yourself. I am a bit puzzled regarding 'ctstate' for ICMP traffic, but that is likely a personal shortcoming :-)
That's this: FW_TRUSTED_NETS="192.168.1.1,udp,syslog 192.168.1.1,icmp \ 192.168.1.5,udp,syslog 192.168.1.5,icmp \ 192.168.1.6,udp,syslog 192.168.1.6,icmp \ 192.168.1.29,udp,syslog 192.168.1.29,icmp \ .5 was oldrouter.valinor .6 is one of the switches, don't know which. .29 I don't remember, it is not in the DNS, but seeing the syslog reference it had to be a router or access point. Not active anymore.
ACCEPT icmp -- 192.168.1.1 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.5 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.6 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.29 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.15 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.16 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED
That is more stuff that you have added. It looks to me as if you accept type 4 (weird, "source quench?" ) type 8 (ping request)
See above. I just wrote a plain normal SuSEfirewall option.
I expect you didn't actually add those ICMP rules yourself, but the host addresses must have come from you.
## Type: string # # Which services should be accessible from 'trusted' hosts or nets? # # Define trusted hosts or networks (doesn't matter whether they are internal or # external) and the services (tcp,udp,icmp) they are allowed to use. This can # be used instead of FW_SERVICES_* for further access restriction. Please note # that this is no replacement for authentication since IP addresses can be # spoofed. Also note that trusted hosts/nets are not allowed to ping the # firewall until you also permit icmp. # # Format: space separated list of network[,protocol[,port]] # in case of icmp, port means the icmp type # # if network has IPv6 address format then an ip6tables rule will be assumed. # # Example: "172.20.1.1 172.20.0.0/16 1.1.1.1,icmp 2.2.2.2,tcp,22 2620:113:80c0:8080:10:160:68:136/64,rsync" # # dhcp fixed addresses on router. # 50 - laptop on Windows. # 51 - samsung android. # 52 - tablet android # FW_TRUSTED_NETS="192.168.1.1,udp,syslog 192.168.1.1,icmp \ -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-28 19:19, Per Jessen wrote:
Carlos E. R. wrote:
The issue is - if it is a default, it is in the migration script and that would be weird.
Try running "iptables --list -n" and maybe grep for 'icmp'
I see I forgot to mention that I run the query in a computer that is still running SuSEfirewall2.
I did expect that, otherwise it would have been useless :-)
Telcontar:~ # iptables --list -n | grep -i icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED REJECT all -- 0.0.0.0/0 0.0.0.0/0 owner GID match 1011 reject-with icmp-port-unreachable
That is an odd one, I don't think I have ever seen anything like that.
I think I remember where that one may come from, but I do not remember it was icmp.
No, it's for all protocols, the grep hits on on the reject-with reason.
This was used on acroread. That program run with that GID, and thus had it network connections denied. No talking back home.
Weird sh**t .... :-) [snip]
.5 was oldrouter.valinor .6 is one of the switches, don't know which. .29 I don't remember, it is not in the DNS, but seeing the syslog reference it had to be a router or access point. Not active anymore.
It is beginning to sound like you have a lot of old baggage to get rid of.
That is more stuff that you have added. It looks to me as if you accept type 4 (weird, "source quench?" ) type 8 (ping request)
See above. I just wrote a plain normal SuSEfirewall option.
Oh sure, I understand that, but it is nonetheless why you have ended up with something utterly unmaintainable. In my opinion, of course. -- Per Jessen, Zürich (13.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-28 20:52, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-28 19:19, Per Jessen wrote:
Carlos E. R. wrote:
The issue is - if it is a default, it is in the migration script and that would be weird.
Try running "iptables --list -n" and maybe grep for 'icmp'
I see I forgot to mention that I run the query in a computer that is still running SuSEfirewall2.
I did expect that, otherwise it would have been useless :-)
Telcontar:~ # iptables --list -n | grep -i icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED REJECT all -- 0.0.0.0/0 0.0.0.0/0 owner GID match 1011 reject-with icmp-port-unreachable
That is an odd one, I don't think I have ever seen anything like that.
I think I remember where that one may come from, but I do not remember it was icmp.
No, it's for all protocols, the grep hits on on the reject-with reason.
This was used on acroread. That program run with that GID, and thus had it network connections denied. No talking back home.
Weird sh**t .... :-)
That was my concoction with help and ideas from here, very probably. Normally I write a comment saying where, but I don't see it now. I see a "SuSEfirewall2-custom~" dated 2008 with that code. Another one dated 2005 has this section:
#Cer 2051225 - from an email in suse-security # Blocking ssh attacks iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j REJECT
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. ] Date: Mon, 18 Apr 2005 15:56:26 +0200 ] From: nordi ] To: suse-security@ ] Subject: Re: [suse-security] How to block Acroread 7 with SuSE FW2? ] ] Carl A. Schreiber wrote: ]> I'd like to learn more about this, would you mind to give an example ]> for such a rule? ] ] I did it with the following rule: ] iptables -A OUTPUT -m owner --gid-owner talker -j REJECT ] ] Then I set /usr/bin/netcat to be owned by group 'talker' and to mode ] 2755 (SGID). After that I could not connect anywhere with netcat. Once I ] chmodded netcat back to 755 it worked again.
[snip]
.5 was oldrouter.valinor .6 is one of the switches, don't know which. .29 I don't remember, it is not in the DNS, but seeing the syslog reference it had to be a router or access point. Not active anymore.
It is beginning to sound like you have a lot of old baggage to get rid of.
You don't say :-D
That is more stuff that you have added. It looks to me as if you accept type 4 (weird, "source quench?" ) type 8 (ping request)
See above. I just wrote a plain normal SuSEfirewall option.
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. 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. Of course, I can purge now machine 192.168.1.5 because it no longer exists and I have forgotten what machine it was. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
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.
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.
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. 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. -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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)
Carlos E. R. wrote:
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.
Might be good for laugh, I suppose. No doubt a rich rule.
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.
It sounds much more like you didn't trust your own machines.
They considered NAT to be all that was needed.
Which it almost certainly was. Did you have any traffic penetrate that NAT-wall ? -- Per Jessen, Zürich (18.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-29 14:07, Per Jessen wrote:
Carlos E. R. wrote:
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.
Might be good for laugh, I suppose. No doubt a rich rule.
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.
It sounds much more like you didn't trust your own machines.
I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware. The only thing the guest wifi has is a different ssid and password, so you do not have to give the main one. And that guest password can be cycled.
They considered NAT to be all that was needed.
Which it almost certainly was. Did you have any traffic penetrate that NAT-wall ?
Not that I know, but hackers and script kiddies have their list of vulnerabilities to penetrate Telefónica routers. Do you know that all Telefónica routers use the same user, ie "1234" and is hardcoded? And back then, not 1754 but 2010 or thereabouts, used the same password? They just have to bombard a router from outside and try all possible passwords with 8 letters/numbers. If it is under attack, some models do not log the attempts. The current incumbent logs nothing at all whatsoever. Maybe that's why they refuse using fixed IPv6. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-29 14:07, Per Jessen wrote:
Carlos E. R. wrote:
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.
It sounds much more like you didn't trust your own machines.
I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.
I thought you had a reserved range that you could allocate as fixed addresses. Something about 20 addresses?
The only thing the guest wifi has is a different ssid and password, so you do not have to give the main one. And that guest password can be cycled.
Our wifi password is just "password" and I give it to anyone who wants it.
Do you know that all Telefónica routers use the same user, ie "1234" and is hardcoded? And back then, not 1754 but 2010 or thereabouts, used the same password?
Well, that isn't too unlike Netgear and Tp-Link and D-link etc. By default they also all comes with the same admin userid and password. I was not aware that it was hardcoded in Telefonica equipment, but nothing surprises me about Telefonica any more. I think everyone is just amazed that you keep using them. -- Per Jessen, Zürich (20.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 18:21 +0200, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 14:07, Per Jessen wrote:
Carlos E. R. wrote:
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.
It sounds much more like you didn't trust your own machines.
I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.
I thought you had a reserved range that you could allocate as fixed addresses. Something about 20 addresses?
AFAIR, no, it is just the global DHCP (or whatever method) pool. The wifi configuration of my current router page says, that it allows 64 guest clients. Says nothing about an VLAN for them. The "isolate client" tick is just a wifi thing: a client will not see the radio transmission intended for another client. I believe it is just that. Ok, maybe some feature appears only when guest is enabled. Trying. [...] Nay. I can not even configure the password for the guests ssid. Ah, yes, I can, found it.
The only thing the guest wifi has is a different ssid and password, so you do not have to give the main one. And that guest password can be cycled.
Our wifi password is just "password" and I give it to anyone who wants it.
:-D mine is more complex.
Do you know that all Telefónica routers use the same user, ie "1234" and is hardcoded? And back then, not 1754 but 2010 or thereabouts, used the same password?
Well, that isn't too unlike Netgear and Tp-Link and D-link etc. By default they also all comes with the same admin userid and password. I was not aware that it was hardcoded in Telefonica equipment, but nothing surprises me about Telefonica any more. I think everyone is just amazed that you keep using them.
Oh, they learn. The fibre routers I have seen all had a custom password written in the label or sticker all routers have. Same as commercial (home grade) we can buy. Still, the user is 1234 and can not be changed. As to why we use them, I feel in the family, million of us do use them. Ask Daniel :-) - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE1Vahwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVQfUAniMoOLfM2ErgDD1oxzNJ Y9DMOvd+AJ0YwlZX3BmBVl7mqy6vnL+8Kc6xIw== =UdtL -----END PGP SIGNATURE-----
Carlos E. R. wrote:
On Saturday, 2023-04-29 at 18:21 +0200, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 14:07, Per Jessen wrote:
Carlos E. R. wrote:
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.
It sounds much more like you didn't trust your own machines.
I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.
I thought you had a reserved range that you could allocate as fixed addresses. Something about 20 addresses?
AFAIR, no, it is just the global DHCP (or whatever method) pool.
So ... I'm curious, how do you guarantee fixed, known addresses for your machines? I tried searching, but google is not up-to-date with our archives. I feel so sure you mentioned something about a reserved range not used for dhcp.
The wifi configuration of my current router page says, that it allows 64 guest clients. Says nothing about an VLAN for them.
Any VLAN would be assigned to the SSID, not the clients.
Well, that isn't too unlike Netgear and Tp-Link and D-link etc. By default they also all comes with the same admin userid and password. I was not aware that it was hardcoded in Telefonica equipment, but nothing surprises me about Telefonica any more. I think everyone is just amazed that you keep using them.
Oh, they learn. The fibre routers I have seen all had a custom password written in the label or sticker all routers have. Same as commercial (home grade) we can buy. Still, the user is 1234 and can not be changed.
As to why we use them, I feel in the family, million of us do use them.
Yep. Millions of flies can't be wrong. -- Per Jessen, Zürich (18.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-29 20:15, Per Jessen wrote:
Carlos E. R. wrote:
On Saturday, 2023-04-29 at 18:21 +0200, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 14:07, Per Jessen wrote:
Carlos E. R. wrote:
> 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.
It sounds much more like you didn't trust your own machines.
I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.
I thought you had a reserved range that you could allocate as fixed addresses. Something about 20 addresses?
AFAIR, no, it is just the global DHCP (or whatever method) pool.
So ... I'm curious, how do you guarantee fixed, known addresses for your machines? I tried searching, but google is not up-to-date with our archives. I feel so sure you mentioned something about a reserved range not used for dhcp.
I can use static leases defined in the router (there is a limited number of them, maybe 30), or I configure a static address in the computer. Ah, that's something not feasible with my IPv6 (aside from ULA). But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.
The wifi configuration of my current router page says, that it allows 64 guest clients. Says nothing about an VLAN for them.
Any VLAN would be assigned to the SSID, not the clients.
Ok, but no such a thing, AFAIK. There is VLAN support, but can not assign an VLAN to the guest wifi config.
Well, that isn't too unlike Netgear and Tp-Link and D-link etc. By default they also all comes with the same admin userid and password. I was not aware that it was hardcoded in Telefonica equipment, but nothing surprises me about Telefonica any more. I think everyone is just amazed that you keep using them.
Oh, they learn. The fibre routers I have seen all had a custom password written in the label or sticker all routers have. Same as commercial (home grade) we can buy. Still, the user is 1234 and can not be changed.
As to why we use them, I feel in the family, million of us do use them.
Yep. Millions of flies can't be wrong.
I was hoping you didn't remember that saying :-p -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-29 20:15, Per Jessen wrote:
Carlos E. R. wrote:
So ... I'm curious, how do you guarantee fixed, known addresses for your machines? I tried searching, but google is not up-to-date with our archives. I feel so sure you mentioned something about a reserved range not used for dhcp.
I can use static leases defined in the router (there is a limited number of them, maybe 30),
Ah, maybe that is I'm thinking of.
or I configure a static address in the computer.
It won't help if dhcp has dished out a fixed address to somebody else.
Ah, that's something not feasible with my IPv6 (aside from ULA).
Well, your router seems to leave a lot to be desired.
But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.
It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.
The wifi configuration of my current router page says, that it allows 64 guest clients. Says nothing about an VLAN for them.
Any VLAN would be assigned to the SSID, not the clients.
Ok, but no such a thing, AFAIK.
There is VLAN support, but can not assign an VLAN to the guest wifi config.
It is a pretty unusual thing to find in a consumer network. For one thing, you need managed switches which are also quite rare in a consumer network. -- Per Jessen, Zürich (15.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-29 21:07, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 20:15, Per Jessen wrote:
Carlos E. R. wrote:
So ... I'm curious, how do you guarantee fixed, known addresses for your machines? I tried searching, but google is not up-to-date with our archives. I feel so sure you mentioned something about a reserved range not used for dhcp.
I can use static leases defined in the router (there is a limited number of them, maybe 30),
Ah, maybe that is I'm thinking of.
or I configure a static address in the computer.
It won't help if dhcp has dished out a fixed address to somebody else.
No, different ranges. Basically, 192.168.1.0/16 is for myself (except an area the router uses for its own vlans), and 192.168.2.0/16 is for dhcp. Yes, /16, not /24: they are not sublans, just different administrative ranges.
Ah, that's something not feasible with my IPv6 (aside from ULA).
Well, your router seems to leave a lot to be desired.
Certainly.
But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.
It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.
I do that. But there is nothing that impedes a guest machine from reading a share in any other machine. It is all a single /16.
The wifi configuration of my current router page says, that it allows 64 guest clients. Says nothing about an VLAN for them.
Any VLAN would be assigned to the SSID, not the clients.
Ok, but no such a thing, AFAIK.
There is VLAN support, but can not assign an VLAN to the guest wifi config.
It is a pretty unusual thing to find in a consumer network. For one thing, you need managed switches which are also quite rare in a consumer network.
I have managed switches. But again, the problem is that the router doesn't assign a separate VLAN to guest machines over WiFi. I can do VLANS on eth if I wished. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-29 21:07, Per Jessen wrote:
But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.
It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.
I do that. But there is nothing that impedes a guest machine from reading a share in any other machine. It is all a single /16.
Ever heard of firewalls? When you know "all known machines" are in 192.168.34.0/24 and "everything else" is in 192.168.101.0/24, it is easy to permit everything between "all known machines" and isolate them from "everything else". That is what I do with my home "subnet" ranges I posted at some point. They are all in a single /64. Disclaimer: not a ready-to-go solution, just for inspiration. The rest is up to the reader. Maybe require some reading. -- Per Jessen, Zürich (13.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 08:59, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 21:07, Per Jessen wrote:
But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.
It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.
I do that. But there is nothing that impedes a guest machine from reading a share in any other machine. It is all a single /16.
Ever heard of firewalls?
I did say "with my existing hardware" :-) If not in this post, in another.
When you know "all known machines" are in 192.168.34.0/24 and "everything else" is in 192.168.101.0/24, it is easy to permit everything between "all known machines" and isolate them from "everything else".
Certainly. But with my existing hardware, I can not put guests in another LAN. I know very well how to do it, but my existing hardware is not capable. MEANING. I have both a router and a wiFi access point. Both have "guest wifi" setup. NONE of them assigns a different (SUB)LAN to them. To do that, I need a third AP with its own DHCP server and using a different LAN. And some eth mouths, one for input, several for output (mind: my existing AP doesn't separate those ETH mouths AFAIR). It is perfectly doable, I know how to do that. But it is new hardware, new expense, new management time. I simply say that my existing hardware, and this is a common complaint, despite claiming they can do guest handling, really don't. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 08:59, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 21:07, Per Jessen wrote:
But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.
It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.
I do that. But there is nothing that impedes a guest machine from reading a share in any other machine. It is all a single /16.
Ever heard of firewalls?
I did say "with my existing hardware" :-) If not in this post, in another.
Maybe you did, but what is the significance? you don't need extra hardware to set up a firewall.
Certainly. But with my existing hardware, I can not put guests in another LAN.
I never suggested you should. It might provide extra separation and better options for performance, but in a household context, those are not particularly relevant. On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP Disclaimer: not a ready-to-go solution, just for inspiration. The rest is up to the reader. Might require some reading. -- Per Jessen, Zürich (15.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 11:58, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 08:59, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 21:07, Per Jessen wrote:
But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.
It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.
I do that. But there is nothing that impedes a guest machine from reading a share in any other machine. It is all a single /16.
Ever heard of firewalls?
I did say "with my existing hardware" :-) If not in this post, in another.
Maybe you did, but what is the significance? you don't need extra hardware to set up a firewall.
Certainly. But with my existing hardware, I can not put guests in another LAN.
I never suggested you should. It might provide extra separation and better options for performance, but in a household context, those are not particularly relevant.
On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP
All that is very nice, but I do need new hardware to assign 192.168.101.0/24 to guests. Currently I have no way to do that. DHCP is handled by the router. The router has no capability to assign a different range to clients that connect to the guest SSID. And before you ask, no, I can not put DHCP on a different machine without breaking TV and who knows what. For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.
Disclaimer: not a ready-to-go solution, just for inspiration. The rest is up to the reader. Might require some reading.
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP
All that is very nice, but I do need new hardware to assign 192.168.101.0/24 to guests. Currently I have no way to do that.
I thought you said your router supported allocating fixed addresses, up to 30 ?
For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.
That is fine - assign fixed addresses to the household machines. Disclaimer: not a ready-to-go solution, just for inspiration. The rest is up to the reader. Might require some reading. -- Per Jessen, Zürich (16.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 12:34, Per Jessen wrote:
Carlos E. R. wrote:
On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP
All that is very nice, but I do need new hardware to assign 192.168.101.0/24 to guests. Currently I have no way to do that.
I thought you said your router supported allocating fixed addresses, up to 30 ?
Ok, yes, but I'm not going to bother to use those for guests. Too much work. Allow them to connect find the MAC, write the config, force them to re-connect. No.
For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.
That is fine - assign fixed addresses to the household machines.
Bufff. I did, most of them... then replaced the router and config destroyed. I'm too lazy, I only assign IPs to machines that I really need to know what address they have, to give them access to an NFS share or otherwise punch a hole in the firewall. There are even virtual machines that get their IP from the house router.
Disclaimer: not a ready-to-go solution, just for inspiration. The rest is up to the reader. Might require some reading.
I understand what you are suggesting, I know how to do that, but... no. Too much work, and too few slots. Yeah, instead, all my important machines have a firewall to inside. No, the only safe and proper way is another AP router, handling DHCP and having a firewall and a distinct IP range. That is an effort I would do if the expense were justified. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 12:34, Per Jessen wrote:
Carlos E. R. wrote:
On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP
All that is very nice, but I do need new hardware to assign 192.168.101.0/24 to guests. Currently I have no way to do that.
I thought you said your router supported allocating fixed addresses, up to 30 ?
Ok, yes, but I'm not going to bother to use those for guests. Too much work.
I didn't suggest that.
For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.
That is fine - assign fixed addresses to the household machines.
Bufff. I did, most of them... then replaced the router and config destroyed. I'm too lazy,
Actually, you are not lazy enough or you have too much time an your hands. You spend days fiddling with a tedious firewall setup, dragging around age old stuff that you have long forgotten the purpose of, trying to figure out if a dhcp client request should be allowed or not. I am lazy or I don't have enough time - I can't be bothered with all that tedium. Split the machines into trusted and untrusted (simplified) and set up rules for trusted and unstrusted. Essentially two rules, all done. -- Per Jessen, Zürich (15.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 14:12, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 12:34, Per Jessen wrote:
Carlos E. R. wrote:
On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP
All that is very nice, but I do need new hardware to assign 192.168.101.0/24 to guests. Currently I have no way to do that.
I thought you said your router supported allocating fixed addresses, up to 30 ?
Ok, yes, but I'm not going to bother to use those for guests. Too much work.
I didn't suggest that.
For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.
That is fine - assign fixed addresses to the household machines.
Bufff. I did, most of them... then replaced the router and config destroyed. I'm too lazy,
Actually, you are not lazy enough or you have too much time an your hands.
You spend days fiddling with a tedious firewall setup, dragging around age old stuff that you have long forgotten the purpose of, trying to figure out if a dhcp client request should be allowed or not.
That's an itch that I like scratching, and it is just now. It is something new to learn about. Yes, and now I'm doing it again, on the desktop machine. The other thing would be for ever.
I am lazy or I don't have enough time - I can't be bothered with all that tedium. Split the machines into trusted and untrusted (simplified) and set up rules for trusted and unstrusted. Essentially two rules, all done.
:-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 4/30/23 03:09, Carlos E. R. wrote:
And before you ask, no, I can not put DHCP on a different machine without breaking TV and who knows what.
Do you have a separate modem or something for the TV? How does all that work? Do you feed the TV(s) from a coax cable? Where does the phone connect? It's a serious question, we've got only a coax feed from the ISP that handles VOIP, IP, and TV. I wish we could get a direct fiber connection, but it's not available. Fiber runs down the street here, but it daisy-chains utility boxes in the street that in turn feed RG-6 coax that leads to the houses. One box feeds about eight houses. It's all underground. Inside the house the single coax is split into three with a regular passive splitter which in turn feeds a VOIP modem, my DOCSIS 3.1 cable modem, and a Tivo Romaio DVR. The Romaio is the master of the Tivo network which in turn feeds four Tivo "Mini" interfaces via TCP-IP over wired Ethernet. The Minis are next to the TV's and feed them via HDMI cables. The master has six tuners, so it can handle four Minis and also record two channels for later viewing. It can record six channels if none of the Minis are active. Three TV's lack a Mini, they get their content via IP over WiFi. Tivo is great, it allows us to skip over advertisements! Before you comment on the absurd number of TV's, realize that we have lots of family living here with us. Not that we want them here, but the declining standard of living that we're experiencing here in California limits their options to live on their own, and I don't want to see them living on the streets.
For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.
I've got an Asus RT-AC68U that provides an isolated guest network on both 2.4 and 5 GHz. I go further and have that router on it's own isolated subnet on my Zyxel router. Of course I've got IPv6 disabled here as well as on my main router. NAT keeps me as snug as a bug in a rug without complicating my life, it's bad enough as it is. Regards, Lew
On 2023-04-30 18:29, Lew Wolfgang wrote:
On 4/30/23 03:09, Carlos E. R. wrote:
And before you ask, no, I can not put DHCP on a different machine without breaking TV and who knows what.
Do you have a separate modem or something for the TV? How does all that work? Do you feed the TV(s) from a coax cable? Where does the phone connect?
The "old" setup: --fibre---ONT---ROUTER----TV_DECO \ \----computers phones ONT → <https://en.wikipedia.org/wiki/Network_interface_device#Optical_network_terminals> Only that it is not external, but internal, in the wall of the sitting room TV cabinet. Then, recently they removed the ONT, replaced the router and DECO: WiFi (2 and 5G) Y --fibre---ROUTER----TV_DECO | \----computers | phones It is fibre to the home. Somewhere in the block, a single fibre splits to a number of fibres, one per home. Maybe 32. The setup allows 1 gig symmetrical bandwidth. Actual, I measured it. Then I reduced the BW to pay less. The phones are plain old phones, copper, but fed from the router. Mains fails, then no service, unless the client purchases an UPS on his own. Obviously, it is VoIP till the router, then copper. They claim it is impossible to connect standard VoIP phones. In building blocks newer than maybe 20 years, it comes underground, and the building has the ducts and provision for at least three different Telco companies to deploy their hardware and reach each flat. The TV deco gets its signal over ethernet. The deco tells "I want to watch this channel", then the server sends that channel to the house. It uses IGMP broadcasts. I can pause, go back or forward. Whact serials, TV on demand, rent/purchase movies. I can "record" a program from a channel, but it really only saves a pointer or link to the actual recording at the server room. They are erased after 6 months. It also supports Netflix, Prime, Disney, and others. Yes, I can skip adverts in the channels recording, but not those of the ISP, that run before a movie or chapter of a serial. Just one advert. Only one TV set. For more, we have to rent another decoder. One chap reverse engineered the system, and I could watch any channel on my computer. But then they implemented digital right management (not all channels), and the chap disappeared, he stopped supporting the software or answering questions. That software allowed saving a recording on the cloud to a file.
Before you comment on the absurd number of TV's, realize that we have lots of family living here with us. Not that we want them here, but the declining standard of living that we're experiencing here in California limits their options to live on their own, and I don't want to see them living on the streets.
No objections :-) I have 3 TV sets myself: sitting room, the only one on fibre; a smart tv on the kitchen, and a set at the computer room. The later can display from a TV double tuner receiver with hard disk, or display my mini-server, which then can run Firefox and display almost any program from the same Telefónica serving, for free. The TV set is smart because the previous incumbent died. I was using it as auxiliary computer display for my relatives this summer, and it fell. Just half a metre, and fell on top of my leg. Not his intention, but mine: I quickly put my leg in his falling trajectory in an attempt to save its life. Did not work. And it happens than a smart tv is almost the same price as plain tv.
For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.
I've got an Asus RT-AC68U that provides an isolated guest network on both 2.4 and 5 GHz. I go further and have that router on it's own isolated subnet on my Zyxel router.
Of course I've got IPv6 disabled here as well as on my main router. NAT keeps me as snug as a bug in a rug without complicating my life, it's bad enough as it is.
heh :-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Sun, 30 Apr 2023 19:21:12 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
The "old" setup:
--fibre---ONT---ROUTER----TV_DECO \ \----computers phones
ONT → <https://en.wikipedia.org/wiki/Network_interface_device#Optical_network_terminals>
Only that it is not external, but internal, in the wall of the sitting room TV cabinet.
Then, recently they removed the ONT, replaced the router and DECO:
What is a 'DECO'?
On 2023-05-01 11:36, Dave Howorth wrote:
On Sun, 30 Apr 2023 19:21:12 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
The "old" setup:
--fibre---ONT---ROUTER----TV_DECO \ \----computers phones
ONT → <https://en.wikipedia.org/wiki/Network_interface_device#Optical_network_terminals>
Only that it is not external, but internal, in the wall of the sitting room TV cabinet.
Then, recently they removed the ONT, replaced the router and DECO:
What is a 'DECO'?
TV decoder. I don't know exactly how it is called in English. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-01 11:36, Dave Howorth wrote:
What is a 'DECO'?
TV decoder. I don't know exactly how it is called in English.
In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers. -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-01 15:51, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 11:36, Dave Howorth wrote:
What is a 'DECO'?
TV decoder. I don't know exactly how it is called in English.
In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers.
This one is quite different. With cable TV, all channels are sent simultaneously to every home. The box simply tunes one. This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream. If the client wants several TV sets, he has to hire one decoder for each. Or, you can watch a stream on the computer, gratis, if the computer is in the LAN (huh, I have to test if it works now after the firewall upgrade). -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 5/1/23 08:57, Carlos E.R. wrote:
This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.
Uhm..................Not sure that is correct. Spain being in a parallel universe may work that way but I doubt it. All the signals are present all the time. Each is on it's own frequency [ channel ]. The decoder box just tunes in the appropriate frequency that you want. Over the air, cable, satellite all work this way. -- In times of Tyranny and injustice when law oppresses the people, the outlaw takes his place in history. ~ · Robin Hood · 2010 · Screen Title
On Mon, 1 May 2023 09:54:29 -0500 Bill Walsh <bill@kctu.com> wrote:
On 5/1/23 08:57, Carlos E.R. wrote:
This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.
Uhm..................Not sure that is correct. Spain being in a parallel universe may work that way but I doubt it. All the signals are present all the time. Each is on it's own frequency [ channel ]. The decoder box just tunes in the appropriate frequency that you want. Over the air, cable, satellite all work this way.
I think you'll find that digital on-demand systems don't work like that at all. They work as Carlos described. The user initiates a stream at a time of their choosing for the programme of their choosing, and it is sent to them specifically. I suspect the service Carlos is describing is Movistar+
On 2023-05-01 17:49, Dave Howorth wrote:
On Mon, 1 May 2023 09:54:29 -0500 Bill Walsh <bill@kctu.com> wrote:
On 5/1/23 08:57, Carlos E.R. wrote:
This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.
Uhm..................Not sure that is correct. Spain being in a parallel universe may work that way but I doubt it. All the signals are present all the time. Each is on it's own frequency [ channel ]. The decoder box just tunes in the appropriate frequency that you want. Over the air, cable, satellite all work this way.
I think you'll find that digital on-demand systems don't work like that at all. They work as Carlos described. The user initiates a stream at a time of their choosing for the programme of their choosing, and it is sent to them specifically. I suspect the service Carlos is describing is Movistar+
Yes, aka Movistar Fusion. To watch on the computer, this web: https://ver.movistarplus.es/ No credentials needed if used inside the LAN that has a contract. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-05-01 16:54, Bill Walsh wrote:
On 5/1/23 08:57, Carlos E.R. wrote:
This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.
Uhm..................Not sure that is correct. Spain being in a parallel universe may work that way but I doubt it. All the signals are present all the time. Each is on it's own frequency [ channel ]. The decoder box just tunes in the appropriate frequency that you want. Over the air, cable, satellite all work this way.
No, there are no frequencies, it is just one digital stream containing just one live channel, serial, movie or recording. On demand, mostly. This is certain, some people reverse engineered it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E.R. wrote:
On 2023-05-01 15:51, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 11:36, Dave Howorth wrote:
What is a 'DECO'?
TV decoder. I don't know exactly how it is called in English.
In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers.
This one is quite different.
With cable TV, all channels are sent simultaneously to every home. The box simply tunes one.
This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.
Like Bill said, "ummm ...." - doesn't sound right to me either.
If the client wants several TV sets, he has to hire one decoder for each.
Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider?? Besides the excellent ervices of my local streaming service "MythTV", my TV offers a menu of 9-10 different - Samsung TV, Rakuten TV, Amazon Prime, Netflux, Sky, 20minutes and more.
Or, you can watch a stream on the computer, gratis, if the computer is in the LAN
I'm curious, how does your VLC client tell the "cloud" what it wants to watch? -- Per Jessen, Zürich (16.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider??
Hmm, correction - the big providers (at least one) do offer their own hardware, but the smaller providers rely on consumer hardware - Fritz!Box, Apple TVbox and AndroidTV (built-in) - or indeed your own PC. My provcider recommends Fritz!Box. -- Per Jessen, Zürich (15.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 5/1/23 08:42, Per Jessen wrote:
Per Jessen wrote:
Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider?? Hmm, correction - the big providers (at least one) do offer their own hardware, but the smaller providers rely on consumer hardware - Fritz!Box, Apple TVbox and AndroidTV (built-in) - or indeed your own PC. My provcider recommends Fritz!Box.
Do you have paid subscription channels, Per? How is that done? You mentioned that your TV's have card readers, are these cards used as decryption tokens for paid channel subscriptions? Over here they've used things called CableCards that handle the decryption tasks. We've got one in our master Tivo box that can decrypt six channels simultaneously. There used to be a federal requirement that all cable TV companies support CableCards, but that requirement was dropped a few years ago. Now they're supported as a courtesy, and many companies don't support them at all. They expect you to rent their own proprietary decoders. If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. There are still digital over-the-air channels here but we can't receive most of them due local geography. Wolfgang Manor doesn't have line-of-sight to the transmitter sites. Regards, Lew
Lew Wolfgang wrote:
On 5/1/23 08:42, Per Jessen wrote:
Per Jessen wrote:
Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider?? Hmm, correction - the big providers (at least one) do offer their own hardware, but the smaller providers rely on consumer hardware - Fritz!Box, Apple TVbox and AndroidTV (built-in) - or indeed your own PC. My provcider recommends Fritz!Box.
Do you have paid subscription channels, Per? How is that done?
Myself, I'm old fashioned (no comments please) - I only have satellite telly, for more than twenty years. My only paid subscription channels are the Swiss national channels, for which I pay an annual license fee. Because I use satellite, I need a "decoder card", creditcard sized smartcard, which goes in the CI/CA slot on my receiver card. (card = PCI express)
You mentioned that your TV's have card readers, are these cards used as decryption tokens for paid channel subscriptions?
AFAIK, they are CI/CA slots for precisely that. I don't use them though.
Over here they've used things called CableCards that handle the decryption tasks.
I have a suspicion we are talking about exactly the same thing.
them at all. They expect you to rent their own proprietary decoders. If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP.
Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV. -- Per Jessen, Zürich (11.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 5/1/23 10:11, Per Jessen wrote:
them at all. They expect you to rent their own proprietary decoders. If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV.
I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more? I remember hearing about plans for re-using the spectrum. Anything that we currently watch on the telly isn't available OTA anyway. Regards, Lew
On 5/1/23 12:24, Lew Wolfgang wrote:
On 5/1/23 10:11, Per Jessen wrote:
them at all. They expect you to rent their own proprietary decoders. If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV.
I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more? I remember hearing about plans for re-using the spectrum. Anything that we currently watch on the telly isn't available OTA anyway.
Regards, Lew
Cable and satellite were behind the push to digital TV. They thought it would kill OTA. No more "fringe" reception so smaller viewer numbers. It backfired big time. Our station has ten channels on the air. Before digital we could only do one. Most any city with local OTA's will find something on the order of 40 or 50 channels available. We share programming with a friend out in western Kansas. He has multiple stations with multiple channels on each. Major network stations put in repeaters around the state to increase broadcast area. You can now find WAY more TV than you could before digital. Lew, unless your WAY out in the boonies, which I know your not, or down in a deep hole, which I doubt, OR you local TV stations are all stupid and placed their transmitters in the worst possible location(s), I see no reason you should have an issue with OTA. You might need to put up an outdoor antenna. I see twenty channels plus subchannels. https://www.channelmaster.com/pages/tv-antenna-map-san-diego-ca-92129 -- In times of Tyranny and injustice when law oppresses the people, the outlaw takes his place in history. ~ · Robin Hood · 2010 · Screen Title
On 5/1/23 10:55, Bill Walsh wrote:
On 5/1/23 12:24, Lew Wolfgang wrote:
On 5/1/23 10:11, Per Jessen wrote:
them at all. They expect you to rent their own proprietary decoders. If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV.
I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more? I remember hearing about plans for re-using the spectrum. Anything that we currently watch on the telly isn't available OTA anyway.
Cable and satellite were behind the push to digital TV. They thought it would kill OTA. No more "fringe" reception so smaller viewer numbers. It backfired big time. Our station has ten channels on the air. Before digital we could only do one. Most any city with local OTA's will find something on the order of 40 or 50 channels available. We share programming with a friend out in western Kansas. He has multiple stations with multiple channels on each. Major network stations put in repeaters around the state to increase broadcast area. You can now find WAY more TV than you could before digital.
Lew, unless your WAY out in the boonies, which I know your not, or down in a deep hole, which I doubt, OR you local TV stations are all stupid and placed their transmitters in the worst possible location(s), I see no reason you should have an issue with OTA. You might need to put up an outdoor antenna. I see twenty channels plus subchannels.
https://www.channelmaster.com/pages/tv-antenna-map-san-diego-ca-92129
One transmitter site is located on Mount Soledad 22-miles north of us, a second is on Otay Mountain, about 11-miles NE of us. The problem is we're in a bit of a valley. The neighborhood was originally built with 40-foot TV masts on each house, then in the mid 1980's the area was wired for CATV. The antennas then started to disappear. Ours actually fell over of it's own accord around 1989. So going back to OTA would require a significant mast on our roof. Also, note that many of those listed stations are located in Tijuana and are only Spanish speaking. Regards, Lew
On 2023-05-01 21:02, Lew Wolfgang wrote:
On 5/1/23 10:55, Bill Walsh wrote:
On 5/1/23 12:24, Lew Wolfgang wrote:
On 5/1/23 10:11, Per Jessen wrote:
them at all. They expect you to rent their own proprietary decoders. If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV.
I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more? I remember hearing about plans for re-using the spectrum. Anything that we currently watch on the telly isn't available OTA anyway.
Cable and satellite were behind the push to digital TV. They thought it would kill OTA. No more "fringe" reception so smaller viewer numbers. It backfired big time. Our station has ten channels on the air. Before digital we could only do one. Most any city with local OTA's will find something on the order of 40 or 50 channels available. We share programming with a friend out in western Kansas. He has multiple stations with multiple channels on each. Major network stations put in repeaters around the state to increase broadcast area. You can now find WAY more TV than you could before digital.
Lew, unless your WAY out in the boonies, which I know your not, or down in a deep hole, which I doubt, OR you local TV stations are all stupid and placed their transmitters in the worst possible location(s), I see no reason you should have an issue with OTA. You might need to put up an outdoor antenna. I see twenty channels plus subchannels.
https://www.channelmaster.com/pages/tv-antenna-map-san-diego-ca-92129
One transmitter site is located on Mount Soledad 22-miles north of us, a second is on Otay Mountain, about 11-miles NE of us. The problem is we're in a bit of a valley. The neighborhood was originally built with 40-foot TV masts on each house, then in the mid 1980's the area was wired for CATV. The antennas then started to disappear. Ours actually fell over of it's own accord around 1989. So going back to OTA would require a significant mast on our roof. Also, note that many of those listed stations are located in Tijuana and are only Spanish speaking.
Just have the community put a digital transmitter in the centre of the valley. 20 channels at least. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 5/1/23 12:51, Carlos E. R. wrote:
One transmitter site is located on Mount Soledad 22-miles north of us, a second is on Otay Mountain, about 11-miles NE of us. The problem is we're in a bit of a valley. The neighborhood was originally built with
40-foot TV masts on each house, then in the mid 1980's the area was wired for CATV. The antennas then started to disappear. Ours actually fell over of it's own accord around 1989. So going back to OTA would require a significant mast on our roof. Also, note that many of those listed stations are located in Tijuana and are only Spanish speaking.
Just have the community put a digital transmitter in the centre of the valley. 20 channels at least.
Easier said than done. Leasing tower space, obtaining right-of-entry, FCC licensing and permits, etc. Studies would have to be done to identify interference problems, jurisdictional overlaps, threats to endangered species, effects on carbon footprints, and such. It would be a nightmare. You might recall that a couple of months ago I was looking into Internet access via microwave link? The company came out and determined that we were dark for their service. There's a good antenna farm not too far away and the guy said they've tried to install their repeater there, but they just couldn't get things lined up. Remember, this is California, the home of Big Government and the Regulation State. Regards, Lew
On 2023-05-01 22:11, Lew Wolfgang wrote:
On 5/1/23 12:51, Carlos E. R. wrote:
One transmitter site is located on Mount Soledad 22-miles north of us, a second is on Otay Mountain, about 11-miles NE of us. The problem is we're in a bit of a valley. The neighborhood was originally built with 40-foot TV masts on each house, then in the mid 1980's the area was wired for CATV. The antennas then started to disappear. Ours actually fell over of it's own accord around 1989. So going back to OTA would require a significant mast on our roof. Also, note that many of those listed stations are located in Tijuana and are only Spanish speaking.
Just have the community put a digital transmitter in the centre of the valley. 20 channels at least.
Easier said than done. Leasing tower space, obtaining right-of-entry, FCC licensing and permits, etc. Studies would have to be done to identify interference problems, jurisdictional overlaps, threats to endangered species, effects on carbon footprints, and such. It would be a nightmare.
Same as in any modern country. Yet we do it.
You might recall that a couple of months ago I was looking into Internet access via microwave link? The company came out and determined that we were dark for their service. There's a good antenna farm not too far away and the guy said they've tried to install their repeater there, but they just couldn't get things lined up. Remember, this is California, the home of Big Government and the Regulation State.
Just come over here and compare. Yet we do it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 5/1/23 15:18, Carlos E. R. wrote:
On 2023-05-01 22:11, Lew Wolfgang wrote:
On 5/1/23 12:51, Carlos E. R. wrote:
One transmitter site is located on Mount Soledad 22-miles north of us, a second is on Otay Mountain, about 11-miles NE of us. The problem is we're in a bit of a valley. The neighborhood was originally built with
40-foot TV masts on each house, then in the mid 1980's the area was wired for CATV. The antennas then started to disappear. Ours actually
fell over of it's own accord around 1989. So going back to OTA would require a significant mast on our roof. Also, note that many of those listed stations are located in Tijuana and are only Spanish speaking.
Just have the community put a digital transmitter in the centre of the valley. 20 channels at least.
Easier said than done. Leasing tower space, obtaining right-of-entry, FCC licensing and permits, etc. Studies would have to be done to identify interference problems, jurisdictional overlaps, threats to endangered species, effects on carbon footprints, and such. It would be a nightmare.
Same as in any modern country. Yet we do it.
You might recall that a couple of months ago I was looking into Internet access via microwave link? The company came out and determined that we were dark for their service. There's a good antenna farm not too far away and the guy said they've tried to install their repeater there, but they just couldn't get things lined up. Remember, this is California, the home of Big Government and the Regulation State.
Just come over here and compare. Yet we do it.
Or come to the land of freedom. I have a 65 foot tower on the north end of the house and a 75 foot tower on the south. No regulations. No environmental impacts. Put them up myself just because I wanted them. -- In times of Tyranny and injustice when law oppresses the people, the outlaw takes his place in history. ~ · Robin Hood · 2010 · Screen Title
On 5/1/23 13:18, Carlos E. R. wrote:
On 2023-05-01 22:11, Lew Wolfgang wrote:
On 5/1/23 12:51, Carlos E. R. wrote:
Just have the community put a digital transmitter in the centre of the valley. 20 channels at least.
Easier said than done. Leasing tower space, obtaining right-of-entry, FCC licensing and permits, etc. Studies would have to be done to identify interference problems, jurisdictional overlaps, threats to endangered species, effects on carbon footprints, and such. It would be a nightmare.
Same as in any modern country. Yet we do it.
Your country allows television stations to be created and operated without any governmental oversight? What if your frequencies interfere with other areas? Can you, as a amateur radio operator, operate at any frequency and power?
You might recall that a couple of months ago I was looking into Internet access via microwave link? The company came out and determined that we were dark for their service. There's a good antenna farm not too far away and the guy said they've tried to install their repeater there, but they just couldn't get things lined up. Remember, this is California, the home of Big Government and the Regulation State.
Just come over here and compare. Yet we do it.
I doubt it with regard to rogue television or radio stations. Can you cite any examples? Over here, back in the early 1960's, small communities would do exactly as you suggest. It was the beginning of the cable television industry. I even remember seeing a repeater in a field in New Jersey where we used to hunt that relayed TV signals to a small village at the bottom of a large cliff. Now you'd have to have carriage agreements with all the content providers and pay them money for relaying their signals. Then there are easements and permissions from local jurisdictions for digging up the streets, for cable signal distribution anyway. We're wandering into the off-topic area again. Interesting stuff but possibly boring to many readers. Regards, Lew
On 2023-05-02 02:09, Lew Wolfgang wrote:
On 5/1/23 13:18, Carlos E. R. wrote:
On 2023-05-01 22:11, Lew Wolfgang wrote:
On 5/1/23 12:51, Carlos E. R. wrote:
Just have the community put a digital transmitter in the centre of the valley. 20 channels at least.
Easier said than done. Leasing tower space, obtaining right-of-entry, FCC licensing and permits, etc. Studies would have to be done to identify interference problems, jurisdictional overlaps, threats to endangered species, effects on carbon footprints, and such. It would be a nightmare.
Same as in any modern country. Yet we do it.
Your country allows television stations to be created and operated without any governmental oversight? What if your frequencies interfere with other areas? Can you, as a amateur radio operator, operate at any frequency and power?
Of course not. I'm saying the reverse: we have more strict requirements and red tape than you do, yet we don't complain and get things done. No rogue TV. Just comply and hard work. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-05-01 19:24, Lew Wolfgang wrote:
On 5/1/23 10:11, Per Jessen wrote:
them at all. They expect you to rent their own proprietary decoders. If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV.
I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more? I remember hearing about plans for re-using the spectrum. Anything that we currently watch on the telly isn't available OTA anyway.
Not here at all. Over the air TV is just fine and strong. Digital Terrestrial Television, aka TDT <https://en.wikipedia.org/wiki/Digital_terrestrial_television#Spain> <https://en.wikipedia.org/wiki/Television_in_Spain> <https://es.wikipedia.org/wiki/Televisi%C3%B3n_digital_terrestre#Espa%C3%B1a> <https://es.wikipedia.org/wiki/Televisi%C3%B3n_digital_terrestre_en_Espa%C3%B1a> In fact, they are applying a second plan since 2019. Going for HD and further. It is a loooong article with all the gory details. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 5/1/23 12:49, Carlos E. R. wrote:
I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more? I remember hearing about plans for re-using the spectrum. Anything that we currently watch on the telly isn't available OTA anyway.
Not here at all. Over the air TV is just fine and strong. Digital Terrestrial Television, aka TDT
I guess I'm mistaken about OTA TV going away. Indeed, there's now a spec called ATSC 3.0 that allows 4K and things like Dolby Atmos. We haven't watched OTA for more than 30-years. Regards, Lew
* Per Jessen <per@opensuse.org> [05-01-23 13:12]:
Lew Wolfgang wrote:
On 5/1/23 08:42, Per Jessen wrote:
Per Jessen wrote:
Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider?? Hmm, correction - the big providers (at least one) do offer their own hardware, but the smaller providers rely on consumer hardware - Fritz!Box, Apple TVbox and AndroidTV (built-in) - or indeed your own PC. My provcider recommends Fritz!Box.
Do you have paid subscription channels, Per? How is that done?
Myself, I'm old fashioned (no comments please) - I only have satellite telly, for more than twenty years. My only paid subscription channels are the Swiss national channels, for which I pay an annual license fee. Because I use satellite, I need a "decoder card", creditcard sized smartcard, which goes in the CI/CA slot on my receiver card. (card = PCI express)
You mentioned that your TV's have card readers, are these cards used as decryption tokens for paid channel subscriptions?
AFAIK, they are CI/CA slots for precisely that. I don't use them though.
Over here they've used things called CableCards that handle the decryption tasks.
I have a suspicion we are talking about exactly the same thing.
them at all. They expect you to rent their own proprietary decoders. If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP.
Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV.
I have Amazon Recast with an outside antenna attached for ota channels and receive 60-80 different signals with a few being rather weak and many duplicates. with the Recast (out of production), I can record two channels and watch two channels at the same time, similar to tivo I guess. here in the flat-lands, there is rather easy/ample access to ota channels. I converted my satellite mount to attach a yagi antenna and used the previous wire feed into the house to my Recast. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2023-05-01 17:31, Per Jessen wrote:
Carlos E.R. wrote:
On 2023-05-01 15:51, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 11:36, Dave Howorth wrote:
What is a 'DECO'?
TV decoder. I don't know exactly how it is called in English.
In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers.
This one is quite different.
With cable TV, all channels are sent simultaneously to every home. The box simply tunes one.
This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.
Like Bill said, "ummm ...." - doesn't sound right to me either.
If the client wants several TV sets, he has to hire one decoder for each.
Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider??
Absolutely. And pay the rent, the decoder is rented, not sold.
Besides the excellent ervices of my local streaming service "MythTV", my TV offers a menu of 9-10 different - Samsung TV, Rakuten TV, Amazon Prime, Netflux, Sky, 20minutes and more.
Or, you can watch a stream on the computer, gratis, if the computer is in the LAN
I'm curious, how does your VLC client tell the "cloud" what it wants to watch?
No VLC. Chrome or Firefox. VLC was reverse engineered, there was a list of URLS: #EXTINF:-1,[000] Movistar+ HD rtp://@239.0.5.185:8208 #EXTINF:-1,[001] La 1 HD rtp://@239.0.0.185:8208 #EXTINF:-1,[002] La 2 HD rtp://@239.0.0.183:8208 #EXTINF:-1,[003] Antena 3 HD rtp://@239.0.0.186:8208 #EXTINF:-1,[004] Cuatro HD rtp://@239.0.0.177:8208 #EXTINF:-1,[005] Tele 5 HD rtp://@239.0.0.176:8208 #EXTINF:-1,[006] La Sexta HD rtp://@239.0.0.187:8208 ... https://www.web-futbol.com/lista-actualizada-de-canales-para-vlc-2020/ Section "Fibra (FTTH) – Canales HD" I just tried the last one, it works. An updated list, but might not be the same thing, might be IPTV instead: https://www.audiencesusa.com/listas-de-canales-iptv/vlc-player/ -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
TV tuner as in “over the air” broadcasts were on a specific frequency and had to be ’tuned’ in. Ken Schneider
On May 1, 2023, at 9:51 AM, Per Jessen <per@opensuse.org> wrote:
Carlos E. R. wrote:
On 2023-05-01 11:36, Dave Howorth wrote: What is a 'DECO'?
TV decoder. I don't know exactly how it is called in English.
In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers.
-- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Mon, 01 May 2023 15:51:23 +0200 Per Jessen <per@opensuse.org> wrote:
Carlos E. R. wrote:
On 2023-05-01 11:36, Dave Howorth wrote:
What is a 'DECO'?
TV decoder. I don't know exactly how it is called in English.
In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers.
Thanks, I've heard of set top boxes but think of them as an American thing. Wikipedia has more explanation of the possibilities than anybody could want: https://en.wikipedia.org/wiki/Set-top_box But I understand the general idea now, thanks Per & Carlos. For me TV still comes over the air and requires a tuner, nowadays followed by a demultiplexor, before there's a stream that can be interpreted by a display processor. I believe in a year or two my landline will stop working and I will need to have new equipment that requires the power to be on in order to report a power failure :( Progress!
On 4/29/23 05:34, Carlos E. R. wrote:
It sounds much more like you didn't trust your own machines.
I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.
This is exactly what I do with my IPv4 router. I've got physically separate Ethernet connections for trusted computers, for WiFi, and for IOT devices such as smart televisions, light bulbs, security cameras, etc. Thus the untrusted, and possibly malicious, devices have no way to connect to my important hosts. IOT devices are particularly hazardous since their insecurities are legend, and they never get firmware updates once deployed. This separation is what I was unable to do in IPv6 a few years ago. While it might be possible now (different router, etc) I don't see any clear reason to pursue it. My IPv6 "itch" is not that great, and the risks of screwing it up up are real. The concept of separating trust classes of traffic for home networks is valid and is worth taking about here, IMHO. Regards, Lew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 10:22 -0700, Lew Wolfgang wrote:
On 4/29/23 05:34, Carlos E. R. wrote: It sounds much more like you didn't trust your own machines.
I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.
Oh, both my switches have VLAN capability. But not my WiFi points. I could, of course, buy a new wifi router and just assign it a new range. But I'm not going to do that expense. - -- Cheers. -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE1WYhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVYWIAn1iswQv8eZ6kSboiS8if uyZ8i985AJ4sPGAmPBu1aj5FxI9+Lm+NoC7FFw== =130t -----END PGP SIGNATURE-----
On Thu, 27 Apr 2023 13:12:45 +0200 Per Jessen <per@opensuse.org> wrote:
Dave Howorth wrote:
On Thu, 27 Apr 2023 08:58:44 +0200 Per Jessen <per@opensuse.org> wrote:
per@office64:~> unzip -l Documents/surbl-stats.ods Archive: Documents/surbl-stats.ods Length Date Time Name -------- ---- ---- ---- 46 07-24-09 06:44 mimetype 423142 07-24-09 06:44 content.xml 6168 07-24-09 06:44 styles.xml 914 07-24-09 06:44 meta.xml 9768 07-24-09 06:44 Thumbnails/thumbnail.png [snip] 9069 07-24-09 06:44 settings.xml 1873 07-24-09 06:44 META-INF/manifest.xml -------- ------- 450980 15 files
Right, but there are no XML files there that could be accidently edited, so no need for any warnings about editing them :) So a poor choice of counterexample?
Yeah I admit it, it was a slightly poor example :-) Still, the key message remains the same - excluding certain common examples, XML files are not for human processing, accidentally or otherwise. When they are made human-readable with newlines and indentation, it is for debugging purposes.
Maybe these are better examples ?
/var/lib/wicked/ (three XML files) all openSUSE repodata (1270 files on my mirror)
Yes, I think so. (I have 4 files :) I think they may illustrate another point, which is that applications writing XML files should always use an XML library to do so. With something as short as a couple of those files, it's easy to be tempted to write them directly, but that's nearly always a bad idea. XML is a bit like cryptography - there's enough gotchas that you always want to use something that's been tested elsewhere. Corrupt XML files are a nightmare.
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
We went over this, but it is even worse: Telcontar:/etc/firewalld # firewall-cmd --check-config Error: INVALID_ZONE: 'external.xml': not a valid zone file: mismatched tag: line 176, column 4 Telcontar:/etc/firewalld # <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="20" protocol="tcp"/> <accept/> </rule> <!-- comment --> <rule family="ipv4"> <source address="192.168.1.57/32"/> <port port="53633" protocol="tcp"/> <accept/> </rule> Can't write comments in the file at all, even renouncing to using the commands. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
We went over this, but it is even worse:
Telcontar:/etc/firewalld # firewall-cmd --check-config Error: INVALID_ZONE: 'external.xml': not a valid zone file: mismatched tag: line 176, column 4
At first glance, that seems to be a bug - even if that config file is not intended as a user interface. Adding a comment is perfectly valid XML. Second glance - with the virtually empty config, I added a comment and "--check-config" reported "success". You could try feeding the XML to a validator - or use "xmllint" if you have that installed. https://www.w3schools.com/xml/xml_validator.asp xmllint your.xml.file -- Per Jessen, Zürich (17.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-01 15:30, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-26 08:45, Per Jessen wrote:
Carlos E. R. wrote:
(Can I write comments in xml file /etc/firewalld/zones/external.xml?)
Yes, use "<!-- comment -->". Can span multiple lines.
We went over this, but it is even worse:
Telcontar:/etc/firewalld # firewall-cmd --check-config Error: INVALID_ZONE: 'external.xml': not a valid zone file: mismatched tag: line 176, column 4
At first glance, that seems to be a bug - even if that config file is not intended as a user interface. Adding a comment is perfectly valid XML.
Second glance - with the virtually empty config, I added a comment and "--check-config" reported "success".
You could try feeding the XML to a validator - or use "xmllint" if you have that installed.
https://www.w3schools.com/xml/xml_validator.asp
xmllint your.xml.file
It just prints my file back. Oh, now the comment works. Go figure. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-01 15:30, Per Jessen wrote:
xmllint your.xml.file
It just prints my file back.
Good. That means it found no problem in that file. -- Per Jessen, Zürich (11.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-02 08:22, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:30, Per Jessen wrote:
xmllint your.xml.file
It just prints my file back.
Good. That means it found no problem in that file.
What does it do when there is a problem? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-02 08:22, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:30, Per Jessen wrote:
xmllint your.xml.file
It just prints my file back.
Good. That means it found no problem in that file.
What does it do when there is a problem?
If you had introduced an error and tried it, you would have had an answer in seconds :-) The answer is - it complains. -- Per Jessen, Zürich (16.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-02 13:07, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-02 08:22, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:30, Per Jessen wrote:
xmllint your.xml.file
It just prints my file back.
Good. That means it found no problem in that file.
What does it do when there is a problem?
If you had introduced an error and tried it, you would have had an answer in seconds :-)
The answer is - it complains.
I mean, is it obvious to see? Don't I have to go up a kilometre of print to see it up there, out of sight? I would expect to see just a message like "good" or "bad", a single line. With all that print, I can not put it in my CLI:
Telcontar:/etc/firewalld # firewall-cmd --check-config && firewall-offline-cmd --check-config && firewall-cmd --reload && tail -n 100 /var/log/firewalld | grep `date -u +"%Y-%m-%d-%H"` success WARNING: 'NoneType' object has no attribute 'check': None WARNING: 'NoneType' object has no attribute 'check': None success Telcontar:/etc/firewalld #
# xmllint zones/external.xml just prints the file and I can't know where is the line that produces that warning. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-02 13:07, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-02 08:22, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:30, Per Jessen wrote:
xmllint your.xml.file
It just prints my file back.
Good. That means it found no problem in that file.
What does it do when there is a problem?
If you had introduced an error and tried it, you would have had an answer in seconds :-)
The answer is - it complains.
I mean, is it obvious to see? Don't I have to go up a kilometre of print to see it up there, out of sight?
Again, if you had tried it, you would have had an answer in seconds :-) xmllint - <<KKK <carlos> <elem1>text</elem1> </carlo> KKK per@janeway:~> xmllint klop.xml klop.xml:776: parser error : Opening and ending tag mismatch: interface line 774 and zone </zone> ^ klop.xml:777: parser error : Premature end of data in tag zone line 2 ^ "klop.xml" is a copy of external.xml from the firewalld config, with a minor typo in line 774.
I would expect to see just a message like "good" or "bad", a single line.
Well. Other people might expect a return code indicating failure or success. By default, xmllint prints the parsed tree. Add argument '--noout' if you don't want that.
With all that print, I can not put it in my CLI:
Telcontar:/etc/firewalld # firewall-cmd --check-config && firewall-offline-cmd --check-config && firewall-cmd --reload && tail -n 100 /var/log/firewalld | grep `date -u +"%Y-%m-%d-%H"` success WARNING: 'NoneType' object has no attribute 'check': None WARNING: 'NoneType' object has no attribute 'check': None success Telcontar:/etc/firewalld #
The above has got nothing to do with xmllint, but it sounds like it checks against an xml schema and finds an unwanted/undefined attribute. Hmm, maybe not - there is no schema specified in that file.
# xmllint zones/external.xml
just prints the file and I can't know where is the line that produces that warning.
xmllint in the basic invocation only checks for the XML being well-formed, i.e. syntactically correct. -- Per Jessen, Zürich (18.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-02 13:50, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-02 13:07, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-02 08:22, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:30, Per Jessen wrote: > > xmllint your.xml.file
It just prints my file back.
Good. That means it found no problem in that file.
What does it do when there is a problem?
If you had introduced an error and tried it, you would have had an answer in seconds :-)
The answer is - it complains.
I mean, is it obvious to see? Don't I have to go up a kilometre of print to see it up there, out of sight?
Again, if you had tried it, you would have had an answer in seconds :-)
Yeah, I produced an error and saw it, after posting.
I would expect to see just a message like "good" or "bad", a single line.
Well. Other people might expect a return code indicating failure or success. By default, xmllint prints the parsed tree. Add argument '--noout' if you don't want that.
Ah, thanks.
With all that print, I can not put it in my CLI:
Telcontar:/etc/firewalld # firewall-cmd --check-config && firewall-offline-cmd --check-config && firewall-cmd --reload && tail -n 100 /var/log/firewalld | grep `date -u +"%Y-%m-%d-%H"` success WARNING: 'NoneType' object has no attribute 'check': None WARNING: 'NoneType' object has no attribute 'check': None success Telcontar:/etc/firewalld #
The above has got nothing to do with xmllint, but it sounds like it checks against an xml schema and finds an unwanted/undefined attribute. Hmm, maybe not - there is no schema specified in that file.
The thing is, as it does not say what line is bad, I can not find it. Telcontar:/etc/firewalld # grep -ri NoneType * Telcontar:/etc/firewalld #
Telcontar:/etc/firewalld # grep -ri check * SuSEfirewall2-to-firewalld.txt:INFO: The dry-run has been completed. Please check the above output to ensure SuSEfirewall2-to-firewalld.txt:INFO: The dry-run has been completed. Please check the above output to ensure susefirewall2-to-firewalld_11.txt:INFO: The dry-run has been completed. Please check the above output to ensure Telcontar:/etc/firewalld #
# xmllint zones/external.xml
just prints the file and I can't know where is the line that produces that warning.
xmllint in the basic invocation only checks for the XML being well-formed, i.e. syntactically correct.
I guessed. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Telcontar:/etc/firewalld # firewall-cmd --check-config && firewall-offline-cmd --check-config && firewall-cmd --reload && tail -n 100 /var/log/firewalld | grep `date -u +"%Y-%m-%d-%H"` success WARNING: 'NoneType' object has no attribute 'check': None WARNING: 'NoneType' object has no attribute 'check': None success Telcontar:/etc/firewalld #
The above has got nothing to do with xmllint, but it sounds like it checks against an xml schema and finds an unwanted/undefined attribute. Hmm, maybe not - there is no schema specified in that file.
The thing is, as it does not say what line is bad, I can not find it.
An object of type "NoneType" sounds like it doesn't actually exist or at least couldn't be properly identified. -- Per Jessen, Zürich (19.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 5/2/23 13:50, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-02 13:07, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-02 08:22, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:30, Per Jessen wrote: The above has got nothing to do with xmllint, but it sounds like it checks against an xml schema and finds an unwanted/undefined attribute. Hmm, maybe not - there is no schema specified in that file.
It seems there is no XML schema for firewalld (there are some GitHub issues open about it), most one can do besides checking the overall XML validity using xmllint is using `firewall-cmd --check-config` (or `firewall-offline-cmd --check-config`, respectively).
# xmllint zones/external.xml
just prints the file and I can't know where is the line that produces that warning.
xmllint in the basic invocation only checks for the XML being well-formed, i.e. syntactically correct.
Per Jessen wrote:
Second glance - with the virtually empty config, I added a comment and "--check-config" reported "success".
I have now tried adding comments all over the place, unfolding lines etc - doing a "--check-config" reports no problems, a "--reload" works too and xmllint is happy. I even tried adding this: <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="20" protocol="tcp"/> <accept/> </rule> <!-- comment --> The above wasn't in my converted config, but it also caused no problems or complaints when I added it. I also tried adding blanks where blanks aren't always expected - again, no problems or complaints. -- Per Jessen, Zürich (16.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-02 11:53, Per Jessen wrote:
Per Jessen wrote:
Second glance - with the virtually empty config, I added a comment and "--check-config" reported "success".
I have now tried adding comments all over the place, unfolding lines etc - doing a "--check-config" reports no problems, a "--reload" works too and xmllint is happy.
I even tried adding this:
<rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="20" protocol="tcp"/> <accept/> </rule>
<!-- comment -->
The above wasn't in my converted config, but it also caused no problems or complaints when I added it. I also tried adding blanks where blanks aren't always expected - again, no problems or complaints.
Yes, I wrote yesterday several comments and they all worked fine. I don't understand why it complained before. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forgot to send this the past night. On Tuesday, 2023-04-25 at 22:58 +0200, Carlos E. R. wrote: <0.4> 2023-04-29T00:25:49.693695+02:00 Isengard kernel - - - [1211886.836452][ C0] FINAL_REJECT: IN=eth0 OUT= MAC= SRC=192.168.1.16 DST=192.168.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=23392 DF PROTO=UDP SPT=137 DPT=137 LEN=58 <0.4> 2023-04-29T00:25:51.697641+02:00 Isengard kernel - - - [1211888.843976][ C1] FINAL_REJECT: IN=eth0 OUT= MAC= SRC=192.168.1.16 DST=192.168.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=23711 DF PROTO=UDP SPT=137 DPT=137 LEN=58 <0.4> 2023-04-29T00:25:52.701737+02:00 Isengard kernel - - - [1211889.844391][ C1] FINAL_REJECT: IN=eth0 OUT= MAC= SRC=192.168.1.16 DST=192.168.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=23942 DF PROTO=UDP SPT=137 DPT=137 LEN=58 <0.4> 2023-04-29T00:25:53.701690+02:00 Isengard kernel - - - [1211890.845524][ C0] FINAL_REJECT: IN=eth0 OUT= MAC= SRC=192.168.1.16 DST=192.168.255.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=24132 DF PROTO=UDP SPT=137 DPT=137 LEN=58 <0.4> 2023-04-29T00:25:54.701642+02:00 Isengard kernel - - - [1211891.846967][ C0] FINAL_REJECT: IN=eth0 OUT= MAC= SRC=192.168.1.16 DST=192.168.255.255 LEN=211 TOS=0x00 PREC=0x00 TTL=64 ID=24241 DF PROTO=UDP SPT=138 DPT=138 LEN=191 192.168.1.16 is precissely Isengard. Port 137 is part of samba: cer@Telcontar:/usr/lib/firewalld/services> cat samba.xml <?xml version="1.0" encoding="utf-8"?> <service> <short>Samba</short> <description>This option allows you to access and participate in Windows file and printer sharing networks. You need the samba package installed for this option to be useful.</description> <port protocol="udp" port="137"/> <port protocol="udp" port="138"/> <port protocol="tcp" port="139"/> <port protocol="tcp" port="445"/> <helper name="netbios-ns"/> </service> cer@Telcontar:/usr/lib/firewalld/services> I have samba allowed: <rule family="ipv4"> <source address="192.168.0.0/16"/> <protocol value="samba"/> <accept/> </rule> I must be missing something. But I neither see "137" nor "samba" in the output of "firewall-cmd --list-all". Isengard:/etc/firewalld/zones # firewall-cmd --list-all | grep "service name" rule family="ipv4" source address="192.168.0.0/16" service name="https" accept rule family="ipv4" source address="192.168.0.0/16" service name="http" accept rule family="ipv4" source address="192.168.0.0/16" service name="nfs" accept rule family="ipv4" source address="192.168.0.0/16" service name="dns" accept rule family="ipv4" source address="192.168.0.0/16" service name="ntp" accept rule family="ipv4" source address="192.168.0.0/16" service name="ssh" accept limit value="3/m" rule family="ipv4" source address="192.168.0.0/16" service name="mountd" accept rule family="ipv4" source address="192.168.0.0/16" service name="mdns" accept rule family="ipv4" source address="192.168.0.0/16" service name="nfs3" accept rule family="ipv4" source address="192.168.0.0/16" service name="rpc-bind" accept Isengard:/etc/firewalld/zones # I must be missing something, but I am tired. Damm! It is service name, not protocol value. Wrong copy paste. But the syntax check said nothing! Claims success and fails. Isengard:/etc/firewalld/zones # firewall-cmd --check-config && firewall-cmd --reload && date --rfc-3339=ns success success 2023-04-29 00:41:48.864776026+02:00 Isengard:/etc/firewalld/zones # firewall-cmd --list-all | grep samba rule family="ipv4" source address="192.168.0.0/16" service name="samba" accept Isengard:/etc/firewalld/zones # I don't like this firewalld... - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEzqGhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVQ1cAoIAxzbBd1+YDxeFVHiGj 2FzoVpaQAJ9qgoYMUySEVUPH5JXOjeYJLc7RRQ== =Dv4f -----END PGP SIGNATURE-----
Carlos E. R. wrote:
I don't like this firewalld...
Maybe if you used it the way it was intended, via the GUI. -- Per Jessen, Zürich (20.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 12:25 +0200, Per Jessen wrote:
Carlos E. R. wrote:
I don't like this firewalld...
Maybe if you used it the way it was intended, via the GUI.
Not practical when there are this many rules. There is no search. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEz5Qhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVJQYAoJRTWJdax3NAIqzPl/pC LdlHay27AJ9hOSbtrBTCNewpVUCcOUgxPj/lDw== =XfTC -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 11:57 +0200, Carlos E. R. wrote: Thinking aloud again, maybe I find what is going on while I write. I see this entry in my firewall log, repeatedly: <0.4> 2023-04-29T12:07:15.296265+02:00 Isengard kernel - - - [1253972.924118][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=...:49:01:86:dd SRC=fd81:...:4901 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=155 TC=0 HOPLIMIT=255 FLOWLBL=503569 PROTO=UDP SPT=5353 DPT=5353 LEN=115 <0.4> 2023-04-29T11:40:31.021724+02:00 Isengard kernel - - - [1252368.627743][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=33:...:5a:bd:86:dd SRC=2a02:...:5abd DST=ff02:...:00fb LEN=105 TC=0 HOPLIMIT=255 FLOWLBL=44733 PROTO=UDP SPT=5353 DPT=5353 LEN=65 that is mdns, aka Multicast DNS (mDNS). It is open in the intranet for IPv4, but seems some machine prefers IPv6. One comes from 2a02:..., which is my prefix. The one that changes, so I can not write that in the firewall rules. cer@Isengard:~/Pictures> ip neigh 192.168.1.129 dev eth0 lladdr ...:5f STALE 192.168.2.18 dev eth0 lladdr ...:01 STALE 192.168.1.14 dev eth0 lladdr ...:bd REACHABLE 192.168.1.1 dev eth0 lladdr ...:d4 REACHABLE 192.168.1.7 dev eth0 lladdr ...:3c STALE fe80::...:5abd dev eth0 lladdr ...5a:bd STALE fe80::...:80d4 dev eth0 lladdr ...:d4 router STALE fe80::...:ced2 dev eth0 lladdr ...:49 STALE 2a02:...:298b dev eth0 lladdr ...:49 STALE 2a02:...:5abd dev eth0 lladdr ...:5a:bd STALE <=== The 5abd part matches the src. It is Telcontar, this desktop machine. Compare the long string... Yes, it is this one: inet6 2a02:...:5abd/64 scope global dynamic mngtmpaddr On the second firewall entry pasted above. The MAC matches partially the "link/ether" string as printed by "ip addr": MAC=...:a1:5a:bd:86:dd link/ether ...:a1:5a:bd brd ff:ff:ff:ff:ff:ff The other log entry <0.4> 2023-04-29T12:07:15.296265+02:00 Isengard kernel - - - [1253972.924118][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=...:49:01:86:dd SRC=fd81:...:4901 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=155 TC=0 HOPLIMIT=255 FLOWLBL=503569 PROTO=UDP SPT=5353 DPT=5353 LEN=115 That's Beta laptop. Beta:~ # ip addr | grep fd81 | grep 4901 inet6 fd81:...:4901/64 scope global mngtmpaddr noprefixroute Beta:~ # Well, it is a nighmare to find out what machine in the network has a certain IPv6 address. Because it is not only one, it is a bunch of them! And they change! In my case, both the prefix and the suffix. I do not see how to allow them in the firewall. Or silence them (just them). Would it bad, in my case, to open "mDNS" both for IPv4 and IPv6, considering the router firewall doesn't work? - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEz47xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV9p8Anj02TENJmh+NHxJHLScr RY0WNTyLAJ9gyiHpAlr/6JwEPIgSQfRTM3Cuvw== =688F -----END PGP SIGNATURE-----
Carlos E. R. wrote:
One comes from 2a02:..., which is my prefix. The one that changes, so I can not write that in the firewall rules. [snip] Well, it is a nighmare to find out what machine in the network has a certain IPv6 address. Because it is not only one, it is a bunch of them! And they change! In my case, both the prefix and the suffix.
Admittedly I don't have this issue, so I don't know how well this might work: - monitor the ipv6 lease file, in /var/lib/NetworkManager - when it changes, check the prefix and if necessary reload your firewall with the new prefix. (I'll post a better example in a minute).
I do not see how to allow them in the firewall. Or silence them (just them).
Just a rule to permit port 5353, src and dst. Or just a rule to drop port 5353, src and dst. -- Per Jessen, Zürich (17.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 29.04.2023 15:00, Per Jessen wrote:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
Prefix comes from RA, not from DHCP bor@bor-Latitude-E5450:~$ sudo cat /var/lib/NetworkManager/internal-7fdc67fc-d846-4fed-a6f5-2460f96a1708-wlp2s0.lease # This is private data. Do not parse. ADDRESS=192.168.1.6 bor@bor-Latitude-E5450:~$
Andrei Borzenkov wrote:
On 29.04.2023 15:00, Per Jessen wrote:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
Prefix comes from RA, not from DHCP
Yes, but the prefix will still be written into the lease file, e.g. office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b { starts 1682405437; renew 3600; rebind 7200; iaaddr 2a03:7520:4c68:1:ff99:ffff:0:c8f7 { starts 1682405437; preferred-life 43200; max-life 86400; } } option dhcp6.client-id 0:4:d8:8e:b2:c2:94:66:c0:ac:1a:ec:47:b0:87:70:87:53; option dhcp6.server-id 0:1:0:1:28:3e:35:d2:0:15:60:57:7:f1; option dhcp6.name-servers 2a03:7520:4c68:1::1000; } -- Per Jessen, Zürich (20.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 29.04.2023 15:48, Per Jessen wrote:
Andrei Borzenkov wrote:
On 29.04.2023 15:00, Per Jessen wrote:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
Prefix comes from RA, not from DHCP
Yes, but the prefix will still be written into the lease file,
As my example that you gratuitously trimmed shows - it does not. e.g.
office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b {
You requested IA NA from DHCPv6, of course you got back full address with prefix. But that requires using DHCPv6 for address configuration in the first place. And even if you *are* using DHCPv6 the content of lease file depends on which DHCP implementation NM is using. Which changes over time and currently preferred is internal client which does not write anything related to DHCPv6 (even though it does use it to obtain address).
starts 1682405437; renew 3600; rebind 7200; iaaddr 2a03:7520:4c68:1:ff99:ffff:0:c8f7 { starts 1682405437; preferred-life 43200; max-life 86400; } } option dhcp6.client-id 0:4:d8:8e:b2:c2:94:66:c0:ac:1a:ec:47:b0:87:70:87:53; option dhcp6.server-id 0:1:0:1:28:3e:35:d2:0:15:60:57:7:f1; option dhcp6.name-servers 2a03:7520:4c68:1::1000; }
Andrei Borzenkov wrote:
On 29.04.2023 15:48, Per Jessen wrote:
Andrei Borzenkov wrote:
On 29.04.2023 15:00, Per Jessen wrote:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
Prefix comes from RA, not from DHCP
Yes, but the prefix will still be written into the lease file,
As my example that you gratuitously trimmed shows - it does not.
Your example did not appear to be applicable to the situation at hand.
office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b {
You requested IA NA from DHCPv6, of course you got back full address with prefix. But that requires using DHCPv6 for address configuration in the first place.
Which ISTR was necessary anyway? for DNS config? - I think Carlos may also have mentioned it being used/available in the Mitrastar router. I could try stopping our dhcpv6 and see what happens.
And even if you *are* using DHCPv6 the content of lease file depends on which DHCP implementation NM is using. Which changes over time and currently preferred is internal client which does not write anything related to DHCPv6 (even though it does use it to obtain address).
Okay - if the lease file cannot be depended on, maybe it can just be used to detect the change and the actual address determined with "ip -6 -o addr show". If that doesn't work either, I would write an iptables rule to catch the RA and log a message. -- Per Jessen, Zürich (20.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 16:42 +0200, Per Jessen wrote:
Andrei Borzenkov wrote:
On 29.04.2023 15:48, Per Jessen wrote:
Andrei Borzenkov wrote:
On 29.04.2023 15:00, Per Jessen wrote:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
Prefix comes from RA, not from DHCP
Yes, but the prefix will still be written into the lease file,
As my example that you gratuitously trimmed shows - it does not.
Your example did not appear to be applicable to the situation at hand.
office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b {
You requested IA NA from DHCPv6, of course you got back full address with prefix. But that requires using DHCPv6 for address configuration in the first place.
Which ISTR was necessary anyway? for DNS config? - I think Carlos may also have mentioned it being used/available in the Mitrastar router.
I could try stopping our dhcpv6 and see what happens.
And even if you *are* using DHCPv6 the content of lease file depends on which DHCP implementation NM is using. Which changes over time and currently preferred is internal client which does not write anything related to DHCPv6 (even though it does use it to obtain address).
Okay - if the lease file cannot be depended on, maybe it can just be used to detect the change and the actual address determined with "ip -6 -o addr show".
If that doesn't work either, I would write an iptables rule to catch the RA and log a message.
This is the file I have, with some editing for privacy. It corresponds fully with the address I get on the "ip addr" command, as "scope global dynamic mngtmpaddr" <lease> <family>ipv6</family> <type>auto</type> <uuid>73ca3964-...</uuid> <state>granted</state> <acquired>1682786208</acquired> <update>0x00000004</update> <ipv6:auto> <addresses> <address> <local>2a02:9140:...:50a1/64</local> <cache-info> <preferred-lifetime>86400</preferred-lifetime> <valid-lifetime>86400</valid-lifetime> </cache-info> </address> <address> <local>fd81:8fe5:...:50a1/64</local> </address> </addresses> <dns> <server>2a02:9000::aaaa</server> <server>2a02:9000::bbbb</server> </dns> </ipv6:auto> </lease> Isengard:/var/lib/named # There is a duid file, but it is dated yr 2018. There is also a /var/lib/wicked/lease-wlan0-dhcp-ipv6.xml, quite different. It does not contain the same prefix at all. Nor any "<address>" field. Isengard:/var/lib/named # cat /var/lib/wicked/lease-wlan0-dhcp-ipv6.xml <lease> <family>ipv6</family> <type>dhcp</type> <uuid>73ca3964-...</uuid> <state>granted</state> <acquired>1681729921</acquired> <update>0x0000341e</update> <ipv6:dhcp> <client-id>00:01:...:50:a1</client-id> <server-id>00:03:...:80:d4</server-id> <server-address>fe80::...:b34c</server-address> <server-preference>0</server-preference> <dns> <server>2a02:9000::aaaa</server> <server>2a02:9000::bbbb</server> </dns> <options> <unknown-16> <code>16</code> <data>00:00:0d:...:6f:72:67</data> </unknown-16> </options> </ipv6:dhcp> </lease> Isengard:/var/lib/named # Maybe because I tell wifi to switch off. # ip addr ... 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether a0:d3:...:ff:ff altname wlp1s0 Isengard:/var/lib/named # Well, the best thing would be find out if wicked has hook scripts. There is a directory, "/etc/wicked/scripts". /etc/wicked/scripts /etc/wicked/scripts/redfish-update /usr/share/doc/packages/wicked/samples/scripts /usr/share/doc/packages/wicked/samples/scripts/config /usr/share/doc/packages/wicked/samples/scripts/config/dummy0.xml /usr/share/doc/packages/wicked/samples/scripts/config/ifcfg-dummy1 /usr/share/doc/packages/wicked/samples/scripts/systemd /usr/share/doc/packages/wicked/samples/scripts/systemd/test-post@.service I had a quick look at them (3 scripts). Can't make sense of them. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE1MXBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVSukAn2Txw7VvwQuy8i9yMSJW YhKXCvU7AJwKI6n2tvZm7ViF7njHB591GKOCtA== =pLYr -----END PGP SIGNATURE-----
Carlos E. R. wrote:
This is the file I have, with some editing for privacy. It corresponds fully with the address I get on the "ip addr" command, as "scope global dynamic mngtmpaddr"
<lease> <family>ipv6</family>
I guess that is what Andrei meant - the format changes. My NM lease files are not XML.
<ipv6:auto> <addresses> <address> <local>2a02:9140:...:50a1/64</local> <cache-info> <preferred-lifetime>86400</preferred-lifetime> <valid-lifetime>86400</valid-lifetime> </cache-info> </address> <address> <local>fd81:8fe5:...:50a1/64</local>
fd81 ? I wonder what that is.
There is a duid file, but it is dated yr 2018.
That is normal, it is generated at installation time.
There is also a /var/lib/wicked/lease-wlan0-dhcp-ipv6.xml, quite different.
Ummm, it looks very similar to what you posted above. -- Per Jessen, Zürich (19.3°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 19:07 +0200, Per Jessen wrote:
Carlos E. R. wrote:
This is the file I have, with some editing for privacy. It corresponds fully with the address I get on the "ip addr" command, as "scope global dynamic mngtmpaddr"
<lease> <family>ipv6</family>
I guess that is what Andrei meant - the format changes. My NM lease files are not XML.
<ipv6:auto> <addresses> <address> <local>2a02:9140:...:50a1/64</local> <cache-info> <preferred-lifetime>86400</preferred-lifetime> <valid-lifetime>86400</valid-lifetime> </cache-info> </address> <address> <local>fd81:8fe5:...:50a1/64</local>
fd81 ? I wonder what that is.
The ULA.
There is a duid file, but it is dated yr 2018.
That is normal, it is generated at installation time.
Ah.
There is also a /var/lib/wicked/lease-wlan0-dhcp-ipv6.xml, quite different.
Ummm, it looks very similar to what you posted above.
No address. I realized I have wifi disabled later. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE1YRBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVkE4An3PTqKSAOpqSeXrGjJFI PgywEe3mAJ4+EzYTXf8rEvrE364+O7E4U62VVA== =uXZm -----END PGP SIGNATURE-----
On 29.04.2023 17:42, Per Jessen wrote:
Andrei Borzenkov wrote:
On 29.04.2023 15:48, Per Jessen wrote:
Andrei Borzenkov wrote:
On 29.04.2023 15:00, Per Jessen wrote:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
Prefix comes from RA, not from DHCP
Yes, but the prefix will still be written into the lease file,
As my example that you gratuitously trimmed shows - it does not.
Your example did not appear to be applicable to the situation at hand.
office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b {
You requested IA NA from DHCPv6, of course you got back full address with prefix. But that requires using DHCPv6 for address configuration in the first place.
Which ISTR was necessary anyway? for DNS config?
DNS_SERVERS is just another DHCPv6 option like IA_NA, IA_TA or IA_PD. If clients asked for DNS_SERVERS, why should it get back IA_NA?
Andrei Borzenkov wrote:
On 29.04.2023 17:42, Per Jessen wrote:
Andrei Borzenkov wrote:
On 29.04.2023 15:48, Per Jessen wrote:
Andrei Borzenkov wrote:
On 29.04.2023 15:00, Per Jessen wrote:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
Prefix comes from RA, not from DHCP
Yes, but the prefix will still be written into the lease file,
As my example that you gratuitously trimmed shows - it does not.
Your example did not appear to be applicable to the situation at hand.
office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b {
You requested IA NA from DHCPv6, of course you got back full address with prefix. But that requires using DHCPv6 for address configuration in the first place.
Which ISTR was necessary anyway? for DNS config?
DNS_SERVERS is just another DHCPv6 option like IA_NA, IA_TA or IA_PD. If clients asked for DNS_SERVERS, why should it get back IA_NA?
I have no idea what a default openSUSE setup / client might ask for. Eleven years ago when I set it up, there was a reason for having DHCPv6, e.g. for dynamic DNS updates and something about the DNS config too. It is entirely possible things have improved since then, I simply don't know. Do you know? -- Per Jessen, Zürich (19.3°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 29.04.2023 20:12, Per Jessen wrote: ...
Which ISTR was necessary anyway? for DNS config?
DNS_SERVERS is just another DHCPv6 option like IA_NA, IA_TA or IA_PD. If clients asked for DNS_SERVERS, why should it get back IA_NA?
I have no idea what a default openSUSE setup / client might ask for.
Compliant client should check Managed and Other flags in RA. "Managed" means "use DHCPv6 to obtain address and everything else", "Other" means "use DHCPv6 to obtain everything else but SLAAC for address configuration". To my best knowledge both wicked and NetworkManager do it by default.
Eleven years ago when I set it up, there was a reason for having DHCPv6, e.g. for dynamic DNS updates and something about the DNS config too. It is entirely possible things have improved since then, I simply don't know. Do you know?
You may have DHCP server doing DNS updated for you or you may have each client doing DNS updates. It is entirely up to you. So you do not absolutely need DHCP server for it, but I suppose using it simplifies administration. RA has DNS options so it is up to your router to support them. NetworkManager supports them, I do not know about wicked but I would be surprised if not.
On 2023-04-29 14:00, Per Jessen wrote:
Carlos E. R. wrote:
One comes from 2a02:..., which is my prefix. The one that changes, so I can not write that in the firewall rules. [snip] Well, it is a nighmare to find out what machine in the network has a certain IPv6 address. Because it is not only one, it is a bunch of them! And they change! In my case, both the prefix and the suffix.
Admittedly I don't have this issue, so I don't know how well this might work:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
That machine is on wicked. But I meant that when there is a log entry mentioning an IPv6 address, it is a nightmare to find out what machine in the entire LAN it is. The issue would be having a file with *all* the IPv6 used in the LAN. I would have to run a cronjob and query each machine on ssh. That leaves out androids, printers, switches...
- when it changes, check the prefix and if necessary reload your firewall with the new prefix.
The packet I need to allow comes from another machine. The local lease file would not have it.
(I'll post a better example in a minute).
I do not see how to allow them in the firewall. Or silence them (just them).
Just a rule to permit port 5353, src and dst. Or just a rule to drop port 5353, src and dst.
I just wonder whether permitting port 5353 generically on IPv6 is safe (considering the router has no working firewall). It would be easier. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-29 14:00, Per Jessen wrote:
Carlos E. R. wrote:
One comes from 2a02:..., which is my prefix. The one that changes, so I can not write that in the firewall rules. [snip] Well, it is a nighmare to find out what machine in the network has a certain IPv6 address. Because it is not only one, it is a bunch of them! And they change! In my case, both the prefix and the suffix.
Admittedly I don't have this issue, so I don't know how well this might work:
- monitor the ipv6 lease file, in /var/lib/NetworkManager
That machine is on wicked.
Oh dear. See my previous posting, only 2mins ago.
- when it changes, check the prefix and if necessary reload your firewall with the new prefix.
The packet I need to allow comes from another machine. The local lease file would not have it.
It doesn't matter - you get the _prefix_, then you alter your firewall to permit any and all traffic in that prefix. -- Per Jessen, Zürich (19.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-29 15:00, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-29 14:00, Per Jessen wrote:
Carlos E. R. wrote:
The packet I need to allow comes from another machine. The local lease file would not have it.
It doesn't matter - you get the _prefix_, then you alter your firewall to permit any and all traffic in that prefix.
Ah, NOW I understand. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 29.04.2023 12:57, Carlos E. R. wrote:
Damm! It is service name, not protocol value. Wrong copy paste. But the syntax check said nothing! Claims success and fails.
syntax is correct. It also gives warning when (re-)loaded: Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept Whether it should abort completely is certainly debatable. And if you use CLI (or I assume GUI) you get clear message efi:/etc/firewalld # firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept' Error: INVALID_PROTOCOL: samba uefi:/etc/firewalld #
On 2023-04-29 13:25, Andrei Borzenkov wrote:
On 29.04.2023 12:57, Carlos E. R. wrote:
Damm! It is service name, not protocol value. Wrong copy paste. But the syntax check said nothing! Claims success and fails.
syntax is correct. It also gives warning when (re-)loaded:
Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept
Where is that warning printed? Not in the terminal where I typed the command. In the firewall log? Isengard:/etc/firewalld/zones # grep INVALID_PROTOCOL /var/log/firewall Isengard:/etc/firewalld/zones # Isengard:/etc/firewalld/zones # zgrep INVALID_PROTOCOL /var/log/firewall-2023042*xz Isengard:/etc/firewalld/zones # just noticed a different log file: Isengard:/etc/firewalld/zones # ls -ltr /var/log/firewall* ... -rw-r----- 1 root root 227636 Apr 27 23:59 /var/log/firewall-20230428.xz -rw-r----- 1 root root 4683 Apr 29 00:34 /var/log/firewalld -rw-r----- 1 root root 1977300 Apr 29 13:36 /var/log/firewall That one has the errors! 2023-04-29 00:11:52 WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="172.26.0.0/16" protocol value="samba" accept
Whether it should abort completely is certainly debatable. And if you use CLI (or I assume GUI) you get clear message
No, I just expected a message printed in the CLI, not an abort.
efi:/etc/firewalld # firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept' Error: INVALID_PROTOCOL: samba uefi:/etc/firewalld #
And loose the formatting and comments on the file. Ok, now I know that firewalld errors go to a different log file. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 29.04.2023 14:42, Carlos E. R. wrote:
On 2023-04-29 13:25, Andrei Borzenkov wrote:
On 29.04.2023 12:57, Carlos E. R. wrote:
Damm! It is service name, not protocol value. Wrong copy paste. But the syntax check said nothing! Claims success and fails.
syntax is correct. It also gives warning when (re-)loaded:
Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept
Where is that warning printed? Not in the terminal where I typed the command.
Which command? You never told us.
On 2023-04-29 13:44, Andrei Borzenkov wrote:
On 29.04.2023 14:42, Carlos E. R. wrote:
On 2023-04-29 13:25, Andrei Borzenkov wrote:
On 29.04.2023 12:57, Carlos E. R. wrote:
Damm! It is service name, not protocol value. Wrong copy paste. But the syntax check said nothing! Claims success and fails.
syntax is correct. It also gives warning when (re-)loaded:
Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept
Where is that warning printed? Not in the terminal where I typed the command.
Which command? You never told us.
No? I see it: # firewall-cmd --check-config && firewall-cmd --reload && date --rfc-3339=ns I do not post it on every mail, because it is always the same. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 29.04.2023 15:25, Carlos E. R. wrote:
On 2023-04-29 13:44, Andrei Borzenkov wrote:
On 29.04.2023 14:42, Carlos E. R. wrote:
On 2023-04-29 13:25, Andrei Borzenkov wrote:
On 29.04.2023 12:57, Carlos E. R. wrote:
Damm! It is service name, not protocol value. Wrong copy paste. But the syntax check said nothing! Claims success and fails.
syntax is correct. It also gives warning when (re-)loaded:
Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept
Where is that warning printed? Not in the terminal where I typed the command.
Which command? You never told us.
No? I see it:
# firewall-cmd --check-config && firewall-cmd --reload && date --rfc-3339=ns
I do not post it on every mail, because it is always the same.
firewall-cmd is a frontend to firewalld and just forwards request to firewalld. Real work is performed by firewalld and any diagnostic is written to its log file. The first place where one looks for logs of system service today is journal. If you also micromanaged your log files and instead of using journal are forwarding logs to a lot of different places - then you should know where they are. firewalld does not have provision to return detailed messages back as response to D-Bus request. Which really is not different from what happens with systemctl - status from systemctl only tells you whether request was successfully submitted, not whether service succeeded at the end. If you want to check configuration and see diagnostic, use firewall-offline-cmd uefi:/etc/firewalld # firewall-offline-cmd --check-config WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept uefi:/etc/firewalld # Granted, it still returns 0 even if there were warnings. If you think it should be improved, you need to submit an issue on firewalld project.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 16:36 +0300, Andrei Borzenkov wrote:
On 29.04.2023 15:25, Carlos E. R. wrote:
On 2023-04-29 13:44, Andrei Borzenkov wrote:
On 29.04.2023 14:42, Carlos E. R. wrote:
On 2023-04-29 13:25, Andrei Borzenkov wrote:
On 29.04.2023 12:57, Carlos E. R. wrote:
Damm! It is service name, not protocol value. Wrong copy paste. But the syntax check said nothing! Claims success and fails.
syntax is correct. It also gives warning when (re-)loaded:
Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept Apr 29 14:18:55 uefi firewalld[1959]: WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept
Where is that warning printed? Not in the terminal where I typed the command.
Which command? You never told us.
No? I see it:
# firewall-cmd --check-config && firewall-cmd --reload && date --rfc-3339=ns
I do not post it on every mail, because it is always the same.
firewall-cmd is a frontend to firewalld and just forwards request to firewalld. Real work is performed by firewalld and any diagnostic is written to its log file.
Ah.
The first place where one looks for logs of system service today is journal. If you also micromanaged your log files and instead of using journal are forwarding logs to a lot of different places - then you should know where they are.
I have both syslog and journal running, and yes, I customize rsyslogd log files. But as I have only worked with firewalld this week, I doubt I created /var/log/firewalld myself. Checking: Isengard:/var/lib/named # grep firewalld /etc/rsyslog.conf Isengard:/var/lib/named # Isengard:/var/lib/named # grep firewalld /etc/rsyslog.d/* Isengard:/var/lib/named # So I did not. So where is that file configured? Isengard:/var/lib/named # grep -r /var/log/firewalld /etc/firewalld/* Isengard:/var/lib/named # Isengard:/var/lib/named # grep -r log /etc/firewalld/* /etc/firewalld/firewalld.conf:# Add logging rules right before reject and drop rules in the INPUT, FORWARD /etc/firewalld/firewalld.conf.old:# Add logging rules right before reject and drop rules in the INPUT, FORWARD /etc/firewalld/zones/external.xml.202304291206: <service name="syslog"/> /etc/firewalld/zones/external.xml: <service name="syslog"/> Isengard:/var/lib/named # No... Isengard:/var/lib/named # systemctl cat firewalld.service # /usr/lib/systemd/system/firewalld.service [Unit] Description=firewalld - dynamic firewall daemon Before=network-pre.target Wants=network-pre.target After=dbus.service After=polkit.service Conflicts=iptables.service ip6tables.service ebtables.service ipset.service nftables.service Documentation=man:firewalld(1) [Service] EnvironmentFile=-/etc/sysconfig/firewalld ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS ExecReload=/bin/kill -HUP $MAINPID # supress to log debug and error output also to /var/log/messages StandardOutput=null StandardError=null Type=dbus BusName=org.fedoraproject.FirewallD1 KillMode=mixed [Install] WantedBy=multi-user.target Alias=dbus-org.fedoraproject.FirewallD1.service Isengard:/var/lib/named # No... but found a new config file. Isengard:/var/lib/named # cat /etc/sysconfig/firewalld # firewalld command line args # possible values: --debug FIREWALLD_ARGS= Isengard:/var/lib/named # Sorry, nothing found. It is not my doing. "man firewald" does mention it. So it is hardcoded, and bypasses both journal and syslog. HA! :-o --debug[=level] Set the debug level for firewalld to level. The range of the debug level is 1 (lowest level) to 10 (highest level). The debug output will be written to the firewalld log file /var/log/firewalld. (it is the only line mentioning it)
firewalld does not have provision to return detailed messages back as response to D-Bus request. Which really is not different from what happens with systemctl - status from systemctl only tells you whether request was successfully submitted, not whether service succeeded at the end.
Ok...
If you want to check configuration and see diagnostic, use firewall-offline-cmd
uefi:/etc/firewalld # firewall-offline-cmd --check-config WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept uefi:/etc/firewalld #
Granted, it still returns 0 even if there were warnings. If you think it should be improved, you need to submit an issue on firewalld project.
Nay, I'll content myself on knowing how it acts. I have too many things to cook. I was doing: # firewall-cmd --check-config && firewall-cmd --reload && tail /var/log/firewalld && date --rfc-3339=ns I'll add your sugggestion. Although the "&&" will not act if the output is always zero. Isengard:/etc/firewalld/zones # firewall-cmd --check-config && firewall-offline-cmd --check-config && firewall-cmd --reload && tail /var/log/firewalld && date --rfc-3339=ns success success 2023-04-29 00:22:42 WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept 2023-04-29 00:22:42 WARNING: INVALID_PROTOCOL: syslog: rule family="ipv4" source address="192.168.1.0/24" protocol value="syslog" accept 2023-04-29 00:22:45 WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept 2023-04-29 00:22:45 WARNING: INVALID_PROTOCOL: syslog: rule family="ipv4" source address="192.168.1.0/24" protocol value="syslog" accept 2023-04-29 00:22:47 WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept 2023-04-29 00:22:47 WARNING: INVALID_PROTOCOL: syslog: rule family="ipv4" source address="192.168.1.0/24" protocol value="syslog" accept 2023-04-29 00:31:27 WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept 2023-04-29 00:31:27 WARNING: INVALID_PROTOCOL: syslog: rule family="ipv4" source address="192.168.1.0/24" protocol value="syslog" accept 2023-04-29 00:34:37 WARNING: INVALID_PROTOCOL: samba: rule family="ipv4" source address="192.168.0.0/16" protocol value="samba" accept 2023-04-29 00:34:37 WARNING: INVALID_PROTOCOL: syslog: rule family="ipv4" source address="192.168.1.0/24" protocol value="syslog" accept 2023-04-29 19:13:44.300664051+02:00 Isengard:/etc/firewalld/zones # Those are the old errors. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE1R8Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVt7IAn3LhZEo9h4VgWAgh/00u XNmtj9mtAJ9l+qyJJUep9H55dxQF+yETd1Z0/g== =48i6 -----END PGP SIGNATURE-----
On 2023-04-29 19:20, Carlos E. R. wrote:
On Saturday, 2023-04-29 at 16:36 +0300, Andrei Borzenkov wrote:
On 29.04.2023 15:25, Carlos E. R. wrote:
On 2023-04-29 13:44, Andrei Borzenkov wrote:
...
I was doing:
# firewall-cmd --check-config && firewall-cmd --reload && tail /var/log/firewalld && date --rfc-3339=ns
I'll add your sugggestion. Although the "&&" will not act if the output is always zero.
Isengard:/etc/firewalld/zones # firewall-cmd --check-config && firewall-offline-cmd --check-config && firewall-cmd --reload && tail /var/log/firewalld && date --rfc-3339=ns success success
Modified to: # firewall-cmd --check-config && \ firewall-offline-cmd --check-config && \ firewall-cmd --reload && \ tail -n 100 /var/log/firewalld | grep `date --iso` -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2023-04-25 at 22:58 +0200, Carlos E. R. wrote: How do I interpret this one? <0.4> 2023-04-29T23:12:01.790378+02:00 Isengard kernel - - - [1293859.876603][ C3] FINAL_REJECT: IN=eth0 OUT=MAC=ff:ff:ff:ff:ff:ff:96:...:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=322 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=302 It seems to be the one remaining noise on the firewall. It is about DHCP, and a broadcast, that I know. But I don't know if I should accept, reject, drop, nor how to accept them, or silence them. Oh, another strange one. But just one packet. <0.4> 2023-04-30T01:12:25.061938+02:00 Isengard kernel - - - [1301083.230432][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:d0:...:00 SRC=192.168.1.200 DST=255.255.255.255 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=45743 DF PROTO=UDP SPT=26999 DPT=26999 LEN=104 I don't know what machine this is. Not a computer. It responds to pings. Telcontar:~ # nmap -O 192.168.1.200 Starting Nmap 7.92 ( https://nmap.org ) at 2023-04-30 03:44 CEST Nmap scan report for 192.168.1.200 Host is up (0.00016s latency). Not shown: 997 closed tcp ports (reset) PORT STATE SERVICE 53/tcp open domain 1234/tcp filtered hotline 8090/tcp open opsmessaging MAC Address: D0:FC:D0:4C:D1:6C (Unknown) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9 Network Distance: 1 hop OS detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 2.96 seconds Telcontar:~ # The router identifies it as "HUMAX_PTT1000_ES_D0FCD04CD16C -" Now "humax" is familiar... 192.168.1.200 is just the start of the "DHCP Conditional Serving Pool" range as set by the ISP. Ah, it must be the TV receiver. Confirmed, it is the TV decoder. That's a strange broadcast, strange port. I switched it off, but still responds to pings... ah, that's the fast powerup feature. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE3MdRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVMlgAoIwtNrVmoEx62u8FgJLI 7w8AmD2rAJ4j9OI7ZH0xW0r1w35VeBsMvvmr7Q== =8F3Z -----END PGP SIGNATURE-----
Carlos E. R. wrote:
How do I interpret this one?
<0.4> 2023-04-29T23:12:01.790378+02:00 Isengard kernel - - - [1293859.876603][ C3] FINAL_REJECT: IN=eth0 OUT=MAC=ff:ff:ff:ff:ff:ff:96:...:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=322 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=302
It seems to be the one remaining noise on the firewall. It is about DHCP, and a broadcast, that I know. But I don't know if I should accept, reject, drop, nor how to accept them, or silence them.
It's a dhcp client looking for a dhcp server - what to do with it is up to you, depends on your context.
Oh, another strange one. But just one packet.
<0.4> 2023-04-30T01:12:25.061938+02:00 Isengard kernel - - - [1301083.230432][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:d0:...:00 SRC=192.168.1.200 DST=255.255.255.255 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=45743 DF PROTO=UDP SPT=26999 DPT=26999 LEN=104
High ports - why even bother with looking at that?
MAC Address: D0:FC:D0:4C:D1:6C (Unknown) ^^^^^^^^
That is Humax. -- Per Jessen, Zürich (12.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 30.04.2023 09:46, Per Jessen wrote:
Carlos E. R. wrote:
How do I interpret this one?
<0.4> 2023-04-29T23:12:01.790378+02:00 Isengard kernel - - - [1293859.876603][ C3] FINAL_REJECT: IN=eth0 OUT=MAC=ff:ff:ff:ff:ff:ff:96:...:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=322 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=302
It seems to be the one remaining noise on the firewall. It is about DHCP, and a broadcast, that I know. But I don't know if I should accept, reject, drop, nor how to accept them, or silence them.
It's a dhcp client looking for a dhcp server - what to do with it is up to you, depends on your context.
And it logs MAC address which allows finding the system sending this request. https://www.net.co.at/doc/howto/docs/iptables_netfilter_howto_de/docs/netfil...
On 2023-04-30 08:46, Per Jessen wrote:
Carlos E. R. wrote:
How do I interpret this one?
<0.4> 2023-04-29T23:12:01.790378+02:00 Isengard kernel - - - [1293859.876603][ C3] FINAL_REJECT: IN=eth0 OUT=MAC=ff:ff:ff:ff:ff:ff:96:...:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=322 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=302
It seems to be the one remaining noise on the firewall. It is about DHCP, and a broadcast, that I know. But I don't know if I should accept, reject, drop, nor how to accept them, or silence them.
It's a dhcp client looking for a dhcp server - what to do with it is up to you, depends on your context.
But thinking aloud, what is best to do with them? And how? For example, if I accept them, do I add 0.0.0.0/32 or /0? Is it safe? Accepting them is less resources than writing a log entry, and less noise. Can dropping them cause an issue for this machine?
Oh, another strange one. But just one packet.
<0.4> 2023-04-30T01:12:25.061938+02:00 Isengard kernel - - - [1301083.230432][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:d0:...:00 SRC=192.168.1.200 DST=255.255.255.255 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=45743 DF PROTO=UDP SPT=26999 DPT=26999 LEN=104
High ports - why even bother with looking at that?
Because it is curious. What on earth is that? It is not part of an ongoing conversation, it is a broadcast.
MAC Address: D0:FC:D0:4C:D1:6C (Unknown) ^^^^^^^^
That is Humax.
Yes, I said so later in the post. It is the fibre TV decoder. It runs Linux and responds to pings. How do you find the maker from the MAC? Ah, there is a table somewhere, I forgot. There is <https://mac-address.alldatafeeds.com/mac-address-lookup/> And it finds it is Humax. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 08:46, Per Jessen wrote:
It's a dhcp client looking for a dhcp server - what to do with it is up to you, depends on your context.
But thinking aloud, what is best to do with them? And how?
You have to consider the context. Single machine that runs a dhcp server or not? * if you need them, they should obviously be accepted. * if you're not sure if you need then, reject but log * if you don't need then, drop.
For example, if I accept them, do I add 0.0.0.0/32 or /0? Is it safe?
You just don't specify it, you simply accept broadcast udp traffic on ports 67 and 68. It is a broadcast message, it doesn't travel further than the next router.
Accepting them is less resources than writing a log entry, and less noise.
Those are not considerations pertinent to firewalling, not even on a 486dx2.
Can dropping them cause an issue for this machine?
I would ask the admin. :-)
Oh, another strange one. But just one packet.
<0.4> 2023-04-30T01:12:25.061938+02:00 Isengard kernel - - - [1301083.230432][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:d0:...:00 SRC=192.168.1.200 DST=255.255.255.255 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=45743 DF PROTO=UDP SPT=26999 DPT=26999 LEN=104
High ports - why even bother with looking at that?
Because it is curious. What on earth is that? It is not part of an ongoing conversation, it is a broadcast.
It's probably just "Tinder for Humax".
MAC Address: D0:FC:D0:4C:D1:6C (Unknown) ^^^^^^^^ That is Humax.
Yes, I said so later in the post.
I was only showing you that the MAC OUI will tell you.
How do you find the maker from the MAC?
You take the OUI - the first 3 octets - and do a look up: IEEE OUI - https://standards-oui.ieee.org/ (or use wireshark). ISTR being able to do a lookup in KDE, Alt-F2 and then <something>OUI - similar to "#manpage". Maybe I am imagining things. -- Per Jessen, Zürich (14.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 11:42, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 08:46, Per Jessen wrote:
It's a dhcp client looking for a dhcp server - what to do with it is up to you, depends on your context.
But thinking aloud, what is best to do with them? And how?
You have to consider the context. Single machine that runs a dhcp server or not?
Only the router should manage dhcp. But in the past I found that I had to open dhcp port on some clients for dhcp assignment to work.
* if you need them, they should obviously be accepted.
I don't know if I need them.
* if you're not sure if you need then, reject but log
It's a lot of noise.
* if you don't need then, drop.
I don't know if I need them, that's the question.
For example, if I accept them, do I add 0.0.0.0/32 or /0? Is it safe?
You just don't specify it, you simply accept broadcast udp traffic on ports 67 and 68. It is a broadcast message, it doesn't travel further than the next router.
I did <rule family="ipv4"> <source address="0.0.0.0/32"/> <service name="dhcp"/> <accept/> </rule> a while ago, and now the log is empty, which is what I wanted.
Accepting them is less resources than writing a log entry, and less noise.
Those are not considerations pertinent to firewalling, not even on a 486dx2.
:-D it is to me :-) (resources are also disk space. I want logs only with important things, entries use *my* time.)
Can dropping them cause an issue for this machine?
I would ask the admin. :-)
The admin doesn't know.
Oh, another strange one. But just one packet.
<0.4> 2023-04-30T01:12:25.061938+02:00 Isengard kernel - - - [1301083.230432][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:d0:...:00 SRC=192.168.1.200 DST=255.255.255.255 LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=45743 DF PROTO=UDP SPT=26999 DPT=26999 LEN=104
High ports - why even bother with looking at that?
Because it is curious. What on earth is that? It is not part of an ongoing conversation, it is a broadcast.
It's probably just "Tinder for Humax".
MAC Address: D0:FC:D0:4C:D1:6C (Unknown) ^^^^^^^^ That is Humax.
Yes, I said so later in the post.
I was only showing you that the MAC OUI will tell you.
I had forgotten.
How do you find the maker from the MAC?
You take the OUI - the first 3 octets - and do a look up: IEEE OUI - https://standards-oui.ieee.org/
You didn't notice I found them myself, but different site. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 11:42, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 08:46, Per Jessen wrote:
It's a dhcp client looking for a dhcp server - what to do with it is up to you, depends on your context.
But thinking aloud, what is best to do with them? And how?
You have to consider the context. Single machine that runs a dhcp server or not?
Only the router should manage dhcp.
So, can we conclude that this machine does _not_ run a dhcp server? If so, you have to ask why it should be interested in dhcp client broadcasts.
But in the past I found that I had to open dhcp port on some clients for dhcp assignment to work.
Yep, I would expect that to be true.
* if you need them, they should obviously be accepted.
I don't know if I need them.
In that case, you just drop them and wait for something to break.
* if you're not sure if you need then, reject but log
It's a lot of noise.
Is that a problem?
(resources are also disk space. I want logs only with important things, entries use *my* time.)
That makes sense, disk space is growing more and more expensive every day. The other day I saw Sfr14/Tb, that's outrageous.
Can dropping them cause an issue for this machine?
I would ask the admin. :-)
The admin doesn't know.
systemctl polish crystalball -- Per Jessen, Zürich (16.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 12:18, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 11:42, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 08:46, Per Jessen wrote:
It's a dhcp client looking for a dhcp server - what to do with it is up to you, depends on your context.
But thinking aloud, what is best to do with them? And how?
You have to consider the context. Single machine that runs a dhcp server or not?
Only the router should manage dhcp.
So, can we conclude that this machine does _not_ run a dhcp server? If so, you have to ask why it should be interested in dhcp client broadcasts.
It wouldn't. I wasn't sure they were dhcp client broadcasts, though.
But in the past I found that I had to open dhcp port on some clients for dhcp assignment to work.
Yep, I would expect that to be true.
* if you need them, they should obviously be accepted.
I don't know if I need them.
In that case, you just drop them and wait for something to break.
Right.
* if you're not sure if you need then, reject but log
It's a lot of noise.
Is that a problem?
For me, yes! I don't like noise in the logs. Hate it, actually.
(resources are also disk space. I want logs only with important things, entries use *my* time.)
That makes sense, disk space is growing more and more expensive every day. The other day I saw Sfr14/Tb, that's outrageous.
:-DD You forget that each entry causes a sector write in an SSD, which has a limited life. >:-P And if it were rotating rust, it impedes the disk going to sleep ;-p
Can dropping them cause an issue for this machine?
I would ask the admin. :-)
The admin doesn't know.
systemctl polish crystalball
Ok. I'll try drop instead of accept. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
I wasn't sure they were dhcp client broadcasts, though.
Okay. At least that answered in my first reply in the thread.
* if you're not sure if you need then, reject but log
It's a lot of noise.
Is that a problem?
For me, yes! I don't like noise in the logs. Hate it, actually.
Stop logging stuff :-) That is perhaps a matter of personal attitude - when I (in code or in a firewall chain) end up in a situation I hadn't anticipated, I want to know about it. Repetitive lines can be suppressed by your syslog daemon. All of my firewall scripts finish with these lines: ## log all traffic that comes this way $IPTABLES -A INPUT -p all -j LOG --log-level debug --log-prefix 'input: ' $IPTABLES -A FORWARD -p all -j LOG --log-level debug --log-prefix 'forward: ' ## Drop anything that is not explicitly allowed. $IPTABLES -A INPUT -p all -j DROP $IPTABLES -A FORWARD -p all -j DROP -- Per Jessen, Zürich (15.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 14:04, Per Jessen wrote:
Carlos E. R. wrote:
I wasn't sure they were dhcp client broadcasts, though.
Okay. At least that answered in my first reply in the thread.
* if you're not sure if you need then, reject but log
It's a lot of noise.
Is that a problem?
For me, yes! I don't like noise in the logs. Hate it, actually.
Stop logging stuff :-)
Nonono. I want to see the issues. If there is noise, the issues do not stand out.
That is perhaps a matter of personal attitude - when I (in code or in a firewall chain) end up in a situation I hadn't anticipated, I want to know about it. Repetitive lines can be suppressed by your syslog daemon.
All of my firewall scripts finish with these lines:
## log all traffic that comes this way $IPTABLES -A INPUT -p all -j LOG --log-level debug --log-prefix 'input: ' $IPTABLES -A FORWARD -p all -j LOG --log-level debug --log-prefix 'forward: '
## Drop anything that is not explicitly allowed. $IPTABLES -A INPUT -p all -j DROP $IPTABLES -A FORWARD -p all -j DROP
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 14:04, Per Jessen wrote:
Carlos E. R. wrote:
I wasn't sure they were dhcp client broadcasts, though.
Okay. At least that answered in my first reply in the thread.
* if you're not sure if you need then, reject but log
It's a lot of noise.
Is that a problem?
For me, yes! I don't like noise in the logs. Hate it, actually.
Stop logging stuff :-)
Nonono. I want to see the issues. If there is noise, the issues do not stand out.
Well, when the admin does not know whether some packet should be allowed or not, that is an issue. -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
participants (12)
-
Andrei Borzenkov -
Bengt Gördén -
Bill Walsh -
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
Freek de Kruijf -
Georg Pfuetzenreuter -
kschneider bout-tyme.net -
Lew Wolfgang -
Patrick Shanahan -
Per Jessen