View previous topic :: View next topic |
Author |
Message |
grant123 Veteran
Joined: 23 Mar 2005 Posts: 1080
|
Posted: Mon Oct 24, 2022 11:47 am Post subject: Avoid shorewall dhcp option? |
|
|
The 'dhcp' option is called for in the shorewall interfaces file if the interface gets its IP address via DHCP or if the interface is used by a DHCP server running on the firewall:
https://shorewall.org/manpages/shorewall-interfaces.html
I'm thinking this must punch a hole in the firewall for inbound connections to that interface for UDP ports 67 and 68. This is especially undesirable on the WAN interface, and DHCP seems to work fine without using the 'dhcp' option there. Am I thinking about this correctly and should the 'dhcp' option be avoided on the WAN interface? |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 4124 Location: Bavaria
|
Posted: Mon Oct 24, 2022 3:02 pm Post subject: |
|
|
I dont know which application you use for DHCP - I can speak only for "dhcpcd":
This is a very "nice" application. It doesnt care about your firewall-rules ... it has the capability to change (= add) your rules and indeed it does it and opens needed ports for itself ... I observed this behaviour when I did my work for AppArmor.
The following I have done today to proof if it has changed or if it works as I observed before some years (with a stable AMD64 system):
Code: | /etc/MY # ./fwclose.sh
/etc/MY # iptables -L -vn
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
/etc/MY #
/etc/MY # /etc/init.d/net.enp5s0 stop
net.enp5s0 | * Bringing down interface enp5s0
/etc/MY # ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Lokale Schleife)
RX packets 4 bytes 438 (438.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4 bytes 438 (438.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
/etc/MY # /etc/init.d/dhcpcd start
dhcpcd | * Starting DHCP Client Daemon ... [ ok ]
/etc/MY # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 1c:1b:0d:93:46:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.2.100/24 brd 192.168.2.255 scope global dynamic noprefixroute enp5s0
valid_lft 1814393sec preferred_lft 1587593sec
/etc/MY # iptables -L -vn
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination |
.
So, yes your shorewall option maybe is not necessaey in every case ... dont ask me why I dont like DHCP and use only static addresses ...
P.S.: content of my fwclose.sh:
Code: | #!/bin/sh
set -eu
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP |
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54214 Location: 56N 3W
|
Posted: Mon Oct 24, 2022 3:24 pm Post subject: |
|
|
grant123,
I set dhcp here
Code: | # grep -i dhcp -R /etc/shorewall
/etc/shorewall/interfaces:blue blue dhcp,logmartians=1,nosmurfs
/etc/shorewall/interfaces:green green dhcp,logmartians=1,nosmurfs,routeback
/etc/shorewall/interfaces:#modem eth2 dhcp,logmartians=1,nosmurfs |
and I run dhcpd on those two interfaces too. Comparing the blue-fw rules, which has a dhcp service
shorewall show blue-fw: | Shorewall 5.2.8 Chain blue-fw at pi_router - Mon Oct 24 15:08:50 -00 2022
Counters reset Sat Oct 15 11:18:29 -00 2022
Chain blue-fw (1 references)
pkts bytes target prot opt in out source destination
1301 371K dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
1301 371K smurfs all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
1118 360K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:67:68
0 0 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0
6 288 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4886
201 16920 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type ANYCAST
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type MULTICAST
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: up to 1/sec burst 10 mode srcip LOG flags 0 level 6 prefix "Shore4:blue-fw:REJECT:"
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] |
with shorewall show dmz-fw: |
Shorewall 5.2.8 Chain dmz-fw at pi_router - Mon Oct 24 15:12:50 -00 2022
Counters reset Sat Oct 15 11:18:29 -00 2022
Chain dmz-fw (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
0 0 smurfs all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
0 0 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type ANYCAST
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type MULTICAST
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: up to 1/sec burst 10 mode srcip LOG flags 0 level 6 prefix "Shore4:dmz-fw:REJECT:"
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] |
Which does not, make it appear that if dhcp is set you get a free
Code: | ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:67:68 | rule..
You can either put the required rule(s) in your rules file or set the option in interfaces.
The firewall has to accept dhcp requests one way or another, if its running the dhcpd server.
-- edit --
I suspect that the dhcp option on the WAN interface allows dhcp requests out, not in, so its the same term used in both places.
My IPv4 is static, so I don't use dhcp on my WAN interface.
Requests need to be allowed out. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
grant123 Veteran
Joined: 23 Mar 2005 Posts: 1080
|
Posted: Wed Oct 26, 2022 1:27 pm Post subject: |
|
|
Doesn't that negate the point of running a firewall at all? I thought the idea was that you configure your services appropriately but (just in case) you also run a firewall as a barrier. If your services can punch holes in your firewall then what good is the firewall? I didn't think we had to trust our services to respect our firewall and the fact that we do seems more like a firewall/OS problem than a dhcpcd problem. Maybe I'm missing something?
For example the Gentoo Home Router guide says:
Quote: | Setting the interface is very important. Using default dnsmasq settings will open the router to DNS amplification attacks which could create some scary email from the ISP providing the connection. |
https://wiki.gentoo.org/wiki/Home_router
So if you forget to set the interface in dnsmasq.conf it will listen on all interfaces including the WAN interface. If dnsmasq is like dhcpcd then it will punch a hole in your firewall in accordance with its misconfiguration and expose you to the above attack. I thought the point of a firewall was to protect you from this type of misconfiguration or errant service and if it can't do that then I don't see the point. |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 4124 Location: Bavaria
|
Posted: Wed Oct 26, 2022 1:49 pm Post subject: |
|
|
grant123,
you are right with your idea of using a firewall as barrier. And, this is true for incoming traffic (and also for forwarding traffic). Unfortunately this is not true for outgoing traffic ... IF an application (with root permission) acts in/on your FW station. If you can change kernel settings being "root", every application can do the same. YES, it SHOULD NOT do it and respect the settings made by a human ...
Please let me add a word about outgoing traffic: Be aware that your firewall can only warn you (with log-entries) and NOT protect you against evil applications. Why ?
Have you allowed outgoing https to EVERY station in the internet ? Yes ? Then every application can use this open port also. This is the reason why I always recommend using a web proxy (can also only warn you with logging). Be aware every open port to unspecified destinations (like allowing an outgoing ping to everyone) can be used for this. And more bad: An application can even use this for establishing direct connections - even behind a NAT. See more here: https://en.wikipedia.org/wiki/TCP_hole_punching |
|
Back to top |
|
|
grant123 Veteran
Joined: 23 Mar 2005 Posts: 1080
|
Posted: Thu Oct 27, 2022 1:08 pm Post subject: |
|
|
Quote: | you are right with your idea of using a firewall as barrier. And, this is true for incoming traffic (and also for forwarding traffic). Unfortunately this is not true for outgoing traffic |
Aren't we talking about dhcpcd opening ports for *incoming* DHCP requests? |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 4124 Location: Bavaria
|
Posted: Thu Oct 27, 2022 2:01 pm Post subject: |
|
|
grant123 wrote: | Aren't we talking about dhcpcd opening ports for *incoming* DHCP requests? |
No ... dhcpcd is a client ... server is dhcpd ... if some of my remarks had led to a misunderstanding I am very sorry for this |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54214 Location: 56N 3W
|
Posted: Thu Oct 27, 2022 4:18 pm Post subject: |
|
|
grant123,
Set it and look at the rules with
Your WAN interface needs to allow dhcpcd requests out to talk to the ISPs dhcpd server.
Your LAN interfaces need to allow dhcpcd client requests from your clients to reach your dhcpd server running on the firewall.
If your dhcpd (server) is not runnig on the firewall, the firewall will not need to allow dhcpcd in from the LAN.
Rather like The Siphonaptera wrote: | Great fleas have little fleas upon their backs to bite 'em,
And little fleas have lesser fleas, and so ad infinitum.
And the great fleas themselves, in turn, have greater fleas to go on;
While these again have greater still, and greater still, and so on. |
You could run a firewall on your LAN that had its own further LANs and so on. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
grant123 Veteran
Joined: 23 Mar 2005 Posts: 1080
|
Posted: Fri Oct 28, 2022 8:45 pm Post subject: |
|
|
Now I see the benefit of running the firewall and router on separate hardware.
Let me see if I have this straight. A service can punch holes in the firewall for outgoing connections but not for incoming connections? If so I believe my concerns above about the DNS amplification attack scenario are unfounded. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54214 Location: 56N 3W
|
Posted: Fri Oct 28, 2022 9:14 pm Post subject: |
|
|
grant123,
I would be really upset if things fiddled with my firewall settings.
I've not seen that.
If I look at my rules, (shorewall show) they are what I've set.
When things don't work, its often because my firewall does not allow things out that I need. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Fri Oct 28, 2022 9:52 pm Post subject: |
|
|
I suggest being more precise about "punching holes." A firewall can allow or deny inbound or outbound independently. It is common practice to have a rule that if an outbound packet was allowed, then the firewall will heuristically identify the incoming response packet and allow that. This greatly simplifies use of client applications, by not requiring the administrator to define specific rules for every incoming response. It can also be more secure when the administrator wants those responses in, since the heuristic can match the inbound packets based on the outbound characteristics, rather than needing a broad rule such as "Allow all incoming traffic where the peer's port is 443." Such a broad rule could trivially allow in unwanted and unsolicited probe attempts.
This heuristic to automatically recognize incoming traffic is built on the local recipient having previously and recently sent traffic to the peer that is now sending to the firewall. Thus, by definition it cannot automatically allow incoming unsolicited traffic. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54214 Location: 56N 3W
|
Posted: Sat Oct 29, 2022 10:03 am Post subject: |
|
|
Hu,
That's shorewalls default behavior. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
spica Apprentice
Joined: 04 Jun 2021 Posts: 285
|
Posted: Thu Nov 03, 2022 7:16 pm Post subject: |
|
|
I found an interesting reading raw sockets, iptables and the fact that which looks like suitable for this topic and it can contain a possible explanation why the router still obtains IP address with the option turned off if it does not use ebtables. |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 4124 Location: Bavaria
|
Posted: Sat Nov 05, 2022 9:24 am Post subject: |
|
|
spica wrote: | I found an interesting reading raw sockets, iptables and the fact that which looks like suitable for this topic and it can contain a possible explanation why the router still obtains IP address with the option turned off if it does not use ebtables. |
This is very interesting. Thanks a lot for this link ! |
|
Back to top |
|
|
|