-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't see the need for 7 partitions, if you use journaling. For /tmp, use a tmpfs: none on /tmp type tmpfs (rw,size=2G,nr_inodes=200k,mode=01777) I use a 2G tmpfs with a 2G swap and 768M physical ram. I'm a gentoo user, and even compile stuff on this (it helps by anywhere from 0-10%), so it should be appropriate for your uses :) This leaves: / /var /home /usr /usr/local /etc I've never seen the /sbin/init.d thing, but I'm wary of separate /etc. /usr and /usr/local I'd think could be the same; if you break the system, you have to do a full reinstall anyway to rewrite the binaries, even though you could keep your configuration. I'm just being skeptic above, of course. :) Tom Knight wrote: |>-----Original Message----- |>From: Flavius Porumb [mailto:flavius.porumb@gtstelecom.ro] |>Sent: 13 July 2004 08:39 |>To: suse-security@suse.com |>Subject: [suse-security] SuSE webserver |> |>hello, |> |>I found something that may interest some of you, |> |>good luck, |> |>flavius |> |> Security (Beginner): Secure Installation of Apache Web Server |> Posted by hakimkt Tuesday, September 02, 2003 - 08:11 PM CEST | | | Fantastic HOWTO, well done HakimKT (whoever you are), and thanks to Flavius | for posting it. | | So, what are the problems with this approach? | I haven't seen anything absolutely terrible, but I'm no guru... | | * I wouldn't install any ftp server at all, as I just don't go for ftp and | I'm lucky in that my users don't generally need it... | * Portmap is installed by default (on SLES), so I remove it. | | Tom. | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA9D0xhDd4aOud5P8RAr4OAKCM2doyJC3+GpLOEpbiwNZGAPCnugCfUWmx DPxG5mHJL2DyW9omvd2Hy6g= =y9SW -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 nordi wrote: | John Richard Moser wrote: | > I don't see the need for 7 partitions, if you use journaling. | The reason for using several partitions is not that they can be checked | faster. This is done for increased security through special mount | options and to prevent local DoS attacks. But read on. | | > For /tmp, use a tmpfs: | [...] | > I use a 2G tmpfs with a 2G swap and 768M physical ram. | Which will make it easy to overload your machine if you don't use quotas | + a specifically hardened kernel. A local attacker can fill up your 2GB Ok local attacker loses his account and gets fired. Still no chance of lamers coming in from the web server. | of /tmp, which means your RAM is full and 1.5GB of swap in use. This is | going to be _really_ bad for your perfomance (=DoS). This is no concern | for your dev-box at home, but for a webserver this is can be a serious | issue. | | > /usr and /usr/local I'd think could be the same; if you break the | > system, you have to do a full reinstall anyway to rewrite the binaries | > even though you could keep your configuration. | | I think the point behind putting /usr/local/ on a seperate partition is | that you can mount /usr as read only (maybe even mount it from a remote | host if you have many boxes!). As most files are located there, yet they | hardly ever need to be changed, this is a good idea. Stuff that is | specific for this box can then be placed in /usr/local. Ahh, neat. | | In addition to using several partitions, /etc, /var, /home and /tmp | should be mounted with "nodev" and "nosuid" options. /usr/local should | at least have the "nodev" option set | Yeah, nice. | nordi | | Thanks for the clarification. I'm mostly into things like PaX and stack smash protection, proper coding, and a little access control. The whole nosuid-nodev thing I tend to overlook, as I'd expect SELinux or RSBAC to be used for that, or for mknod() or chmod()+s to just be denied to non-root users. I also use journaled filesystems (reiserfs), and think that a filesystem should be seen as 'clean' if it came down when there was nothing to be flushed to it and no files open. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA9FazhDd4aOud5P8RAmUNAJ44/FLjqNQo/x8oyZqPHXYdZPMVCgCfY9cO 5wXKHrQapnWB6Rs/qYCF7SU= =lsOO -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 nordi wrote: | John Richard Moser wrote: | |> | > For /tmp, use a tmpfs: |> | [...] |> | > I use a 2G tmpfs with a 2G swap and 768M physical ram. |> | Which will make it easy to overload your machine if you don't use |> quotas |> | + a specifically hardened kernel. A local attacker can fill up your 2GB |> |> Ok local attacker loses his account and gets fired. Still no chance of |> lamers coming in from the web server. | | | Assume you have a file owned by root called /tmp/foo. Now user bob comes | and does "ln /tmp/foo /tmp/bar". Then the hardlink /tmp/bar will be | owned by root and you will _never_ know who did it unless you do syscall | loggin (which I doubt). | So what are you doing running a server where local users are allowed to create hardlinks to root-owned files in /tmp anyway? ;) | Keep creating hardlinks until /tmp runs out of space or out of inodes. nr_inodes= is your friend. | Ext2/3 allow ~65000 hardlinks per file, ReiserFS allows ~2billion, so | flooding /tmp isn't a problem. Quotas don't help either since the | attacker doesn't own the file. The only thing that helps are special | hardening patches (OpenWall, GRSec) or special permission patches | (SELinux, RSBAC), but not everybody uses them. | | This attack can be truly annoying since it fills up /tmp and may keep | Apache from working. But with your setup (/tmp on tmpfs) it will bring | the server to a grinding halt where you can't even login remotely to fix | the server (assuming you don't have physical access). | | nordi | you raise interesting points. We should clip these issues off at the source. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA9G6bhDd4aOud5P8RAqgyAJ9HCyIdzqUHIy4t9IQvjR3g5enz8gCfefZW UaiUha6ezKXWVBFIGwkK/p4= =LxXK -----END PGP SIGNATURE-----

On Tuesday 13 July 2004 08:23 pm, suse@rio.vg wrote:

PS: Mounting /usr read-only would be fine if you only managed one or two servers.  When you manage two dozen, it quickly becomes too much of a pain in the ass when you have security patches for those read-only files.  Mount /usr remotely on all of them from a single source and patching that is a great theory until you realize that a single problem can wipe out your whole machine room...

Not if you mount your remote /use directly on top of an existing /usr. If you lose your remote, the worst that happens is you fall back to a slightly older local copy. -- _____________________________________ John Andersen

suse@rio.vg wrote:

Quoting John Richard Moser <nigelenki@comcast.net>:

...

| Keep creating hardlinks until /tmp runs out of space or out of inodes.

nr_inodes= is your friend.

| Ext2/3 allow ~65000 hardlinks per file, ReiserFS allows ~2billion, so | flooding /tmp isn't a problem. Quotas don't help either since the | attacker doesn't own the file. The only thing that helps are special | hardening patches (OpenWall, GRSec) or special permission patches | (SELinux, RSBAC), but not everybody uses them. | | This attack can be truly annoying since it fills up /tmp and may keep | Apache from working. But with your setup (/tmp on tmpfs) it will bring | the server to a grinding halt where you can't even login remotely to fix | the server (assuming you don't have physical access). | | nordi |

you raise interesting points. We should clip these issues off at the source.

While this discussion of how to flood /tmp is interesting, it's also rather silly. Does anyone really allow any critical services to get anywhere near /tmp these days? The idea of a single area where everything writes to probably sounded great twenty years ago, but these days, each critical service gets own sandbox to play in and never the twain shall meet. If someone were to somehow overflow /tmp on any of my servers, the only impact would be a note in the syslog...

Using /tmp for anything that matters is just asking for trouble...

PS: Mounting /usr read-only would be fine if you only managed one or two servers. When you manage two dozen, it quickly becomes too much of a pain in the ass when you have security patches for those read-only files. Mount /usr remotely on all of them from a single source and patching that is a great theory until you realize that a single problem can wipe out your whole machine room...

How to prevent flushing /tmp? What can be done to secure a system and prevent unwanted actions to be done? 1) Secure /tmp in /etc/fstab, e.g. /tmp = hda6: /dev/hda6 /tmp ext2 rw,nosuid,nodev,noexec 1 2 other sources: http://www.webhostgear.com/34.html This doesn't prevent /tmp from beeing flushed, but secures it a littlebit. 2) Limit users rights: man limits.conf This even doesn't prevent /tmp beeing flushed, but limits users right, if shellaccess is needed. 3) Set shell to /bin/false for FTP only users /etc/passwd userxy [...] /bin/false This prevents from logging in and doing funny tings. Normally a webserver account only needs ftp access or secure with ssl enhanced ftp. FTP-Server with ssl enhancement: http://sourceforge.net/projects/wzdftpd/ http://sourceforge.net/projects/indiftpd/ Or install secure bash without shell, e.g.: http://www.air.rzeszow.pl/bash-2.05b-secure/ 4) Use secumod to prevent creation of sym- and hardlinks. There are other kernelpatches/-modules out there doing the same. This prevents /tmp to be flushed with symlinks. 5) Further protection: set quota for tmp (this is no symlink protection, but limits user's space on tmp) 6) Run daily scripts as cron-job for /tmp or run logout-scripts. Examples should be found with google: http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-PS2HD-TET1_ht... Maybe you change attributes of the fs (chattr/capbits ...) so the unwanted action cannot be done. This attribute you don't see with ls command. lsattr lists the attributes set. Example for chattr: http://www.theparallax.org/security/linux/chattr.html (only in german - damn) Be careful with this, because this settings even are set for root (e.g. to disallow root to do things). It is even possible to lockout root and give rights compareable to "root" to different users. This makes problems administrating systems and running services, depending on how far you go. 7) If you program your own php-scripts for your webserver look for secure programmingstyle and secure your php.ini. 8) On the webserverside disable "follow symlinks" option (this may lead to other security-issues). No system can be made 100% secure, but this helps making it a little bit more difficult for malicious people to alter your system. Philippe

Am Mittwoch, 14. Juli 2004 14:39 schrieb nordi:

 > /dev/hda6      /tmp           ext2 rw,nosuid,nodev,noexec 1 2

Mounting /tmp as "noexec" could break stuff. Although I agree that nobody should run _any_ programs from /tmp, I have seen 2 programs that do expect stuff in /tmp to be executable.

Note that "noexec" does _not_ increase security as it can be easily circumvented with /lib/ld-linux.so /tmp/foo . Cheers, Stefan --

----- Original Message ----- From: "Tom Knight" <thomas.knight@ahds.ac.uk> To: <suse-security@suse.com> Sent: Wednesday, July 14, 2004 1:12 PM Subject: RE: [suse-security] SuSE webserver

Okay, FTP server of choice - Hakim's document mentions using proftpD. Is this really more secure than all the mainstrain alternatives? I've gone (where possible) for RPMs maintained by SuSE, and proftp isn't one of them. On SLES, the choice appears to be: ?pure-ftpd?1.0.12 ?Lightweight, fast and secure FTP server ?vsftpd ?1.1.0 ?A Very Secure FTP Daemon - written from scratch.

Despite my earlier insistance that I never install an FTP daemon, I'm now finding that I have to in order to support one piece of software. It's either that or samba.... :-(

Tom.

-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here

Another alternative is vsftp which is presented below: http://www.zdnet.co.uk/print/?TYPE=story&AT=2129119-39020445t-20000012c Use VSFTP for a secure FTP server Scott Lowe MCSE TechRepublic January 22, 2003, 10:37 BST Use VSFTP for a secure FTP server File Transfer Protocol (FTP) servers can be useful for providing files to customers and for exchanging files with partners and business associates. However, FTP can become the bane of existence for the admins who must keep these services secure and operational. Poorly secured FTP services can often result in a successful attack on a server. That's where VSFTP comes in. VSFTP is a secure, stable, and fast FTP server. It can greatly decrease the chances of an attacker gaining access to a server via FTP exploits. Want evidence? The Red Hat, OpenBSD, and SuSE FTP sites all have one thing in common: They all run on VSFTP. Even SANS recommends VSFTP as the preferred FTP daemon because of its tight security. VSFTP basics VSFTP is an FTP server daemon that runs on Linux/UNIX operating systems. Its primary features are security, performance, and stability. VSFTP includes a number of additional attractive features, including: a small system footprint, the ability to handle virtual users, the choice of operating in a standalone configuration or via the inetd daemon, and bandwidth throttling for more site control. As of this writing, the current version is 1.13, although version 1.2 is a release candidate and may very well be available by the time this article is published. Version 1.13 is a 117-KB archived download. For this demonstration, I am using VSFTP 1.13 on a Red Hat 8.0 server with version 2.4.18-14 of the kernel. Installation Installing VSFTP is much like installing any other application under Linux. To expand the downloaded archive, switch to the directory in which you saved it and type: gunzip -dc vsftpd-1.1.3.tar.gz | tar xvf - This will create a directory named vsftpd-1.1.3 and put all of the files into it. Switch to that directory by typing cd vsftpd-1.1.3 at the prompt. In this example, I am using a standard configuration, which begins by typing make at the command prompt. If you want to make changes to the configuration, you can edit the builddefs.h file in the distribution before compiling with the make command. If the compilation process is successful, a binary file named vasftpd will be placed into this directory. In my testing, the compilation went quickly and was free of errors. Adding users VSFTP uses the Linux/UNIX "nobody" user as a part of the default configuration. On most Linux/UNIX operating systems, this user exists by default, but if it doesn't exist on your system(s), you'll need to add it. On my system, I get the following results when I try to add it (which indicates that the user already exists): [root@rh8lab VSFTP d-1.1.3]# /usr/sbin/useradd nobody useradd: user nobody exists In addition, you need to create an FTP user if you want to support anonymous FTP. If you plan to always authenticate the incoming user, you don't have to do this. However, to preserve the security of VSFTP, the anonymous user's home directory must not be owned by the FTP user, and the user should not have any permissions for it. You can use the commands in Table A to accomplish this. Table A mkdir /var/ftp/ Creates a directory named /var/ftp. /usr/sbin/useradd -d /var/ftp ftp Creates a user named "ftp" with the home directory /var/ftp. On many systems, this user will already exist. chown root.root /var/ftp Changes ownership of the /var/ftp directory to the root user. chmod og-w /var/ftp Removes the write permission from others and groups. Creating the FTP user and setting appropriate permissions Next, make sure that the directory /usr/share/empty exists. If not, create it with the mkdir command. Finally, you need to install the executable file, help pages, and so forth, that were previously created during the build process. To do this, change to the directory in which you built vsftpd and type make install. This installs everything you need to begin using VSFTPD except a configuration file. You can copy a sample configuration file to the /etc directory by typing cp vsftpd.conf /etc. Page 2 Standalone If you want to run VSFTP in standalone mode, all you need to do is add a single line to the end of the /etc/vsftpd.conf file that reads "listen=YES" and then execute /usr/local/sbin/vsftpd &. The & tells the program to continue to run but bring you back to a command prompt. Assuming you get no error messages, you can now connect to the FTP server as an anonymous user and get directory listings, transfer files, etc. Using xinetd Since I'm doing my testing and demonstration on a Red Hat 8 system (which uses xinetd), I will be focusing on the xinetd installation process. inetd If you are running an inetd machine, you can use the installation instructions included with VSFTP for details on how to set up your server. Everything should work if you add the lineftp stream tcp nowait root /usr/local/sbin/vsftpd to /etc/inetd.d and then restart the inetd daemon either via a reboot or kill -SIGHUP {pid of inetd}.Be sure that this is the only "ftp" line in the file. If you are running on an xinetd machine, a configuration file resides in /etc/xinetd.d named vsftpd. If you can't find this file at that location, you can copy it from the vsftpd.conf example that comes with the VSFTP distribution. When editing this file, you'll see a number of parameters underneath "service ftp" that dictate how the VSFTP server will function. Table B lists these parameters, their defaults, and what they mean. Table B socket_type stream This is the type of TCP socket to use for this protocol. FTP is a TCP stream. wait no This is associated with the ability for the socket to accept messages. user root What user should be used to launch this service? Note that VSFTP reduces privileges as soon as possible after starting. server /usr/local/sbin/vsftpd This is the location of the server program associated with this configuration file. If you have vsftpd in a different location, you should change this value. nice 10 This option modifies the default scheduling priority for the process. 10 is the default with the range being 20 (highest) to 19 (lowest). disable no The service is not disabled. In other words, it should be started when xinetd starts up. per_source No default This specifies the number of concurrent connections allowed from the same IP address. It's useful for limiting the number of connections from a single site. instances No default This limits the maximum number of concurrent FTP connections to the server. It's useful for limiting server load. no_access No default This is a list of IP addresses that are not allowed to access this service. I will be using the default configuration file and restart xinetd on my Red Hat server by typing /etc/rc.d/init.d/xinetd restart at the command prompt. Note that if you previously configured VSFTP in standalone mode, you need to remove the line "listen=YES" from /etc/vsftpd.conf. If you don't, xinetd will restart, but the vsftpd service will not work. I made that mistake the first time I configured VSFTP. Once this is done, you should be able to connect to the VSFTP server as an anonymous user and get directory listings, download files, etc. Enabling controlled access Setting up an FTP server to distribute software to anyone who connects can be useful in many cases, but you may want to control access to the FTP resources. For example, suppose you want to set up a site just for your customers. You can do this with VSFTP by making use of PAM. My Red Hat server uses PAM for authentication, as do most Red Hat machines. To determine whether your distribution uses PAM, look for a filename pam.conf or for a directory named pam.d. Since my Red Hat server uses the pam.d directory for its PAM information, I will be demonstrating that installation method only. VSFTP comes with a sample PAM configuration located in the Red Hat subdirectory of the distribution. This file needs to be renamed and copied to the pam.d directory, which you can do with the command: cp vsftpd.pam /etc/pam.d/ftp Next, you need to change the VSFTP configuration to allow local user logins. To do this, edit the file /etc/vsftpd.conf and uncomment the line "local_enable=YES". Now, when you attempt to connect to the server as a Linux/UNIX user, you will be placed in that user's home directory. Listing A shows the results of my demonstration. As you can see, a directory listing was provided after I logged into the VSFTP server. Summary VSFTP powers many of the largest sites in the open source world, including the security-conscious Open BSD project and Red Hat Linux. With its small footprint, ability to handle large loads, security, and flexibility, it makes an ideal FTP server for any organisation that wants file transfer capability but not the major security headaches that typically come with it.