Each opened (listening) socket in the system is a potential vulnerability. I may be wrong but as I understand that binding to an address is almost the same as binding to an interface. Maybe I am wrong, again. And it is meaning that an appropriate opened socket will receive packers only from the corresponding interface, of course if IP forwarding, source nat and so on is not set up.
So, it can be checked practically. Is it true or false. When you will add such functionality, I will build a new version of chrony and will turn off nat, ip forwarding and will launch tcpdump and will see what happens on the lan interface when some client from dmz sends a request to dmz interface. That is, will any packets come to the lan interface or not. ср, 30 авг. 2023 г. в 13:29, Miroslav Lichvar <mlich...@redhat.com>: > On Wed, Aug 30, 2023 at 12:49:34PM +0300, CpServiceSPb wrote: > > > Why is it not good? Is it meant to be a security measure? Would > firewall > > not work better? > > There are sockets in a system. > > Sometimes a firewall can pass packets due to its malfunction or not > > accurate settings. > > If there are no extra sockets it is much much better for security. > > Can you please elaborate? The security benefits are not very clear to > me. > > There are some misconceptions. Binding a socket to an address doesn't > mean it will not receive packets from other interfaces. For example, > if eth1 has ADDR1 and eth2 has ADDR2, and chronyd is configured to > listen only on ADDR1, I think on a typical system it will respond to > requests send to ADDR1 no matter if they are received from eth1 or > eth2. > > There are exceptions to this like the loopback range (127.0.0.0/8) > which the kernel should drop as "martian packets" if received from > real network interfaces, so default bindcmdaddress of 127.0.0.1 should > prevent responding to requests from network. > > -- > Miroslav Lichvar > > > -- > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
