En un articulo publicado ayer por Linux Magazine, trata del tema de las Instalaciones de Linux inseguras, particularmente, el caso de Ubuntu: http://www.linux-mag.com/cache/7297/1.html Para los que no puedan acceder al articulo, les pego el texto: Ubuntu Server has one of the cleanest and easiest Linux distribution installers. However, in many cases, its designers choose to ignore security in favor of ease-of-use. The result? An install that is not secure by default. Ronald McCarty Monday, April 13th, 2009 During the last couple of years, Linux distributions have focused on improving the installation process of Linux in order to make the freely available operating system available to more people. It’s a noble goal, however, when making anything in computing easier, a common approach is to make a number of decisions for the user — decisions that can put an inexperienced (and possibly an experienced) Linux installer at risk. Unfortunately, many Linux distributions make a number of painfully wrong security decisions at install. All too often these issues are overlooked by the administrator since the prevailing wisdom tends to be: “If it’s Linux, it’s secure.” As we’ll soon see, that’s not always the case. For this article we’ll look at Ubuntu Sever version 8.10. The methodology used to determine if the installation is as secure as it could be is three fold: * Identity, * Authentication, and * Authorization Identity is key to providing access to computing resources. For most internal services, identity of confidential information must be limited to those needing the information. Typically this is based upon user identification. To determine the identity of the user it must be validated via authentication (passwords). Authentication is key to ensuring a system is secure — since any security gained by identifying a user is quickly lost if weak authentication is used. Weak authentication can be caused by users (for example sharing or losing passwords), but weakness from a system standpoint will be reviewed in this article. Finally, authorization is necessary to ensure the appropriate resource are authorized for the user. This allows individual resources on a server to be further managed; for example, directories, printers, etc. Excuses, Excuses It is common for Linux proponents (and the makers of operating systems on their chosen platform) to rationalize away many of the decisions that go into developing an installer. The most often cited reason for a lack of security is based on the idea that security does not go hand-in-hand with ease of use. This article will show how and when wrong security decisions are made by installation programs and a more viable and secure secure resolutions you can use to counter the issues. Another common reason given for a lack of security is that a distribution is actually a collection of software and that the individual packages should be secure by the maintainer not the distributor. This justification of bad behavior by more bad behavior is simply poor practice — if the distribution is making decisions on behalf of the user, then it should make a solid decision and not push decisions within its control back on the package maintainer. (In fact, the distribution should help assist the community and point out to the package maintainer, any security concerns it or its users have identified.) Security During Installation Let’s begin with a fresh install of Ubuntu Sever 8.10. One of the immediate security concerns that come to mind during the installation of Ubuntu, is making the user’s home directory world readable: “The contents of your home directory will normally be visible to all users on the system” as shown in Figure 1, “Set up users and passwords”. Figure 1: Set up users and passwords Figure 1: Set up users and passwords Permissions open by default? In a rather odd twist, since the directory is wide open, the installer attempt to plug the hole by providing the option to encrypt a private directory! A closer look at the permissions validates the files are world readable: drwxr-xr-x 2 rmccarty rmccarty 4096 2009-04-13 09:40 rmccarty In addition, any additional users will be created by the useradd command world readable due to the entry: DIR_MODE=0755 in the /etc/adduser.conf file Continuing now, during the software selection phase of the installation, the following items were selected for installing: DNS Server, LAMP server, mail server, OpenSSH server, and the Virtual Machine host, as these are most likely the instances the server version of Ubuntu would be deployed in a typical setting. As the installation chugs along, it asks to change the “root” user password for mysql. This is excellent as mysql installs by default without a password set for the user “root” (root under mysql control, not the root account on the system). Unfortunately, the installer does allow the user to leave it blank rather than forcing the user to enter a password. The installer also does not enforce any minimum password lengths or rules. Another instance of choice trumping security. For these gotcha’s Ubuntu gets an A- on the report card for authorization whenever it could easily have gotten an A. Making users files world readable to ease installation but then pushing the issue back on the administrator or user to address is not ease of use. Post Installation - Network One of the quickest way for hackers to access systems are to use services that are not well documented or well understood. Once a system is in production, it is often unlikely the system will be further hardened so additional risk is created by not addressing services that are typically not being used. Ubuntu allows the software sets to be chosen that the sys admin wishes to use; however, a closer look at an abridged version of netstat shows services that are not likely needed or unintended by the sys admin will appear: root@sparky:~# netstat -lActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:pop3 *:* LISTEN tcp 0 0 *:imap2 *:* LISTEN udp 0 0 *:bootps *:* udp 0 0 *:bootpc *:* Ironically the first two entries: the Post Office Protocol version 3 (pop3) and the Internet Message Access Protocol version 2 (imap2) are installed and running despite Ubuntu having installed the more secure versions. Both of these older protocols were needed in years past for interoperability with older mail programs, but all major mail programs now support the more secure versions. (The biggest issues with these older services are clear text passwords; however, POP2 servers have also been vulnerable to root compromises.) The bootps and bootpc entries are for providing dynamic addressing via the BOOTP and DHCP protocols — and are on by default although static addressing is being used, and will typically be used by a server install. Even if the intent was to provide DHCP services to the network, this option is not covered as part of the install and is hidden under the DNS selection of the install. Having these unauthorized services running knocks the Ubuntu report card down to a B for authorization. User Accounts - Keys to the Kingdom Remote access combined with loose management of user IDs is a recipe for disaster. The key to secure system ID management is limiting the system to only those necessary and not allowing remote shell access to those accounts. Reviewing Ubuntu’s system accounts show the following: daemon:x:1:1:daemon:/usr/sbin:/bin/shbin:x:2:2:bin:/bin:/bin/shsys:x:3:3:sys:/dev:/bin/shgames:x:5:60:games:/usr/games:/bin/shman:x:6:12:man:/var/cache/man:/bin/shlp:x:7:7:lp:/var/spool/lpd:/bin/shmail:x:8:8:mail:/var/mail:/bin/shnews:x:9:9:news:/var/spool/news:/bin/shuucp:x:10:10:uucp:/var/spool/uucp:/bin/shproxy:x:13:13:proxy:/bin:/bin/shwww-data:x:33:33:www-data:/var/www:/bin/shbackup:x:34:34:backup:/var/backups:/bin/shlist:x:38:38:Mailing List Manager:/var/list:/bin/shirc:x:39:39:ircd:/var/run/ircd:/bin/shgnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/shnobody:x:65534:65534:nobody:/nonexistent:/bin/shlibuuid:x:100:101::/var/lib/libuuid:/bin/shsshd:x:107:65534::/var/run/sshd:/usr/sbin/nologin With the exception of the sshd, all of the system accounts are provided with an interactive shell session. So when any of these accounts are compromised interactive remote access is most likely the results. For example, a buffer overload for some of the mail processes could result in one of the mail related users (mail, news, uucp, etc.) providing remote access to the system through a shell login. Ubuntu should flag these accounts with the nologin option or possibly /bin/false. Even of more concern is the fact that there are user IDs that are in use that were not made obvious by the installation process. For example, print server was not chosen, yet the lp user exists and is active. Other suspect accounts are news, uucp, list, irc. Some arguments are made that the desire for standardization of user IDs across the distribution is more important than not including the user IDs. For example, uucp should always be UID 10. There is value to such a standard; however, a more secure method could be used by including intelligence into the package management and passwd programs. Or, a more simple option, to create the IDs and then to disable them to avoid the UID integer being used by another user ID. While Ubuntu’s practice is not uncommon, the identity management must be tighter on a distribution aiming at the enterprise market on the server distribution. Therefore, an A- is warranted for standard identity management. Summary Ubuntu has one of the cleanest and easiest Linux distribution installers; however, its designers choose to ignore security in some areas as shown above. Although these issues can be addressed post install in most cases, the install is not secure by default. Ronald McCarty is a systems/network professional and freelance author. Ron completed his undergraduate in CIS with University of Maryland and received his graduate degree from Capella University. Ron is the founder of Your Net Guard (www.YourNetGuard.com) a company specializing in IT infrastructure support. His free time is spent with his best friend and wife, Claudia, and their two children. Ron can be reached atmccarty@mcwrite.net. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org