I propose that a system/application (which I've chosen to call Critical Defense Daemon) be developed and integrated into Pfc.
Such a system have the following properties: - be installed by default, but could be disabled during Anaconda installer - kick into action as soon as the presence of Internet connectivity is detected - reference a central server (group of servers) sending it's distro version - accept of packages vulnerable to attack over the Internet - check this list against installed package list - request iptable rules to block such an attack(s) if any installed packages are vulnerable - alert the user that said rules were about to be entered into their firewall, giving the user an opportunity to Cancel - implement said rules - if rule implementation failed alert user of failure and give user option to block all packets except packets outgoing to port 80 - forward user to a detailed or simplified advisory online which would, among other things give instructions on how to prevent attack, etc. - would reverse rules once package version has been upgrade to a non affected version, or user requests that rules be reversed - check for update advisories at user defined intervals for users permanently connected to the Internet, and for dial up users do check on Internet connection
The reason I propose such a system is because over the past up I've installed a few fresh installs of Windows, and without service packs installed from cdrom, the machines last approx 20 mins on the net before they are bogged down my malaware. Such a system would serve as a simple preemptive move that would protect a Linux desktop from such problems now, and in the future.
Just an idea Arturo
On Tue, 21 Sep 2004 19:15:52 -0400, DALive Editor dalive@flashmail.com wrote:
Such a system have the following properties: - be installed by default, but could be disabled during Anaconda installer - kick into action as soon as the presence of Internet connectivity is detected - reference a central server (group of servers) sending it's distro version - accept of packages vulnerable to attack over the Internet - check this list against installed package list - request iptable rules to block such an attack(s) if any installed packages are vulnerable
OR we could just have very secure default configurations where no outside accessible services are turned on by default AND a default firewall that blocks all incoming service requests. Which is very close to what we have right now. Doing a default install of fedora core.. using the default firewall settings...and default configuration choices what services are exposed? What you describe makes sense in a windows world where incoming services are enabled by default..but it seems a huge waste of effort to me to implement this for fedora, when reasonably secure default configuration is used that limits the exposure to malicious attack by default. http://www.advogato.org/person/mjcox/diary.html?start=126 http://blogs.redhat.com/people/archive/000133.html
- alert the user that said rules were about to be entered into theirfirewall, giving the user an opportunity to Cancel - implement said rules - if rule implementation failed alert user of failure and give user option to block all packets except packets outgoing to port 80 - forward user to a detailed or simplified advisory online which would, among other things give instructions on how to prevent attack, etc. - would reverse rules once package version has been upgrade to a non affected version, or user requests that rules be reversed
This complicated scheme sounds fragile and prone to its own vulnerabilities. Imagine if someone was able to spoof a dns server response and point you to the wrong list of packages..and that list encouraged you to create iptables rules that users dont understand how to review... sounds like a recipe for a problem to me.
- check for update advisories at user defined intervals for userspermanently connected to the Internet, and for dial up users do check on Internet connection
Well rhn-applet checks for updates...or it should. And when connected to rhn up2date is able to give advisory text as well. I will agree with you that finding a way to get update advisory text into the ui again for fedora core updates is something worth doing.
The reason I propose such a system is because over the past up I've installed a few fresh installs of Windows, and without service packs installed from cdrom, the machines last approx 20 mins on the net before they are bogged down my malaware. Such a system would serve as a simple preemptive move that would protect a Linux desktop from such problems now, and in the future.
I counter that secure default firewall settings and default configuration settings where inbound services are not exposed by default is more than enough to prevent a linux distribution from experiencing the problem windows experiences and what you want would be a drain on development resources for very little actual gain. If there is a problem with the default configuration and the default firewall rules that should be dealt with directly.
I would say however, that it might be useful to think about how to have the ui for the system ask the user if they want to check for updates very soon after installationa is complete. Maybe firstboot could be taught to prompt the user about what updates are available, maybe something else.
-jef
Jeff Spaleta wrote:
On Tue, 21 Sep 2004 19:15:52 -0400, DALive Editor dalive@flashmail.com wrote:
Such a system have the following properties:
- be installed by default, but could be disabled during Anaconda
installer
- kick into action as soon as the presence of Internet connectivity
is detected
- reference a central server (group of servers) sending it's distro
version
- accept of packages vulnerable to attack over the Internet
- check this list against installed package list
- request iptable rules to block such an attack(s) if any installed
packages are vulnerable
OR we could just have very secure default configurations where no outside accessible services are turned on by default AND a default firewall that blocks all incoming service requests. Which is very close to what we have right now. Doing a default install of fedora core.. using the default firewall settings...and default configuration choices what services are exposed? What you describe makes sense in a windows world where incoming services are enabled by default..but it seems a huge waste of effort to me to implement this for fedora, when reasonably secure default configuration is used that limits the exposure to malicious attack by default. http://www.advogato.org/person/mjcox/diary.html?start=126 http://blogs.redhat.com/people/archive/000133.html
Point taken. What would you consider to be the worst case scenario for a fresh FC3 install in 2008, hyperthetically?
- alert the user that said rules were about to be entered into their
firewall, giving the user an opportunity to Cancel
- implement said rules
- if rule implementation failed alert user of failure and give user
option to block all packets except packets outgoing to port 80
- forward user to a detailed or simplified advisory online which
would, among other things give instructions on how to prevent attack, etc.
- would reverse rules once package version has been upgrade to a non
affected version, or user requests that rules be reversed
This complicated scheme sounds fragile and prone to its own vulnerabilities. Imagine if someone was able to spoof a dns server response and point you to the wrong list of packages..and that list encouraged you to create iptables rules that users dont understand how to review... sounds like a recipe for a problem to me.
You have a point here for sure. Would ssh keys not lessen such a problem? And I'm doubtful the target audience would be expected to understand iptables rules at all.
- check for update advisories at user defined intervals for users
permanently connected to the Internet, and for dial up users do check on Internet connection
Well rhn-applet checks for updates...or it should. And when connected to rhn up2date is able to give advisory text as well. I will agree with you that finding a way to get update advisory text into the ui again for fedora core updates is something worth doing.
Well, from my last two FC2 installs rhn-applet worked just well enough to tell me that here were updates to be made. It showed a 0 sizes for all the packages, I had to turn to Yumi for updates/installs (BTW I think Yumi or similar tool should be part of the distro). I hate to say this, but getting a sort of XPish poppup bubble to warn users of critcal upates at least would be a good step.
The reason I propose such a system is because over the past up I've installed a few fresh installs of Windows, and without service packs installed from cdrom, the machines last approx 20 mins on the net before they are bogged down my malaware. Such a system would serve as a simple preemptive move that would protect a Linux desktop from such problems now, and in the future.
I counter that secure default firewall settings and default configuration settings where inbound services are not exposed by default is more than enough to prevent a linux distribution from experiencing the problem windows experiences and what you want would be a drain on development resources for very little actual gain. If there is a problem with the default configuration and the default firewall rules that should be dealt with directly.
Fair enough, you make valid points. Any idea if a more flexible firewall configuration tool is in mind for FC? And correct me if I'm wrong, but isn't the default firewall setup for FC with FTP, SSH, etc open?
I would say however, that it might be useful to think about how to have the ui for the system ask the user if they want to check for updates very soon after installationa is complete. Maybe firstboot could be taught to prompt the user about what updates are available, maybe something else.
On this we both aggree. I for one don't think that enough is done in anticipation of novice users. I'm not suggesting a watering down of the desktop. Just some optional hand holding. Or is this the job of the KDE/GNOME guys?
-jef
desktop@lists.fedoraproject.org
-
Arthur Pemberton -
Jef Spaleta