Hi, I picked the default minimal installation option while setting up a test server but after it was all said and done I feel like I can still remove a number of packages. I figure the less I have installed the more easy to manage and safer (less vulnerable packages) the server will be. I'm using SuSE Professional 9.0 and here are the packages I deleted.. # rpm -e bc eject finger lukemftp portmap procmail rsh tcsh telnet I think portmap and rsh should not be included by default. In the case of portmap, if anyone really needs NFS then I'm assuming they're knowledgeable enough to install & enable it themselves. That being said I have a question. There are a couple more packages that I'm not sure are necessary but I don't know if removing them will break anything. I ran a script which showed that no other package depends on them cpp (The GCC Preprocessor) initviocons (Terminal initialization for the iSeries virtual console) isapnp (An ISA plug and play configuration utility) mailx (A MIME-capable Implementation of the mailx Command) sash (A stand-alone shell with built-in commands) sitar (System InformaTion at Runtime) src_vipa (Virtual Source IP address support for HA solutions) I'm guessing I definetly don't need cpp, initviocons. I don't have any ISA hardware so isapnp isn't necessary. I forward all mail to a local mail server so I don't need mailx on each computer. I don't need anything related to HA so src_vipa isn't required. Don't know about sash or sitar though. I just want to make sure that I'm not deleting anything vital for SuSE or YaST to function in a reliable fashion. Any thoughts? Regards, Avtar Gill
On Sat, Mar 06, 2004 at 02:59:36PM -0500, Avtar Gill wrote:
Hi,
I picked the default minimal installation option while setting up a test server but after it was all said and done I feel like I can still remove a number of packages. I figure the less I have installed the more easy to manage and safer (less vulnerable packages) the server will be. I'm
Installation of a tool or daemon package does not make your server more vurnerable as long as you do not enable this service. And I do not understand why a system should be more easy to manage when you have some less files installed. Robert -- Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
Robert Schiele wrote:
Installation of a tool or daemon package does not make your server more vurnerable as long as you do not enable this service.
Fair enough but if the tool or package isn't being used and thus not necessary then why leave it on the server? Leaving gcc on a computer that doesn't require it doesn't automatically make it vulnerable but if a local user's account gets compromised then gcc can be used to compile various utilities that will probably not contribute to the security of the computer or network. Now how would a user's account get compromised is another story and concerns a different layer of security but my point is that several security experts advise to keep as few files (I guess mainly suid/sgid ones) on servers as necessary.
And I do not understand why a system should be more easy to manage when you have some less files installed.
It's good practice to keep an eye on what updates need to be installed and test those updates first to make sure that when installing them on production machines they will perform as expected. The less packages installed means fewer updates apply to you. I don't understand the point of *not* removing unrequired packages.
On Sat, Mar 06, 2004 at 03:27:57PM -0500, Avtar Gill wrote:
Robert Schiele wrote:
Installation of a tool or daemon package does not make your server more vurnerable as long as you do not enable this service.
Fair enough but if the tool or package isn't being used and thus not necessary then why leave it on the server? Leaving gcc on a computer that doesn't require it doesn't automatically make it vulnerable but if a local user's account gets compromised then gcc can be used to compile various utilities that will probably not contribute to the security of the computer or network. Now how would a user's account get compromised
If an account gets compromised, the attacker could just copy any binary from remote he wants to have. An attacker compiling the binaries on the remote system would be a really stupid attacker anyway.
is another story and concerns a different layer of security but my point is that several security experts advise to keep as few files (I guess mainly suid/sgid ones) on servers as necessary.
suid/sgid files is another topic. But regular files could be installed by an attacker anyway.
And I do not understand why a system should be more easy to manage when you have some less files installed.
It's good practice to keep an eye on what updates need to be installed and test those updates first to make sure that when installing them on production machines they will perform as expected. The less packages installed means fewer updates apply to you. I don't understand the point of *not* removing unrequired packages.
For unused packages without suid/sgid files it makes no difference whether you have them installed or not or whether you test and install updates or not. So, if you like then uninstall them. I just wanted to express that it is pointless whether you do or not. Robert -- Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
Hi,
If an account gets compromised, the attacker could just copy any binary from remote he wants to have. An attacker compiling the binaries on the remote system would be a really stupid attacker anyway.
This is exactly what the Slapper worm did, and it was not stupid. A precompiled binary would have been bound to a specific system architecture, UNIX and dialect, maybe even distro and version. For automated attacks like these, compiling a C soure file on the target system gains flexibility, thus increasing the damage by being able to spread among much more systems. Thus, the presence of a C compiler (and other software development tools) on a public server IS a possible risk. Regards, Holger
participants (3)
-
Avtar Gill -
Holger Schletz -
Robert Schiele