Critical Defense Daemon

[DALive Editor]

Jeff Spaleta wrote:

>On Tue, 21 Sep 2004 19:15:52 -0400, DALive Editor <dalive at 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
>
>
>  
>