Someone wrote:
Run a firewall like SuSEFirewall. THe default setup should protect you 10 times better than what you are protected on your Windows box.
I enable logdigest on my servers that are connected to the net and I configure it to mail me every hour, so I can see relatively quickly if something goes wrong.
---- The above says it all: instead of having an interactive tool that requires the interactive user's permission, most Linux users have to rely on a "log file" -- that _retrospectively_ will tell you what has happened on your box. It doesn't allow you to permit/deny traffic in real time, nor does it allow real-time interactive firewall rule construction based on usage. It isn't about the relative strengths of security but about real-time interactivity. Linux is poor in real-time, interactive controls and monitoring. I find the discussion about how the user should or shouldn't be doing things amusing -- i.e. "Dear ex-windows user: um, we don't have the features and abilities you want, so we want to educate you on what you think you should want and give you lots of reasons why what you want doesn't really protect you (which is what we wanted to tell you what you really wanted)." Bleh! *Differences of Win vs. Linux Security model* There is a fundamental difference in the security model and tools available for windows and for linux. With Windows, you only have the concept of one active user at the desktop -- and that user usually "owns" the computer and usually has that computer to themselves. Such a design isn't where Linux has come from. Linux is descended (in thought and design concept) from unix -- which was designed for multi-user computer sharing -- usually with no one at the console. It wasn't designed for attended monitoring 24x7, whereas Windows is designed from the point of the "single-user", who is usually in attendance when the computer is being used. In the Windows philosophy of _past_, nothing should happen on your computer unless you "instigate it". NOTE: there is a difference between the historic use of 1-windows user/computer and later editions of Windows used as a server. Even Windows as a server isn't designed as *nix has been. Multi-user *nix was the norm and it has been adapted for single-user use. With windows, it is the opposite -- it was designed for solo, non-networked use and has been adapted for network use. Everything about Windows was designed for "interoperability" with other Windows computers in a "non-threat" environment. *nix was designed for separating users to allow multiple "academics" to share information, but still keep them separate. It heralds back to "Multics" that was designed with security in mind in the 1960's, but I digress. Windows in its current incarnation (XP as version 5.1 of "NT") is similar in design to many current *nix implementations. NT was _supposedly_ descended from mainframe OS principles. Like *nix, NT supports multiple users. Like *nix NT supports levels of privileged code. NT has superior security features to many *nix implementations, however, it's insecure by *configuration*. NT (as used for Windows XP sold for individual computers) is still configured for compatibility with the older, single-user Win9x systems. It is the default configuration for usability and compatibility that makes WinNT based systems less secure than their *nix counterparts. Most NT applications require "root access" to install. Many NT applications install system drivers as part of their typical install. At least WinNT has the concept of 2 driver privilege levels: Ring 0 & Ring 1 (which is different from user processes that operate at Ring 3). Few, if any *nix systems use more than the 2-ring security model. Single process capabilities have been present in NT since it's 4.x days -- likely 3.x (though I had no experience w/such). Linux had process capabilities so screwed up that they were complete disabled in 2.2.16 (~2000) as a critical security flaw because the implementors and reviewers of capabilities in linux, /at the time/, had a fundamental lack of understanding of how they should work. One of the worst offenders is *non-system software* -- _games_ in Windows. How many games try to install "copy-protection" into a user's computer by attempting direct access to the hardware and/or by installing specialized drivers? Such applications are uncommon in *nix. In historic *nix systems, users _couldn't_ install applications requiring direct-hardware access. I could go on for ever on the differences in design, but suffice it to say: if the linux desktop "shell" required constant "root access" to install and run hardware, and if it provided all of the "automatic" features of Win XP, it would be just as insecure (perhaps more so) as Windows. To get back to the Original Poster's article -- and some people's claim that *nix doesn't provide real-time monitoring and permission grants to interactive users only shows the lack of flexibility of the *nix model. Some claim it would be "possible to provide the same functionality in *nix". I challenge you to do so with the same constraints on easy of install and control for what ever user is using the desktop. It won't be easy: You will have to: 1) identify what process is attempting unauthorized access. (remember, the process may be owned by any user -- not just the "logged in user). 2) display a high priority popup on the ... well...who? The primary console user's terminal? What if someone is running "Citrix" or logged in via Terminal Services? Who gets the message? In Windows, it is the console user. 3) Allow the Console user to decide if the "arbitrary process" (good chance it isn't owned by the user) should be granted the appropriate access. Same with incoming connections -- they are probably going into some "system process" (response to "bind/dns", incoming "email" handled by sendmail, etc). 4) Allow the "unprivileged" user to decide on network access for some non-user owned (likely, system level) process. Ex. I just use a browser to look at a site. Say it is configured to use a proxy (squid). I see a message that squid wants an outside line. Do I allow it? Is it my browser? If I do allow it, squid is allowed for all users and all processes -- it isn't just my browsing. Suppose I choose to allow it - some firewall rule (running with system privileges) needs to be modified. This means my "interactive popup" is allowed to modify system firewall tables? That breaks the fundamental user-superuser separation on *nix. 5) To modify firewall rules, the user must (at least temporarily) be running with system (root) privileges. You've violated *nix's main protection. 6) If the *nix system is running "X", more than one user may be running a console session. How will you trace what "outgoing connection attempt" is related to which user (if any). How will these users decide on which non-user utils get access? Bottom line: I submit that you can't require instantaneous user interaction on *nix and have the system function "normally". Most network activity on a *nix system happens on *behalf* of a user -- maybe no specific user, but just as part of making the *nix system responsive and robust. You can't provide something as convenient as "ZoneAlarm" on Linux without _alot_ of work and a violation of the *nix system design. If you create the support structure necessary to support such "automation", including the ability to click on mail attachments like ".pdf" and have them auto-open acrobat, you create the same opportunity for "holes" in *nix as in WinNT bases systems. Do you need more examples? Note -- manual, human-based *logfile review* is _unacceptable_. It is _reactive_, time consuming and error prone. In the one-hour between being mailed "logs", a well qualified hacker could be in, plant a trojan and clean up the logs to remove a trace of their being there. If you have to sleep or go on a vacation for any number of days, you have even less responsiveness to intrusions. Sorry, but in my opinion, Linux is considerably more lacking in real-time, interactive security response tools that talk to the active user. In the absence of a real-time, at the console user, traffic is *blocked*. This is very *untrue* for the average *nix system, where systems are expected to run "unattended". None of this should be taken to mean that Linux, as used today is less secure than Windows -- but it easily could be if it was _configured_ to be as easily interoperable as WinNP is (by requirement of legacy compatibility) to be. It should be noted that the main hindrance to good security is _usability_. The less usable a security system is, the more likely users are to find a way to work around it. The presence of an easy-to-use, interactive, graphical firewall configuration tool that allows real-time monitoring and feedback -- so a user can see that if an application wants web access, they get immediate prompting that tells them the application is attempting network access, informs them what application(s) are attempting what type of internet access. Post examination of log files doesn't provide that type of interactive training. FYI -- I do have linux log files that show me blocked outgoing firewall traffic. It isn't uncommon to see applications (running on Windows through a linux proxy server) to simply and mysteriously "not work". It's only later, if I examine log files and remember what I was doing at the time, do i find that I couldn't watch some "video" because my firewall blocked outgoing ports by my "http-proxy" (squid) to some site. It is rare that I know why the application(s) failed at the time they fail -- there is no interactive message to tell me that a forbidden network traffic type is being automatically blocked. That is way less usable (and useful) than having a popup instantly tell me that my attempt to play some video is accessing some weird port, that isn't in the normal video port range. It's even less easy to "temporarily" allow one specific traffic request through. I.e. - on linux, I'd have to add some firewall rule, go back and run my app, then re-edit the firewall rule to remove the temporary access. **Very** inconvenient. That's not my idea of _usable_ security. Ms. Linda Walsh