I am running the following services on my SuSE 6.4 box: Port Service version comments 21 in.ftpd 6.4/OpenBSD/Linux-ftpd-0.16 2 users allowed access strong passwords enforced 25 sendmail 8.9.3 53 named BIND 8.2.3-REL 80 httpd Apache 1.3.12 PHP/3.0.15, mod_perl/1.21 110 rinetd 0.61 POP3 requests redirected to another machine 443 https Apache 1.3.12 According to an nmap port scan, all other ports up to port 1024 are in state filtered. Anything from port 1024 up is closed. My question is whether this box is vulnerable in its current state and if so, what should I be doing to secure it? Tnx, MR
Check CERT vulnerabilities for the specific software you are runnnig.
Esspeciall BIND and FTP.
Regards,
Oyku
----- Original Message -----
From:
I am running the following services on my SuSE 6.4 box:
Port Service version comments 21 in.ftpd 6.4/OpenBSD/Linux-ftpd-0.16 2 users allowed access strong passwords enforced 25 sendmail 8.9.3 53 named BIND 8.2.3-REL 80 httpd Apache 1.3.12 PHP/3.0.15, mod_perl/1.21 110 rinetd 0.61 POP3 requests redirected to another machine 443 https Apache 1.3.12
According to an nmap port scan, all other ports up to port 1024 are in state filtered. Anything from port 1024 up is closed.
My question is whether this box is vulnerable in its current state and if so, what should I be doing to secure it?
Tnx, MR
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On 14-Jun-01 ryanm3@eircom.net wrote:
I am running the following services on my SuSE 6.4 box:
Do you use the latest kernel? If your current kernel is <= 2.2.14 you should update.
Port Service version comments 21 in.ftpd 6.4/OpenBSD/Linux-ftpd-0.16 2 users allowed access strong passwords enforced
I would replace this with proftpd (www.proftpd.org), which is more flexible and more secure than the standard in.ftpd. Proftpd can be run standalone as a demon listening to port 21 or, like usual, via inetd.
25 sendmail 8.9.3
AFAIK this version of sendmail seems to be secure. However, sendmail is a complex piece of software and may contain a couple of 'sleeping bugs' which could propose a threat to your host. To overcome this possible danger you may want to use a smtp proxy software which accepts mails on port 25 and hands them over to your MTA. Thus, if the (low priviledged) smtp proxy breaks or gets cracked, your system can not be 'owned' by elevated privileges (it could with sendmail as it normally runs as root). You can find a good smtp proxy and other such tools in the tis firewall toolkit (tis fwtk) from www.tis.com/research/software/ .
53 named BIND 8.2.3-REL
No problems with this one. Make sure you choose a non-priviledged user to run bind with in a chroot jail. Look at www.linux.org/docs/ldp/howto/Chroot-BIND-HOWTO.html how this can be done.
80 httpd Apache 1.3.12 PHP/3.0.15, mod_perl/1.21
No problems with this Apache version. If you run MySQL, too, make sure you use the latest version.
110 rinetd 0.61 POP3 requests redirected to another machine
No known problems (to me). I use ipmasqadm for port redirection which IMHO should perform a little better than rinetd.
443 https Apache 1.3.12
No known problems. Make sure your private key files and certificates are properly secured...
According to an nmap port scan, all other ports up to port 1024 are in state filtered. Anything from port 1024 up is closed.
My question is whether this box is vulnerable in its current state and if so, what should I be doing to secure it?
If possible, avoid protocols with clear text passwords (ftp, pop3, etc...). If not possible, replace these protocols with ones using encryption or tunnel requests to unsafe services via ssh/ssl. Many tightly secured systems had been cracked in the past due to a combination of sniffers running in the networking neighborhood and heavy use of clear text protocols. You may want to take a look at ssh/openssh to find out wether file transfers from/to your host can be accomplished with sftp (secure ftp) or scp (secure file copy). If so, use it and forget about ftp.
Tnx, MR
Good luck,
---
Boris Lorenz
Boris Lorenz
I would replace this with proftpd (www.proftpd.org), which is more flexible and more secure than the standard in.ftpd. Proftpd can be run standalone as a demon listening to port 21 or, like usual, via inetd.
ProFTPd has a *LONG* list of bugs, security incidents and compatibility issues. I would not trust that software. -- Matthias Andree
I would replace this with proftpd (www.proftpd.org), which is more flexible and more secure than the standard in.ftpd. Proftpd can be run standalone as a demon listening to port 21 or, like usual, via inetd.
ProFTPd has a *LONG* list of bugs, security incidents and compatibility
Thats new to me: when I search www.cert.org for proftp, there is not one hit.
issues. I would not trust that software.
Which ftp server would you recommend instead? mfg ar -- mailto:andreas@rittershofer.de http://www.rittershofer.de PGP-Public-Key http://www.rittershofer.de/ari.htm
ProFTPd has a *LONG* list of bugs, security incidents and compatibility
Thats new to me: when I search www.cert.org for proftp, there is not one hit.
Searching cert archives might not be a good idea, then. For instance, take a look at the code, maybe compare it with code from vsftpd (Chris Evans) or postfix. Decide then.
issues. I would not trust that software.
We had proftpd running on ftp.suse.com for a few weeks. I have added a few patches that made it possible to run the server with 500 instances, but 600 knocked the box out - too much system call overhead, /proc accesses in the file transfer loop, name it, you get it.
Which ftp server would you recommend instead?
We are running wuftpd-2.4 on ftp.suse.com now, the daemon that is installed as /usr/sbin/wu.ftpd. It is the old version, not 2.6. Thomas Biege made a comprehensive audit some time ago, and since then there has been no bug in it. 5:12am up 60 days, 13:38, 2 users, load average: 3.30, 2.86, 2.42 The load is a result from 18 concurrent rsync processes. We have only 370 sessions right now, the output is near 48 MBit/s. As an additional solution there might be the BSD-derived ftpd (in.ftpd). It works quite nicely, it's slim and fast, and it does its job. Roman.
"Andreas Rittershofer"
I would replace this with proftpd (www.proftpd.org), which is more flexible and more secure than the standard in.ftpd. Proftpd can be run standalone as a demon listening to port 21 or, like usual, via inetd.
ProFTPd has a *LONG* list of bugs, security incidents and compatibility
Thats new to me: when I search www.cert.org for proftp, there is not one hit.
Search Bugtraq. Virtually every 1.2.0pre and 1.2.0rc version (more than 10) has had a security problem or other severe bugs, including exploitable buffer overflows, crashes when command and CRLF span over package boundaries, 1.2.1 suffers from glob(3) problems, and so on. That beast cannot possibly be secure if public beta test versions have problems that big. The list is endless, I'll not reproduce it here. I've been using the Linux port of ftpd-BSD and limiting the impact of the glob problem with DJB's softlimit. For fresh installs, I'd recommend against ftp in the first place, for anonymous ftp only in the second place, and check out pureftpd and vsftpd. Both are still beta, but close to release and feature security as a major design goal. ProFTPd also sported security as a design goal but has failed miserably more than one time. If pureftpd and vsftpd will be secure, we'll see. At least vsftpd has an extensive audit scheme. -- Matthias Andree
On 18-Jun-01 Matthias Andree wrote:
Boris Lorenz
writes: I would replace this with proftpd (www.proftpd.org), which is more flexible and more secure than the standard in.ftpd. Proftpd can be run standalone as a demon listening to port 21 or, like usual, via inetd.
ProFTPd has a *LONG* list of bugs, security incidents and compatibility issues. I would not trust that software.
Well... At least proftpd *has* a security history with an active maintainer team. They have their own security reporting facility, a section for critical and not-so-scary bugs, and if you review the security incidents for other ftp demons, proftpd still stands strong. For me it's the most useable ftp server for linux to date. Which ftp server do *you* trust in?
-- Matthias Andree
---
Boris Lorenz
ProFTPd has a *LONG* list of bugs, security incidents and compatibility issues. I would not trust that software. True. but I know that no bug has been found in wu-ftpd since a security audit was done on it perhaps you should try that. Also vsftpd which I use is really the best I've seen in a long time. The download url is somewhere in the archives of this list. Noah.
Something to consider: for complicated setups proftpd is a LOT easier to
configure then wuftpd for example. Thus you are less likely to accidently
make a directory world readable.writeable or whatever.
Kurt Seifried, seifried@securityportal.com
PGP Key ID: 0xAD56E574 Fingerprint:
A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574
http://www.securityportal.com/
----- Original Message -----
From: "semat"
ProFTPd has a *LONG* list of bugs, security incidents and compatibility issues. I would not trust that software. True. but I know that no bug has been found in wu-ftpd since a security audit was done on it perhaps you should try that. Also vsftpd which I use is really the best I've seen in a long time. The download url is somewhere in the archives of this list. Noah.
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Something to consider: for complicated setups proftpd is a LOT easier to configure then wuftpd for example. Thus you are less likely to accidently make a directory world readable.writeable or whatever.
wuftpd ftpaccess files might be a little more complicated than apache-style proftpd files. But nevertheless: If your setup is fragile wrt complexity, then the complexity will be the primary source of problems. Always keep it simple and short. Roman.
On Mon, 18 Jun 2001, Kurt Seifried wrote:
Something to consider: for complicated setups proftpd is a LOT easier to configure then wuftpd for example. Thus you are less likely to accidently make a directory world readable.writeable or whatever.
True, but then again, FTP is not the best choice for sensible data after all, see f. i. http://cr.yp.to/ftp/security.html HTTP/TLS and OpenSSH's sftp are viable alternatives in many cases.
True, but then again, FTP is not the best choice for sensible data after all, see f. i. http://cr.yp.to/ftp/security.html
I've just read that article. The conclusions he makes are not quite right, if not plain wrong (it's a client problem, not a protocol design bug: What would make a client send a RETR or STOR command if the data connection, be it PASV or PORT, has not been established yet succesfully?). I'll write an own article about it. Will be on http://portal.suse.de/ .
HTTP/TLS and OpenSSH's sftp are viable alternatives in many cases.
Thanks,
Roman.
--
- -
| Roman Drahtmüller
On 20-Jun-01 Roman Drahtmueller wrote:
True, but then again, FTP is not the best choice for sensible data after all, see f. i. http://cr.yp.to/ftp/security.html
I've just read that article. The conclusions he makes are not quite right, if not plain wrong (it's a client problem, not a protocol design bug: What would make a client send a RETR or STOR command if the data connection, be it PASV or PORT, has not been established yet succesfully?).
True. The whole article is a little blunt, only covering parts of the ftp problem. What the author correctly has figured out is that implementing ftp should be avoided where possible, but the widespread use of this protocol makes this suggestion quite hard to follow in some circumstances. IMHO the worst problems with ftp grow from a combination of the protocol's clear-text transmission of passwords and weakly/lazily configured authorization schemes (one pw for everything, etc.), together with buggy/misconfigured ftp demons.
I'll write an own article about it. Will be on http://portal.suse.de/ .
Delighted to hear that. Perhaps an addition to the SuSE security FAQ would also be a good idea. [...]
Thanks, Roman. -- - - | Roman Drahtm�ller
// "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | N�rnberg, Germany +49-911-740530 // (Batman Costume warning label) |
---
Boris Lorenz
On Wed, 20 Jun 2001, Roman Drahtmueller wrote:
I've just read that article. The conclusions he makes are not quite right, if not plain wrong (it's a client problem, not a protocol design bug: What
Well, some of the problems can be alleviated for by proper validation and a big portion of paranoia. FTP as it is will never be secure. It would require STARTTLS and in-band transportation of data (in-band == in the same channel that has completed the authentication). FTP is usually wrongly implemented on client and server side; numerous if not all FTP clients mess up LIST and NLST, the first is to be presented raw, the second can be dealt with automatically (for mirroring); so FTP effectively is not suited for mirroring, timestamps being the least of the problems. (The MPLF extension will fix this soon.) Servers still over active mode although the problems cannot possible be overcome.
participants (8)
-
Andreas Rittershofer
-
Boris Lorenz
-
Kurt Seifried
-
Matthias Andree
-
Oyku Gencay
-
Roman Drahtmueller
-
ryanm3@eircom.net
-
semat