View Single Post
  #3   (View Single Post)  
Old 19th June 2008
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

One of the catchphrases of OpenBSD is, "Secure by Default." See www.openbsd.org/security.html for an overview of security features, including "Secure by Default."

As mentioned there, the default installation has few services running, and each is considered secure enough to be exposed directly on the Internet without fear of successful attack. As the home page of the Project website states, there have been two known remote attack vectors in the last 10 years, but no known exploits of them.

Once you change anything in the default installation -- make a configuration change, install a 3rd party package -- you are no longer running a default install, and the choices YOU make will affect your security. Knowledge is necessary, and it is gained by experience and understanding of your specific environment and specific needs.

For example: during install, you are asked if you would like to have an OpenSSH daemon started during bootup. If you request the OpenSSH server to be started, you need to know that the default configuration allows the "root" superuser to log on, and, the default configuration allows authentication via passwords. So, if you enable the SSH daemon during install, you are immediately responsible for ensuring the strength of the root password on any network the OS is exposed to, including the Internet, if directly connected to it. Poor decisions right then, such as "root" having no password or a poor password such as "root" -- will make your OS immediately insecure.

Why is this the default configuration? Primarily for ease of initial provisioning the OS remotely. Would you want a production server to have this configuration? Perhaps, depending on exposure and the strength of passwords used.

I'm one of those admins who believes passwords are an awful way to secure anything. An 8-byte ASCII password can be broken in a few days by scripted attack. So I configure all production SSH daemons I administer to deny root logon, and also to deny password authentication. Instead I configure alternate, stronger authentications such as public keys and S/Key one-time-passphrases. The specific authentication depends upon the server and its services.

Understanding your environment, and the changes you wish to make, then comprehending the impact of your choices are necessary steps to success.
Reply With Quote