|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
|FTP Protocol and Clients||Recommended Links||Pure-ftpd Daemon||vsftp daemon||WU-FTP daemon|
|obligatory steps||General Steps||Securing vsftpd||Securing wu-ftpd||FXP||Scripting FTP sessions|
|Troubleshooting of ftp connections||Free FTP clients for Window||sftp||chrooting sshd/sftp on Solaris||Humor||Etc|
Anonymous Access is a method by which any user can gain access to your FTP site without the need of a user account.
There are some customer facing services that can be served effectively by Anonymous FTP sites, but the majority of the time allowing anonymous access will result in the eventual hijacking of your site by individuals wanting to host illegal files and copyrighted material.
By removing the capability for anonymous access, you are essentially limiting access to your
FTP site to successful authentication by a predefined user account.
By enabling logging your FTP site, you can ensure that you will have an accurate record of which IP addresses and users accessed your site. Maintaining a practice of routine log review can enable you to assess your traffic patterns and identify any security threats and/or breaches.
Frequent review of logs can alert you to suspicious activity that could be a malicious user trying
to hack in. It can also be used as an effective method for intrusion detection by giving you a historical
look into your FTP sites usage.
If you only need your users to transfer files to your server and not transfer files from your server, consider configuring your FTP site as a “blind put”. What this means is that users are allowed to write files without the having the ability to read from your FTP directory. This will protect the contents of your ftp site in case of an unauthorized user getting access to your ftp directory.
Configuring Blind Puts should be done both at the FTP site and on the directory’s permissions.
Most Unixes allow for the enforcement of Disk Quotas. Disk Quotas can effectively limit the amount of disk space a user can have ownership of. You can also limit the total number of files (inodes) and some other parameters (Linux File System Quotas)
edquota -u user_id
Edit directly using vi editor commands. (See below for more info.)
For example: edquota -u user1System Response (RH 7+):Disk quotas for user user1 (uid 501): Filesystem blocks soft hard inodes soft hard /dev/hda5 1944 0 0 120 0 0
- blocks: 1k blocks
- inodes: Number of entries in directory file
- soft: Max number of blocks/inodes user may have on partition before warning is issued and grace persiod countdown begins.
If set to "0" (zero) then no limit is enforced.
- hard: Max number of blocks/inodes user may have on partition.
If set to "0" (zero) then no limit is enforced.
This can be used creatively to limit access to your FTP site to only times that are authorized.
If for instance you are using this Ftp site in an enterprise environment for business use, you could
assess your availability needs to be limited to working hours. By denying logon during after hours,
you would effectively secure your ftp site for most of the calendar day.
Using complex passwords is a good security practice whenever you are dealing with end user authentication. In the case of FTP, it can be a crucial component in securing your site.
Linux allows for administrators to force users to comply with strong password requirements. By enabling the ‘Passwords Must Meet Complexity Requirements’ via PAM. In this case FTP user accounts will be forced to adhere to following restrictions when selecting their passwords:
Security policies allow administrators to lock down the number of times failed logins can be attempted before an account is locked out. You should enable this option but never set it too low (5 or 7 are usable numbers, 3 is not). By enabling this option you dramatically limit exposure to password crackers.
Red Hat Linux provides vsftpd FTP servers - a standalone, security oriented implementation of the FTP service.
Before submitting a user name and password, all users are presented with a greeting banner. By default, this banner includes version information useful to crackers trying to identify weaknesses in a system.
To change the greeting banner for vsftpd, add the following directive to /etc/vsftpd/vsftpd.conf:
Replace <insert_greeting_here> in the above directive with the text of your greeting message.
To change the greeting banner for wu-ftpd, add the following directives to /etc/ftpusers:
greeting text <insert_greeting_here>
Replace <insert_greeting_here> in the above directive with the text of your greeting message.
For mutli-line banners, it is best to use a banner file. To simplify management of multiple banners, we will place all banners in a new directory called /etc/banners/. The banner file for FTP connections in this example will be /etc/banners/ftp.msg. Below is an example of what such a file may look like:
#################################################### # Hello, all activity on ftp.example.com is logged.# ####################################################
|It is not necessary to begin each line of the file with 220 as specified in Section 126.96.36.199 TCP Wrappers and Connection Banners.|
To reference this greeting banner file for vsftpd, add the following directive to /etc/vsftpd/vsftpd.conf:
To reference this greeting banner file for wu-ftpd, add the following directives to /etc/ftpusers:
greeting terse banner /etc/banners/ftp.msg
It also is possible to send additional banners to incoming connections using TCP wrappers.
For both wu-ftpd and vsftpd, the presence of the /var/ftp/ directory activates the anonymous account.
|If enabling anonymous access to an FTP server, be careful where you store sensitive data.|
If you want to allow anonymous users to upload, it is recommended you create a write-only directory within /var/ftp/pub/.
To do this type:
Next change the permissions so that anonymous users cannot see what is within the directory by typing:
chmod 730 /var/ftp/pub/upload
A long format listing of the directory should look like this:
drwx-wx--- 2 root ftp 4096 Feb 13 20:05 upload
|Administrators who allow anonymous users to read and write in directories often find that their server become a repository of stolen software.|
Additionally, under vsftpd, add the following line to /etc/vsftpd/vsftpd.conf:
Because FTP passes unencrypted usernames and passwords over insecure networks for authentication, it is a good idea to deny system users access to the server from their user accounts.
To disable user accounts in wu-ftpd, add the following directive to /etc/ftpusers:
To disable user accounts in vsftpd, add the following directive to /etc/vsftpd/vsftpd.conf:
The easiest way to disable a specific group of accounts, such as the root user and those with sudo privileges from accessing an FTP server is to use a PAM list file as described in Section 188.8.131.52 Disabling Root Using PAM. The PAM configuration file for wu-ftpd is /etc/pam.d/ftp. The PAM configuration file for vsftpd is /etc/pam.d/vsftpd.
It is also possible to perform this test within each service directly.
To disable specific user accounts in wu-ftpd, add the username to /etc/ftpusers:
To disable specific user accounts in vsftpd, add the username to /etc/vsftpd.ftpusers:
You can use TCP wrappers to control access to either FTP daemon as outlined in
If using wu-ftpd, you can use xinetd to limit the effects of denial of service attacks.
Edit the file /etc/ftpaccess and delete all anonymous entries.
This is an example of how the file ftpaccess would look like:
class all real,guest * email email@example.com loginfails 3 readme README* login readme README* cwd=* message /welcome.msg login message .message cwd=* compress yes all tar yes all chmod no guest delete no guest overwrite no guest rename no guest log transfers anonymous,real inbound,outbound shutdown /etc/shutmsg passwd-check rfc822 warn guestgroup FTPgroup greeting full
First of all create a special usergroup were you can put in all the users. For example FTPgroup
>> groupadd FTPgroup
Now you can create some users:
>> adduser -g FTPgroup "username"
(if you choose not to give shell access to these users look at paragraph 4.)
>> passwd "username"
Make sure you copy "bin", "etc" and "lib" and the files in it from /home/ftp or /var/ftp to the homedirectory of the user. Use cp -R like this:
>> cp -R /var/ftp/pub /home/username
Create a directory called Download and Upload in the "pub"directory for the users to up- and download files from.
>> mkdir /home/username/pub/download >> mkdir /home/username/pub/upload
Be sure to set the rights and ownership onto these just created directory's.
>> chown username:FTPgroup upload download >> chmod 500 /home/username/pub/download >> chmod 700 /home/username/pub/upload
This will give the user read/write access to upload and read access for the download directory.
To keep the users in their own homedirectory you can add "guestgroup FTPgroup" to the ftpaccess
Open /etc/ftpacces with your favorite texteditor and add:
If you choose to deny your users to gain shell access via telnet or ssh all you have to do is
create a dummy shell wich you can name NoAccess and place it under /etc/.
>> touch /etc/NoAccess
Open the file with your editor and put something in like this:
#!/bin/sh # echo " Shell Access denied! " echo " " echo " You don't have a valid login for this server " exit 0
Save the file and make sure that the shell is executable:
>> chmod +x /etc/NoAccess.
Once you've done this edit the file /etc/shells and add the just created shell.
The file /etc/shells would look like this:
/bin/bash2 /bin/bash /bin/sh /bin/ash /bin/bsh /bin/tcsh /etc/NoAccess
If you added the user manually and did not use my shell-script you have to edit /etc/passwd
and change the shell for the users.
The entry would look like this:
Just change /bin/bash to /etc/NoAccess.
If everything is up and you choose to add users manually you can add the user to the right shell with the next command.
>> adduser -g FTPgroup -s /etc/NoAcces "username"
In order to automate the creation of users I've created a small shell-script that will add an user to FTPgroup set the shell, creates upload en download and copy's the required dir's from the FTP directory.
#!/usr/bin/perl print "Username: "; chomp ($Name =<STDIN>); system("adduser -g FTPgroup -s /etc/NoAccess $Name"); system("cp -R /var/ftp/pub /home/$Name"); system("cp -R /var/ftp/bin /home/$Name"); system("cp -R /var/ftp/lib /home/$Name"); system("cp -R /var/ftp/etc /home/$Name"); system("mkdir /home/$Name/pub/upload"); system("mkdir /home/$Name/pub/download"); system("chown $Name: $Name/pub/download"); system("chown $Name: $Name/pub/upload"); system("chmod 500 /home/$Name/pub/download"); system("chmod 700 /home/$Name/pub/upload"); system("passwd $Name"); print "Done! user $Name has been added.\n";
You cannot create a textfile under windows and copy in onto your server. This will not work properly.
Create a file called useradd and insert the lines. You can run the file from the command line like this but first set the rights as followed:
>> chmod +x useradd >> chown root:root useradd
or whatever filepath you wish and start adding users automatically.
December 30, 2013 | The Register
A BBC FTP server ftp.bbc.co.uk was compromised by a Russian hacker and access to it touted online, say computer security researchers.
The miscreant behind the attack on the internet-facing file store tried to sell access to the infiltrated system to other crims on Christmas Day, we're told. Hold Security – which this year has helped break news of data heists at Adobe and a top-flight limo company – spotted someone trying to sell access to ftp.bbc.co.uk, according to Reuters.
FTP is a 1970s vintage protocol for transferring information in bulk over the internet; its use is discouraged because usernames and passwords to log into accounts are sent over the network unencrypted, although there are ways to establish secure connections.
The hacked service was used by reporters to file material from the field, and by advertisers to upload video to BBC Worldwide channels. The invaded computer was cleaned up over the weekend.
Right now the system appears to be running ProFTPD 1.3.3g on Solaris, but there's nothing to indicate that was the vulnerable software. However, versions of ProFTPD prior to 1.3.3g suffer from a use-after-free bug (CVE-2011-4130) that allows an attacker to execute code remotely on the machine hosting the server; a flaw that's been known about since 2011.
"The only other information that I can offer is that the hacker was offering a screenshot proving that he had administrative access to the BBC server," Alex Holden, chief information security officer at Hold Security, told BBC News.
It is not clear how deep the hacker managed to penetrate Auntie: specifically, whether the miscreant obtained just an FTP admin account login, gained control of the user account running the FTP daemon, or gained full control of the machine running the file-transfer server. Don't forget, a compromised computer could have acted as a stepping stone to other systems within the Beeb's network.
If it's not broke...
See title. Just because it's old, doesn't mean it doesn't work. And with very much less overhead than sending big files via HTTP.
Though granted, a restricted-access FTP site should really be sFTP.
Re: If it's not broke...
"should be living on the DMZ"
Should be on A DMZ, not THE DMZ. Why should my FTP server be anywhere near the web server or mail server? Modern firewall design allows individual dirty networks for services so why only have a single big dirty network playground for hackers? The fewer systems they can access from the compromised one the less likely it is they will spread to the internal networks.
I also hate the term DMZ since the dirtiest network after internet is often the internal client one, and DMZ sits next to the internal networks rather than between them and internet these days so DMZ is very outdated.
Re: If it's not broke...
Yup, nothing wrong with FTP if you ask me. It's simple, robust and can be made as secure as a remote connection can be. Certainly the method of choice for the Beeb's field reporters, safer and more robust than pretty much anything more "current", bar sFTP (which ain't that "current" itself, if a good 20 years younger).
Re: If it's not broke...
"safer and more robust than pretty much anything more "current""
There is also FTPS which predates SFTP by a few years while using the actual FTP protocol and daemons. Of course, the protocol isn't what the problem was here, it was a software bug leading to rights escalation and so could just as easily affect SCP/SFTP. It's less likely that anyone would find the bugs in the FTP/S daemon these days when compared to SFTP due to lower usage but if someone wants your system there is usually a way.
Re: If it's not broke...
"FTP is a 1970s vintage protocol".
Yes, like TCP and IP and many others in everyday use. What's your point?
Re: If it's not broke...
> There is also FTPS
I don't usually consider FTPS a separate protocol; it's still FTP
> a software bug leading to rights escalation and so could just as easily affect SCP/SFTP.
Indeed. Especially SCP, which is known to be vulnerable (which is why most "scp" clients actually use SFTP under the hood).
Re: If it's not broke...
The problem with the "If its not broke, don't fit it" attitude is that, when it infects management, it is used as an excuse to deny or delay all preventative maintenance, patching, and so on. Resulting in, eventually, system failures and security breaches due to outdated, bugged, and vulnerable versions of software or sub-optimal configuration. Management would often prefer to have failures they can blame on software bugs or attackers to having a failed modification or patch being blamed on their own department.
Yes, FTP is a relatively lightweight and efficient protocol, but you still need to keep up with the patching and improve security (such as switching to sFTP or FTPS as you mentioned).
Re: If it's not broke...
The problem with the "If its not broke, don't fit it" attitude
And when the Damagement have the desire to fix everything regardless of whether it's broke, we end up with the Windows 8 UI. The problem is in how to educate the bosses enough that they understand what "maintenance" is without going batshit crazy on "new". Or worse, "better because it's newer".
Why blame the BBC? This stuff was outsourced to Siemens in 2004. I should know, I was one of the poor sods who was sold!
That said from the sounds of it, the ftp access pre-dates even BBC Technology back to the days of the beardy wierdy geniuses at Kingswood Warren.
The service part of Siemens was bought out by Atos.
There are many parts of BBC IT outsourced to Atos (BBC Desktop for example) but much is run in house as well by BBC Technology / Tech Ops (most of the web based services and as noted above, BBC Worldwide).
There will probably be much finger pointing as there often is with these things. That's if there was any serious threat. A "stepping stone" it may have been, but into what exactly? And let's face it, the Beeb is just a media organisation, not a bank or a holder of huge amounts of important personal data.
Maybe someone could have done us a favour and taken Radio 1 off the air.
Re: Siemens: To be fair...
It's pretty safe to say that the BBC have enormous amounts of personal data.
Given the prevalence of password reuse, they hold plenty of concern even if you only think in terms of email/password pairs. That said, I do see your point. Anybody with best practices in mind when watching "World's Craziest Fools," is fine.
*nips off to change some passwords*
The 1337day site has an exploit for sale which claims to be for ProFTPD 3.3.3g and quotes the BBC FTP site. Some of their exploits for sale have been a bit dubious in the past so rather than it being a new ProFTPD vulnerability it may just be instructions on a misconfiguration of that particular server.
Always have loved the simplicity and stability of FTP personally and added secure SSL functionality has been available for years on many clients/servers. FxP'ing between servers still happens!
"account running the ftp daemon"
Since this was the bbc, what are the chances that ftp was running as root?
Many of our clients still use ftp to send data to us every few minutes throughout the day (Gas Industry). This is all over Europe and beyond not just in the UK so FTP is very far from dead. As for the attack itself, shocker, an FTP account where the username and password are sent in plain text was compromised (although it seems the attacker here had it even easier). That is why an FTP box just does FTP and sits out on its own in the DMZ and only has the required ports open to the outside (in other words was SSH available to the Outside). I do also wonder if they restrict user accounts, I only allow 3rd parties FTP and FTPS access (and that FTPS access is not run by my SSH daemon either), they have no shell so would have to find a vulnerability in order to elevate themselves somehow. Even if they did compromise the box, it wouldn't help them much here as it has no access to anything else.
I live under the assumption I have been hacked or will be, makes it much easier to manage risk. I hope the BBC do the same.
Software Clients - pass the blame
Maybe this is something to do with Microsoft, having failed to support sftp clients/servers as part as their supplied install packages, whilst maintaining support for ftp.
Re: Software Clients - pass the blame
Erm, but Microsoft has supplied and supported an RFC based FTPS (FTP over SSL) server ever since IIS7....
Re: Software Clients - pass the blame
FTPS != SFTP (which is far more widely used IME)
They use a pretty convoluted aspera based ingest system for almost everything important, content wise anyway.
That said, the bbc is a loose collection of individuals who basically hate each other and are allowed to operate as virtually separate companies.
There are hundreds of FTP servers operating internally and externally for various puropses, getting files on and off the system for engineering purposes, providing logs to suppliers for support, just the usual mash up.
They use a broad range of operating systems ranging from windows 3.11 all the way up to win8 and a whole host of x like systems. Nothing gets patched, in case the patch upsets some of the unsupported 15 year old mission critical software that Dave from FM&T wrote in 1999.
I swear, only a few years ago, I looked after ceefax that has only just been switched off, when asked to find out why it kept falling over, I found the servers in a cupboard and they were a rag tag assortment of 386's the occasional Pentium 1 and, well, you can imagine the rest.
They do take perimeter network security reasonably seriously though so I very much doubt that this FTP server will have made an easy stepping stone into the rest of the network.
ITN hacked via FTP too
Many years ago (about 1999/2000) I was called in to deal with a hack via FTP which defaced ITN's web ste. That was a Solaris box to - a Sun E450.
It wasn't a technically difficult hack though. FTP was world available, the username was ITN and the password ITN. This account had root privilege. Doh!
Jim has written a great article on how you can upgrade your FTP site's security through simple configuration changes.Securing FTP
This document contains information about securing the Internet File Transfer Protocol (FTP) server. While there are a variety of daemons around, most of the material covered here pertains only to wu-ftpd.
In the past there have been bugs found in older versions of various ftpd daemons. Crackers have exploited these bugs and will continue to do so. See http://www.netect.com/advisory_0209.html for the latest attack exploiting a problem in the realpath() function. So, the first order of business is to upgrade that server to the latest version! My favorite site for finding wu-ftpd is at ftp://ftp.vr.net/pub/wu-ftpd/wu-ftpd/, which also includes "vr" patches; they're in my mind akin to the Linux kernel's "ac" patches.
Now on to some really fun steps (as if compiling ftp isn't already fun):
Lets take a peek at /etc/ftpaccess as well
- Check your /etc/ftpusers (a misnomer in my opinion).
This file includes the login names of those users who are NOT allowed to login to your site. This file may look something like:
~[root(lindstrom)1]: cat /etc/ftpusers
At the very least, this file should contain root, system accounts, and nobody. Other possible users will include anonymous and ftp. Adding those accounts will effectively disable anonymous ftp. Removing the ftp user from /etc/passwd will also disable anonymous ftp.
This file configures ftpd, but only if ftpd is called with -a. I recommend using this handy feature. Discussing all the possibilities of this file is out of the scope of this document. I urge you to man ftpaccess to get a better understanding of it.
Setting up the FTP area file structures
- Every happy server should do some logging.
In order to do such things we'll use the "log" directive. Typically you'll want to log transfers and violations of security rules. I also log commands as well. To achieve this, I've added: log transfers anonymous,real,guest inbound,outbound
log security anonymous,guest,real
log commands real,anonymous,guest Logging of incoming and outgoing transfers will go to /var/log/xferlog, unless otherwise changed by adding: log syslog
- Well isn't that a funny-looking file..
Path-filters are useful, particularly if you have your site setup for "drop-off" areas where uploading is permitted. Path-filters use regular expressions to determine what a file can or cannot be. /etc/pathmsg will be displayed when a filename is unacceptable according to the following filters: path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9_\\.]*$ ^\\. ^-
path-filter guest /etc/pathmsg ^[-A-Za-z0-9_\\.]*$ ^\\. ^-
path-filter real /etc/pathmsg ^[-A-Za-z0-9_\\.]*$ ^- These filters permit anonymous and guest users to create only files containing A-Z, a-z, 0-9, a period, an underscore or a dash, but NOT beginning with a period or dash. Now these users will no longer be able to create directories that contain spaces, special characters, con trol characters, or the like. Directories of this nature are often used to hide pirated software. Real users have almost the same rules as anonymous and guest, except a real user can create a file beginning with a period.
- Noretrieve and the wonderful world of uploads
To prevent certain files from being retrieved, use the noretrieve directive. Some examples might include: noretrieve .notar
Marking the file ".notar" noretrieve will prevent it from confusing some clients. I'll talk about its purpose later on. The incoming directory shouldn't allow downloads until the admin has had a chance to inspect the files and move them to an appropriate public place for downloading. If your /incoming directory is on its own partition/drive (which is good practice to prevent Denial of Service attacks on the filesystem, and you might also consider mountin g it with the "nodev" and "noexec" options), there will be a lost+found directory. The contents of this directory shouldn't be downloaded.
wu-ftpd by default doesn't allow anonymous uploads, so this will have to be changed if you so desire. For this example, we'll assume that the upload directory in the chroot environment is /incoming. This is what a typical configuration may look: upload /home/ftp * no
upload /home/ftp /bin no
upload /home/ftp /etc no
upload /home/ftp /lib no
upload /home/ftp /incoming yes ftpadmin ftpadmin 0440 nodirs
Here we've explicitly said that uploads are denied everywhere except for /incoming. Files uploaded will have owner and group of ftpadmin, permissions set to 0440. Users will not be able to make directories by adding "nodir." I don't recommend allowing users to make directories.
One note about directories and incoming: You may like to setup your incoming directory to something like /incoming/[some dir], where "some dir" is a directory known only to your local users and those you want to have upload access to your site. This way the occasional passer-byer who logs in wont be able to upload anything unless th e correct directory is known. Granted, this is like a weak password in many ways.
Sometimes it may be desirable to set a umask for uploaded files. This can easily be accomplished by using "defmask" or calling ftpd with the -u option. The following sets a umask of 0377 for everyone:
defumask 0377 or this sets a umask of 0377 for class remote only: defumask 0377 remote
- Everybody loves guests!Let's talk about guestgroup for a moment. When a real user is a member of a guestgroup (as defined in ftpaccess), the user is treated like an anonymous user and the session is chrooted. This also requires a little bit /etc/passwd fun! Let's say we put: guestgroup ftpguest in our ftpaccess file. Any user logging in as a member of "ftpguest" will be setup as a guest. However, before we can rejoice, we need to do that passwd editing. For this example, user bob is a member of "ftpguest" and we want bob to be chrooted. Normally his passwd line would look like bob:x:1051:502:mister the bob:/home/bob/:/bin/ftpshell so instead we change it to bob:x:1051:502:mister the bob:/home/bob/./:/bin/ftpshell
The path specified before the /./ tells the daemon where to chroot to. The path that follows the /./ is the user's home directory in the chrooted environment. Now, when bob logs in, he will be chrooted to /home/bob, and his current directory will be / (which, outside of the chrooted environment is /home/bob).
Also, since the user is chrooted to /home/bob, he will require an ls binary inorder to be able to do a dir listing, just like how any anonymous user will require the same thing. necessary binaries and the structure of ~ftp/ is the next topic.
- I'm sorry I can't allow you to do that, Dave.While it's the default in most wu-ftpd configurations, it's a good idea to explicitly disallow anonymous/guest users any privileges. So, to revoke these rights, add to ftpaccess:
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
chmod no guest,anonymous
umask no guest,anonymous
Finally we setup restrictions at the file level.
The root directory and every directory under it should not be owned by the same user/group of the ftp account. We certainly don't want anonymous users writing to just anywhere.
d--x--x--x 2 ftpadmin ftpadmin 1024 Feb 12 18:34 bin/
d--x--x--x 2 ftpadmin ftpadmin 1024 Jul 11 06:36 etc/
drwxr-xr-x 2 ftpadmin ftpadmin 1024 Feb 5 14:48 lost+found/
drwxr-xr-x 7 ftpadmin ftpadmin 1024 Mar 31 17:04 pub/
drwxrws-wt 2 ftpadmin ftpadmin 1024 Jul 18 01:00 incoming or if you want to use the 'secret' directory approach for uploads: drwxr-x--x 3 ftpadmin ftpadmin 1024 Jan 2 1999 incoming/
drwxrws-wt 3 ftpadmin ftpadmin 1024 Jan 2 1999 incoming/secret_upload_dir
Other points of interest
ls, tar, and gzip live here. tar and gzip are optional and used for on-the-fly compression. All files should be compiled statically, mode 111, and owned by root. NEVER put any command interpreters in here.
Passwd and group files go in here, and possibly other needed files like pathmsg (see above). Please note, however, these should NOT be the same files from /etc/passwd and /etc/group. This would permit anyone to retrieve a copy of your account information. Instead, they should contain only the usernames and groups of files in t he FTP directories, and NO password information. An example might be
lindstrom(root):/home/ftp# cat ./etc/passwd
lindstrom(root):/home/ftp# cat ./etc/group
- So what about the rest of those directories?
If you've done everything concerning /incoming you should be fine. There is no need for a /lib because all of our binaries are compiled statically. However, if you weren't able to compile your binaries static, the libs that they require would live here. /lost+found we've talked about earlier, (remember it's that directo ry you magically get when you create a partition) and /pub will also be fine as long as sane user/group/permissions are used, as talked about in this section.
- Odds and Ends..
Adding .forward .rhosts to the FTP root would be a good idea to prevent these from being added later by some other means, such as an exploit. The justifiably paranoid may chattr +i these files. /home/ftp[root(lindstrom)2]: touch .forward .rhosts
/home/ftp[root(lindstrom)3]: chmod 0 .forward .rhosts
/home/ftp[root(lindstrom)4]: chattr +i .forward .rhosts
Also, its a good idea to add ".notar" as well to your incoming directories so as to prevent keen users from downloading files using on-the-fly tarring.
For the paranoid, wu-ftpd has something just for you. Define paranoid in config.h and "questionable functions" will be disabled. Check out FIXES-2.4-HOBBIT from wu-ftpd source for more info on this.
Support for S/Key and OPIE are included in wu-ftpd, and I've seen patches for SSL and SRP floating around the internet. SSL for wu-ftpd is at ftp://ftp2.replay.com/pub/crypto/crypto/SSLapps/. However, it's a bit dated as far as keeping up with recent versions of wu-ftpd. There i s also edssl (a non SSL to SSL translator) in the /pub/crypto/crypto/SSLapps/SSLlynx/ directory on that site. SRP patches can be found at MrWizard's homepage along with some other nifty things.
This appendix provides instructions for installing and running Sun™ ONE Identity Server in a chroot environment. This appendix contains the following sections:
- Before Creating chroot
- Creating a chroot Environment
- Installing Identity Server Under chroot
- Starting Identity Server In chroot
- Identity Server Log Files In chroot
Chroot comes from the change root function in Unix®. When Identity Server is installed in a chroot environment, a named directory becomes the root directory. The new chroot directory then becomes the starting point in the path for all Identity Server searches. The chroot prevents malicious programs from accessing the real root file system, providing an added measure of security for the Web Server and Directory Server processes that power Identity Server.
Before beginning the chroot creation process, the following points should be noted:
- You must have root privileges in UNIX or Administrator privileges in Windows® to install Identity Server in a chroot environment.
- Patches cannot be automatically installed in the chroot environment. If any patches have been installed to your system, they must be manually copied to the appropriate locations:
- Sun ONE Directory Server
- Sun ONE Web Server
- Sun ONE Identity Server
Identity Server processes that serve requests cannot see or access files outside the chroot directory so the appropriate Identity Server files must be copied into the chroot directory structure. The first step is to create the user root environment for Identity Server. This new root must contain everything that Identity Server expects from the natural root (/).
$CHROOT is the variable name for the chroot directory.
- Create the following system directories on the computer system that will host Identity Server.
- Create system soft links using the command ln -s.
The following soft links should be created:
- /usr/bin -> bin
- /usr/lib -> lib
- /var/tmp -> tmp
Create devices under $CHROOT using the command mknod.
For example, to create the device /dev/tcp under the $CHROOT directory, enter:
mknod dev/tcp c 11 42
The following devices should be created under the $CHROOT directory:
Copy files from directory /etc to corresponding locations under the $CHROOT directory. (For example, copy /etc/hosts to $CHROOT/etc/hosts.)
The following files should be copied:
Copy binaries to the corresponding locations under the $CHROOT directory. (For example, copy /usr/bin/sh to $CHROOT/usr/bin/sh.)
The following files should be copied:
Copy libraries to corresponding locations under the $CHROOT directory. (For example, copy /usr/lib/libc.so* to $CHROOT/usr/lib/.)
If the computer system in which Identity Server is installed is a 64-bit machine, the libraries from /usr/lib/64 and /usr/lib/lwp/64 need to be copied to $CHROOT/usr/lib/64 and $CHROOT/usr/lib/lwp/64, respectively.
The following files should be copied:
Copy the zoneinfo files to corresponding locations under the $CHROOT directory. (For example, copy /usr/share/lib/zoneinfo/* to $CHROOT/usr/share/lib/.) Copy the locale files to corresponding locations under the $CHROOT directory. (For example, copy /usr/lib/locale/* to $CHROOT/usr/lib/locale.)
Installing Identity Server Under chroot
- Install Identity Server 6.1 in a directory other than $CHROOT.
If an installation directory is not specified, Identity Server is installed, by default, in /opt/IdentityServer_base .
- Stop the instance of Sun ONE Web Server.
- Stop the instance of Sun ONE Directory Server.
- Copy the entire Identity Server directly from IdentityServer_base to the $CHROOT directory using the same structure.
- Copy files from the following locations to the corresponding directories under $CHROOT:
Create a loopback mount for Java.
The following command makes Identity Server ready to run under chroot environment:
mount -F lofs /usr/j2se $CHROOT/usr/j2se
Create a loopback mount for /usr/share/lib and /usr/lib/mps.
mount -F lofs /usr/share/lib $CHROOT/usr/share/lib
mount -F lofs /usr/lib/mps $CHROOT/usr/lib/mps
Starting Identity Server In chroot
To start Identity Server in the chroot environment, both Directory Server and Web Server must be started.
- Start Directory Server using the chroot command:
chroot $ROOT $IS_ROOT/DSServers/slapd-hostName/start-slapd
- Start Web Server using the chroot command:
chroot $ROOT $IS_ROOT/SUNWam/servers/https-instanceName/https-start
Identity Server Log Files In chroot
Identity Server normally creates log files (Error Log, Debug, etc.) in the following directory:
/var/opt/SUNWam/debug and /var/opt/SUNWam/logs
Under chroot these log files will be created at the following locations:
It's important to give to your strictly FTP users no real shell account on the Linux system. In this manner, if for any reasons someone could successfully get out of the FTP chrooted environment, it would not have the possibility of executing any user tasks since it doesn't have a bash shell. First, create new users for this purpose;
These users will be the users allowed to connect to your FTP server.
This has to be separate from a regular user account with unlimited access because of how the chroot environment works. Chroot makes it appear from the user's perspective as if the level of the file system you've placed them in is the top level of the file system.
Use the following command to create users in the /etc/passwd file. This step must be done for each additional new user you allow to access your FTP server.
[root@deep ] /# mkdir /home/ftp [root@deep ] /# useradd -d /home/ftp/ftpadmin/ -s /dev/null ftpadmin > /dev/null 2>&1 [root@deep ] /# passwd ftpadmin
Changing password for user ftpadmin New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully
- The mkdir command will create the ftp directory under the /home directory to handle all FTP users' home directories we'll have on the server.
- The useradd command will add the new user named ftpadmin to our Linux server.
- Finally, the passwd command will set the password for this user ftpadmin.
Once the home/ftp/ directory has been created you don't have to use this command again for additional FTP users.
- Edit the /etc/shells file, vi /etc/shells and add a non-existent shell name like null, for example. This fake shell will limit access on the system for FTP users.
[root@deep ] /# vi /etc/shells
/bin/bash /bin/sh /dev/null
/dev/null, This is our added no-existent shell. With Red Hat Linux, a special device name /dev/null exists for purposes such as these.
- Now, edit your /etc/passwd file and add manually the /./ line to divide the /home/ftp directory with the /ftpadmin directory where the user ftpadmin should be automatically chdir'd to. This step must be done for each FTP user you add to your passwd file.
The account is ftpadmin, but you'll notice the path to the home directory is a bit odd. The first part /home/ftp/ indicates the filesystem that should be considered their new root directory. The dot . divides that from the directory they should be automatically chdir'd. change directory'd into, /ftpadmin/.
Once again, the /dev/null part disables their login as a regular user. With this modification, the user ftpadmin now has a fake shell instead of a real shell resulting in properly limited access on the system.Setup a chroot user environment
What you're essentially doing is creating a skeleton root file system with enough components necessary, binaries, password files, etc. to allow Unix to do a chroot when the user logs in. Note that if you use the --enable-ls option during compilation as seen above, the /home/ftp/bin, and /home/ftp/lib directories are not required since this new option allows Wu-ftpd to use its own ls function. We still continue to demonstrate the old method for people that prefer to copy /bin/ls to the chroot'd FTP directory, /home/ftp/bin and create the appropriated library related to ls.
The following are the necessary steps to run Wu-ftpd software in a chroot jail:
First create all the necessary chrooted environment directories as shown below:
[root@deep ] /# mkdir /home/ftp/dev [root@deep ] /# mkdir /home/ftp/etc [root@deep ] /# mkdir /home/ftp/bin [root@deep ] /# mkdir /home/ftp/lib
- The last two are required only if you are not using the --enable-ls option.
Change the new directories permission to 0511 for security reasons: The chmod command will make our chrooted dev, etc, bin, and lib directories readable and executable by the super-user root and executable by the user-group and all users.
[root@deep ] /# chmod 0511 /home/ftp/dev/ [root@deep ] /# chmod 0511 /home/ftp/etc/ [root@deep ] /# chmod 0511 /home/ftp/bin [root@deep ] /# chmod 0511 /home/ftp/lib
- Copy the /bin/ls binary to /home/ftp/bin directory and change the permission of the ls program to 0111. You don't want users to be able to modify the binaries:
[root@deep ] /# cp /bin/ls /home/ftp/bin [root@deep ] /# chmod 0111 /bin/ls /home/ftp/bin/ls
This step is necessary only if you're not using the --enable-ls option during the configure time of Wu-ftpd. See the Compile and Optimize section in this chapter for more information.
- Find the shared library dependencies of the ls Linux binary program:
[root@deep ] /# ldd /bin/ls
libc.so.6 => /lib/libc.so.6 (0x00125000) /lib/ld-linux.so.2 =7gt; /lib/ld-linux.so.2 (0x00110000)
- Copy the shared libraries identified above to your new lib directory under /home/ftp directory:
[root@deep ] /# cp /lib/libc.so.6 /home/ftp/lib/ [root@deep ] /# cp /lib/ld-linux.so.2 /home/ftp/lib/
These library are needed to make ls work. Also, steps 3 and 4 above are required only if you want to use the ls Linux binary program instead of the --enable-ls option that uses the new internal ls capability of Wu-ftpd.
- Create your /home/ftp/dev/null file:[root@deep ] /# mknod /home/ftp/dev/null c 1 3 [root@deep ] /# chmod 666 /home/ftp/dev/null
- Copy the group and passwd files in /home/ftp/etc directory. This should not be the same as your real ones. For this reason, we'll remove all non FTP users except for the super-user root in both of these files, passwd and group.
- [root@deep ] /# cp /etc/passwd /home/ftp/etc/ [root@deep ] /# cp /etc/group /home/ftp/etc/
- Edit the passwd file, vi /home/ftp/etc/passwd and delete all entries except for the super-user root and your allowed FTP users. It is very important that the passwd file in the chroot environment has entries like:root:x:0:0:root:/:/dev/null ftpadmin:x:502:502::/ftpadmin/:/dev/null
: We can notice two things here: first, the home directory for all users inside this modified passwd file are now changed to reflect the new chrooted FTP directory i.e. /home/ftp/./ftpadmin/ begins /ftpadmin/, and also, the name of the user's login shell for the root account has been changed to /dev/null.
- Edit the group file, vi /home/ftp/etc/group and delete all entries except for the super-user root and all your allowed FTP users. The group file should correspond to your normal group file:root:x:0:root ftpadmin:x:502:
- Now we must set passwd, and group files in the chroot jail directory immutable for better security.
- [root@deep ] /# cd /home/ftp/etc/ [root@deep ] /# chattr +i passwd
- Set the immutable bit on group file:[root@deep ] /# cd /home/ftp/etc/ [root@deep ] /# chattr +i group
The /etc/ftphosts file is used to define whether users are allowed to log in from certain hosts or whether there are denied access.
Configure the /etc/ftpusers file
- Create the ftphosts file, touch /etc/ftphosts and add for example in this file the following lines:# Example host access file # # Everything after a '#' is treated as comment, # empty lines are ignored allow ftpadmin 184.108.40.206 220.127.116.11 18.104.22.168 deny ftpadmin 22.214.171.124
In the example below, we allow the user ftpadmin to connect via FTP from the explicitly listed addresses 126.96.36.199 188.8.131.52 184.108.40.206, and deny the specified ftpadmin user to connect from the site 220.127.116.11.
- Now, change its default permission to be 600:[root@deep ] /# chmod 600 /etc/ftphosts
The /etc/ftpusers/ file specifies those users that are NOT allowed to connect to your FTP server.
Configure the /etc/pam.d/ftp file
- Create the ftpusers file, touch /etc/ftpusers and add in this file the following users for security reasons:root bin daemon adm lp sync shutdown halt mail news uucp operator games nobody
- Now, change its default permission to be 600:[root@deep ] /# chmod 600 /etc/ftpusers
Configure your /etc/pam.d/ftp file to use pam authentication by creating the /etc/pam.d/ftp file and add the following lines:#%PAM-1.0 auth required /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed auth required /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_shells.so account required /lib/security/pam_pwdb.so session required /lib/security/pam_pwdb.so
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017