Well. Yes, yes they are. One quick reason: Let's say you have a ... webserver. It starts to try and make outgoing connections to port 80. Hmm, maybe you got hacked by a worm (hey, it's only a matter of time before someone uses a 0-day for apache to do something nasty). Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/

Hi,

let me get this right: You think by installing a firewall, the system is somewhat secured to rootkits, because they may listen on "to be firewalled" ports? If somebody compromises your system and installs a rootkit, it's almost easy for him to fiddle holes in your firewall - because he uses a ROOTkit.

The majority of rootkits/etc are automated, ala subseven. In other words it will work 98% of the time. Security is never absolute. It's about reducing risk to acceptable levels. It's like making /tmp a seperate partition with noexec, you can still exec programs in /tmp but no hacking scripts I have seen have the capability of doing so.

Ralf

Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/

Yup, On 27-Sep-01 JW wrote:

At 09:59 AM 9/27/2001 +0100, you wrote:

...

IMHO, 'security through layers' is a good idea - let us say, for example, that some remote exploit is found in one of the services you do run. Let us also assume that a bad guy manages to find and use that hole to install a rootkit / some other compromise BEFORE you manage to apply the patch :-(

You then have no protection from the bad guy - his rootkit may be listening on a port which you probably would have firewalled with a strict firewall setup.

My take on the above is that if a cracker gets in far enough to install binaries, he can: 1. probably mess with your firewall rules 2. probably shut your firewall off 3. If none of the above, possibly trojan something like your web server or sshd that still has an open port in the firewall rules.

What do you think am I right, or am I missing something important?

This is where (real time-) intrusion detection should enter the game. The first bastion, the firewall-skript, either based on packet filters or stateful inspection, has been brought down or pierced. The next important barriers may consist of: 1. minimal trust-relationship between the firewall and the internal net 2. file integrity checks 3. very basic installation of the firewall, with a monolithic kernel w/ patches (e. g. Openwall), without any dev tools like gcc and gdb 4. security of the hosts in a dmz (if there is one) or the internal net Here we count on the fail-safe period of some kind of security installation. Imagine a Safe for storing backup media like tapes, CDs, etc. These safes should be fire-proof, and some of them are, but only for a fixed period, for 30 mins or one hour at temperatures of 800 centigrees. The same goes for firewalls and security installations in general, they are never unbreakable or 100% safe, but may keep even a skilled attacker busy for a couple of minutes/hours to activate adaequate countermeasures against the intruder, provided all the other security systems apart from the firewall skript are properly implemented and the admins react accordingly.

Jonathan Wilson System Administrator

Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com

Boris Lorenz ---

Hi,

On 27-Sep-01 Ray Dillinger wrote:

...

I have a machine, which serves several purposes. It is my main development platform, and it is also my main webserver.

Is this a public web server?

...

I've gone through the system and shut down all network services I'm not using -- for example squid came down, because I am not using proxy service at all, and ftpd came down because I don't want to provide ftp services. Rlogin, fingerd, telnetd, hylafax, etc, are also gone. No trusted hosts are defined for rlogin and friends to use anyway; the other boxes on my network are not considered "safe".

I'm using an apache server which I've been through extensive configuration on -- removing most of the modules because I wasn't using them. CGI is still there, but it's not activated on any host except the "default" host (which is only accessible from 127.0.0.1) and there are only two CGI scripts; These are the english-language "search" scripts that hunt through the documentation for keywords and topics, used by the SuSE help system, which I've kept onboard -- both of which I've audited for security. There were similar scripts to search in other languages, but since I'm not using other languages, they are gone now.

Finally, the 'su' binary is moved to sbin, and not available to any user except root.

Uhm... That one seems to be a "zip'ped unzip" ;)

...

I keep copies of my websites offline, on floppy disks. Ditto my inetd.conf, httpd.conf, and a few other configuration files. and, finally, my source code -- so if the machine ever gets subverted, I can restore them easily.

Now, here is my question: Do I get material additional security from my firewall, or does over-the-top paranoia on the other aspects of the config obviate the need for it?

You did the Right Thing by switching off all these unused services. Unfortunately you didn't state wether this machine is the "outpost" of a LAN connected to the internet or an internal web server with some developement tools on it, or just your client PC connected via ISDN/cable/modem. If it is a publicly accessible server I would definitely firewall it, no matter how many backups I'd have to reconstruct the system. There are many ways to "own" (crack) an improperly secured web server, not only brute-force attacks which lead to a system crash, but also more sinister, silent creep-ins of more skilled individuals who could use your server as a leap point to start attacks against other systems by cracking your server, installing high-port file transfer demons (ftp, ssh/sftp, rcp, whatever), uploading some funny stuff and compiling it using your pre-installed developement tools. Without firewalling, you'd have no real protection against these kinds of attacks.

If you have a public web server - go and firewall it, for God's sake. If it's a client PC at work/at home you could use the already-mentioned SuSE

Hi, In what category would you put a tool like portsentry from the abacus project of psionic? According to my knowledge it is not a real firewall but it blocks all unused ports and if someone tries accessing a closed port, the attacker will be blocked immediatly. Does anyone has ever used this tool and if yes, does a portsentry-secured system have enough security for a webserver in the rough world of the internet? Regards reto ----- Original Message ----- From: Boris Lorenz To: Sent: Thursday, September 27, 2001 11:34 AM Subject: RE: [suse-security] Are firewalls necessary? personal

firewall, which is easy to configure and understand.

Of course there is no need for hyperventilated paranoia, but a good sense of security and the acceptance of the fact that even the smallest home system can be the target (and thus often the source for further attacks) of malicous system crackers seems to be appropriate.

...

Bear

Boris Lorenz ---

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

On Thu, 27 Sep 2001, Boris Lorenz wrote:

Hi,

On 27-Sep-01 Ray Dillinger wrote:

...

I have a machine, which serves several purposes. It is my main development platform, and it is also my main webserver.

Is this a public web server?

Remember, no trusted machines defined. It regards the whole world as public, and it has its own IP address. Yes.

...

Finally, the 'su' binary is moved to sbin, and not available to any user except root.

Uhm... That one seems to be a "zip'ped unzip" ;)

I know, but I was worried about the possibility of subvertible- but-unknown-to-me shell-scripts using it.

You did the Right Thing by switching off all these unused services. Unfortunately you didn't state wether this machine is the "outpost" of a LAN connected to the internet or an internal web server with some developement tools

My network does not distinguish internal from external. The DSL bridge is connected directly to an ethernet switch, the ethernet switch is connected directly to all of the machines on my network. Each machine is a separate security configuration issue. Each machine regards its ethernet port as a connection to the whole wide world, and protects itself just as vigorously from its sisters as from strangers. I consider it mistaken to have lax security on a machine because it's "internal" -- that sets up a situation where one subverted machine destroys the security of the whole network. That may be tolerable if you're responsible for a hundred machines and you can't possibly keep idiots off of them, but when you have just six machines and nobody who isn't you ever has the console, it's just lazy. This one box I'm worried about in particular because of the presence of gcc, etc. And firewall config on it is really irritating because of the particular nature of the software I'm developing -- it tends to have fights with the firewall because it has to connect to other machines on pseudo-randomly determined ports.

on it, or just your client PC connected via ISDN/cable/modem. If it is a publicly accessible server I would definitely firewall it, no matter how many backups I'd have to reconstruct the system. There are many ways to "own" (crack) an improperly secured web server,

Agreed. I guess I want to know about properly securing a webserver and where I can read about properly securing webservers. I have done all I know to do to secure it, but what might I have missed? Bear