Hi. Any new information regarding adding functionality specified by the topic ?
чт, 31 авг. 2023 г. в 00:06, CpServiceSPb <cpservice...@gmail.com>: > 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. >> >>
