Version: (using KDE KDE 3.0.99) Installed from: Compiled From Sources OS: Linux By default ksysguardd binds to all interfaces and I found no way to change this behaviour. Combined with the fact, that you recommend in the help-files to copy the small programm to other machines, I would consider this at least as bad practice. A lot of people will run it this way on their routers/firewall -- and will be open to attacks... I would prefer the following: 1) bind to loopback by default 2) supply a documented command-line switch "-i" , to add additional interfaces Although I put this on the wishlist, I would recommend to think about including this wish into 3.1 release - it's a security issue and you are not absolutely sure, that there are no possible abuses for ksysguardd, are you ? bye, ju
Subject: Re: New: ksysguardd binds sto *all* interfaces On Sun, Dec 22, 2002 at 01:42:23PM -0000, ju@ct.heise.de wrote: > Version: (using KDE KDE 3.0.99) > Installed from: Compiled From Sources > OS: Linux Hi Ju, > By default ksysguardd binds to all interfaces and I found no way to change > this behaviour. Combined with the fact, that you recommend in the help-files > to copy the small programm to other machines, I would consider this at least > as bad practice. A lot of people will run it this way on their > routers/firewall -- and will be open to attacks... In security critical environments you shouldn't run ksysguardd in daemon mode at all, because the data exchange is unencrypted. Instead you should login via ssh to the certain server and start the executable there. > I would prefer the following: > > 1) bind to loopback by default > 2) supply a documented command-line switch "-i" , to add additional interfaces Will take a look at it, but can't promise anything > Although I put this on the wishlist, I would recommend to think about > including this wish into 3.1 release > - it's a security issue and you are not absolutely sure, that there are > no possible abuses for ksysguardd, are you? No, but this is another question ;) Ciao, Tobias
Subject: Re: ksysguardd binds sto *all* interfaces Tobias KXnig wrote: >>By default ksysguardd binds to all interfaces and I found no way to change >>this behaviour. Combined with the fact, that you recommend in the help-files >>to copy the small programm to other machines, I would consider this at least >>as bad practice. A lot of people will run it this way on their >>routers/firewall -- and will be open to attacks... > > In security critical environments you shouldn't run ksysguardd in daemon > mode at all, because the data exchange is unencrypted. Instead you > should login via ssh to the certain server and start the executable > there. I do not see a security risk in running ksysguardd on my router to monitor it -- as long as it only talking to the trustworthy LAN interface. No problem with unencrypted traffic here... (BTW: In manual mode, I cannot use ksysguard to monitor the system, do I ?) > Will take a look at it, but can't promise anything Fine :-) bye, ju
Subject: Re: ksysguardd binds sto *all* interfaces On Sun, Dec 22, 2002 at 08:26:58PM -0000, ju@ct.heise.de wrote: > Tobias KXnig wrote: Hi Ju, > > In security critical environments you shouldn't run ksysguardd in daemon > > mode at all, because the data exchange is unencrypted. Instead you > > should login via ssh to the certain server and start the executable > > there. > > I do not see a security risk in running ksysguardd on my router to > monitor it -- as long as it only talking to the trustworthy LAN > interface. No problem with unencrypted traffic here... > > (BTW: In manual mode, I cannot use ksysguard to monitor the system, do I ?) I don't know what you mean with manual mode, but you can run ksysguardd and type in 'monitors' to get listed all available monitors. If you type in one of this monitors, ksysguardd returns the according value. Ciao, Tobias
Subject: Re: ksysguardd binds sto *all* interfaces > I don't know what you mean with manual mode, but you can run ksysguardd > and type in 'monitors' to get listed all available monitors. If you type > in one of this monitors, ksysguardd returns the according value. I am talking about the GUI frontend "ksysguard" that is running on my desktop. I'd like to monitor my Router there -- and right now, there is no way to do this, because ksysguardd ist too communicative ;-) Asking ksysguardd "by hand" is not really helpful (I can run the according system command like df, ifconfig) bye, ju
Subject: Re: ksysguardd binds sto *all* interfaces On Sun, Dec 22, 2002 at 08:26:58PM -0000, ju@ct.heise.de wrote: Hi J
Subject: Re: ksysguardd binds sto *all* interfaces Hi Tobias, > Why don't you simply add a rule like > > ipchains -A input -i ppp0 -d $LOCAL_IP 3112 -j REJECT > to the firewall on your router to deny access to ksysguard from outside? I did -- because I realized what happened. But how many people will not... Just imagine, what will happen, if any distribution starts ksysguardd by default without this ipchains rules - there will be thousands of open machines out there. Perhaps it would be worthwhile already, to do a port scan on port 3112 in one of the big dialin nets ;-) > IMHO it's not the task of ksysguard to manage network access, but the > task of a firewall. Nope - a packet filter is just *one* part of a firewall. The firewall is the whole system. And the most important line of defense is not to run anything that might compromise security - at least not on the public interface. You are not starting wu-ftpd or sendmail and then block them with ipchains rules. If you do not need them, you shut them down. If you do not need a daemon on the external interface, you restrict it on the internal -- that ist the right thing to do ... It is contra productive and against all rules of secure architecture, to poke holes first and to close them afterwards. (If you do not believe me, ask any security expert...) BTW: It should be fairly easy, to clone the necessary code from any well behaving daemon like apache, sshd, ... In my opinion, it would be worth the effort - but it's up to you ... bye, juergen
Created attachment 1111 [details] patch that implements -i option and binds to loopback by default
Please consider the attached patch for inclusion. It implements binding to the loopback by default and adds the -i switch to bind to all interfaces.
Hi J