The two FW default rules (I think so) - port forwarding are the same. I’m a little confused and do not understand the dependencies of two identical rules and enable the port to the WAN IP. Is there any explanation?
… Data collection:
Telnet (23/TCP)
Telnet-alternative port (2323/TCP)
Http (80/TCP)
Squid HTTP proxy (3128/TCP)
Polipo proxy HTTP (8123/TCP)
HTTP proxy (8080/TCP)
…
Any from reference port from the Data collection is not open in firewall !
Here is a comparison of (horní = UP, dolní or spodní = down) rules … ON - OFF
I do not know why you have two rules which are the same (excluding name -D / -H).
But I suppose at least one of them is created randomly by clicking to Add (or Add and edit) buttons on page Network → Firewall → Traffic rules in sections Open ports on router or New forward rule.
Unwanted randomly created firewall rules
You can try it. The “empty” rule is added by one click only. The content of rule is exactly same as you have. Here is screenshot of my firewall rules after i click to both Add / Add and edit buttons followed by Back to overview button. I did not make any change or setting of rule details. I pressed Add and Back, nothing else.
Other users can tell us if they have similar strange rules too.
My first rule (and your both) is dangerous, because it allows access to LAN nodes (PC’s, phones…) from WAN, i.e. Internet.
My second rule makes accessible the honeypot ports (and other ports which are listening on my router). But I am not sure the rule should be active in normal circumstances.
I think that rules are default (I’m not giving my life:-).) The original name of the two was just a dash … “-” and not -H -D.
If this absurd rules are banning - 23 port is open!
Means that these rules are dangerous, but I don’t understand why I have specifically prohibit a one of all single port … port 23. It’s not logical - is this a bug in default firewall rules.
Below are the default firewall rules and there are no rules with just a dash.
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fe80::/10'
option src_port '547'
option dest_ip 'fe80::/10'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
I have the same opinion as WHITE. These rules are not default. They were created accidentally (including the “dash” name ‘-’ ). It is very easy to create new “empty” rule of this type. Just one click to Add. Try it. No saving and no applying is needed.
I mean this unwanted feature is dangerous bug in SW. New rule must be created in three steps.
Click to Add button to open the page containing a form.
Fill the form, set addresses and ports, set the Rule is enabled using Enable/Disable button on top.
Confirm new rule by Save and apply button.
iT IS COMPLETELY WRONG if the rule is created WITHOUT CONFIRMATION, without step 3.
We should inform Turris developer about this problem.
And the effect of this smear on the status port 23 … open-closed ?
My 23 is open and a can`t find rule which allowed the opening of 23. If the port is open , is not monitored in “Data collection”, although it is monitoring 23 enabled.
If you are not sure, you can disable rules without deleting them. A result is the same. Rules stop working, but they can be re-activated in future in case you decide to test it again.
By the way I have sent an email to Turris technical support. I described the problem concerning unwanted firewall rules.
The default configuration seems unnecessarily open to the wan. Is there Omnia-specific doc/advice on which rules we should include in our config to maintain strong security? To pick just one of the default rules, DCHP renewal from wan is very undesirable IMO. Should we disable default rules (like DHCP renewal from wan zone), or leave them enabled but set to Drop rather than Accept?
They are for allowing IPSec traffic. In other words to allow VPN connection to go through Omnia. If you don’t use IPSec VPN in any of your devices in LAN or wireless network then you can disable those at your discretion.
In many Internet connections ISP is assigning IP addresses dynamically via DHCP to either your computers or to your router like Omnia, thus the rules for allowing DHCP and DHCPv6 from WAN zone to Omnia. In case you have static IP addresses (IPv4 and possibly IPv6) from ISP for your Omnia’s WAN interface you can disable that rule.
Hi @white, I realized from your reply that my experience is with defining rules for packet filtering firewalls like Shorewall must not directly apply to packet inspection. Will read further about packet inspection firewalls.
That is not a correct process description for DHCP. If the lease expires then DHCP starts a full discovery and not a renewal process. The renewal process in DHCP is for improving DHCP’s reliability and thus starts well in advance before the lease expires. There is a greater chance for short blackouts in your WAN connections if you let the lease expire.
I also did some digging. There is a reason that the rule is not needed in all DHCP cases. Omnia uses udhcpc and it uses a PF_PACKET socket to implement some phases of its DHCP communication. Packets going through that socket don’t go through the firewall in Omnia. Thus those packets cannot be filtered by the firewall. But in phases where udhcpc uses normal PF_INET sockets it might need that rule for DHCP to work properly.
You can try to check if you need that firewall rule in your environment by running command “iptables -vL | grep Allow-DHCP-Renew”. If you get two zeros at the start of the line when Omnia has been running a few days without reboots or any firewall changes then it means that the rule has not been used in that time frame and might be redundant in your case.
Hi @white, in my case, the router speaks to a pair of firewall machines. Those firewalls manage the dual wan connections. So looks like not an issue for me.
I just noticed that Omnia restarts the firewall every time it successfully renews DHCP lease. The firewall restart unfortunately clears the counters so this check doesn’t work as it should.
One way to try get around this would be edit /lib/netifd/dhcp.script to run iptables -vL to a temporary file at top of the script. And then checking the temporary file. If you edit /lib/netifd/dhcp.script you may want to do a system snapshot before it so you can rollback if you made a mistake.
