The File Transport Protocol, or FTP, is an older TCP protocol designed to transfer files over a network. Because all transactions with the server, including user authentication, are unencrypted, it is considered an insecure protocol and should be carefully configured.
vsftpd - A standalone, security oriented implementation of the FTP service.
Change the FTP Greeting Banner:
To change the greeting banner for vsftpd, add the following directive to the /etc/vsftpd/vsftpd.conf file:
ftpd_banner=[insert_greeting_here]
To simplify management of multiple banners, place all banners in a new directory called /etc/banners/.
To reference this greeting banner file for vsftpd, add the following directive to the /etc/vsftpd/vsftpd.conf file:
banner_file=/etc/banners/ftp.msg
Securing the Apache HTTP Server
The Apache HTTP Server is one of the most stable and secure services that ships with major Linux Server Distros.
Below is a few list of configuration options administrators should be careful using.
This directive is enabled by default, but may not be desirable. To prevent visitors from browsing files on the server, remove this directive.
This directive is enabled by default, be sure to use caution when creating symbolic links to the
document root of the Web server. For instance, it is a bad idea to provide a symbolic link to /.
The UserDir Directive
The UserDir directive is disabled by default because it can confirm the presence of a user account on the system. To enable user directory browsing on the server, use the following directives:
UserDir enabled UserDir disabled root
These directives activate user directory browsing for all user directories other than /root/. To add users to the list of disabled accounts, add a space delimited list of users on the UserDir disabled line.
Do Not Remove the IncludesNoExec Directive
Restrict Permissions for Executable Directories
Be certain to only assign write permissions to the root user for any directory containing scripts or CGIs. This can be accomplished by typing the following commands:
chown root[directory_name] chmod 755 [directory_name]
Why we should not use the no_root_squash Option
By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account.
In this way, all root-created files are owned by nfsnobody, which prevents uploading of programs with the setuid bit set.
no_root_squash - Allows root users on client computers to have root access on the server. Mount requests for root are not be mounted to the anonomous user. This option is needed for diskless clients.
root_squash - Requests from root clients are mapped to the nobody user and group ID so they will only have file privileges associated with other.
ro - read only access
rw - read write access
If no_root_squash is used, remote root users are able to change any file on the shared file system and leave trojaned applications for other users to inadvertently execute.
Common NFS Syntax Errors
The NFS server determines which file systems to export and which hosts to export these direct-
ories to via the /etc/exports file.
Be careful not to add extraneous spaces when editing this file.
For instance, the following line in the /etc/exports file shares the directory /tmp/nfs/ to the host serverbuddies.example.com with read/write permissions.
/tmp/nfs/ serverbuddies.example.com(rw)
This line in the /etc/exports file, on the other hand, shares the same directory to the host serverbuddies.example.com with read-only permissions and shares it to the world with read/write permis-sions due to a single space character after the hostname.
/tmp/nfs/ serverbuddies.example.com (rw)
It is good practice to check any configured NFS shares by using the showmount command to verify what is being shared:
SSh key passphrase and SSH Agent
It is recommended to protect the keys with a passphrase. it is straightforward to do so. In fact you will be asked to provide a passphrase to your private key during key generation and you can skip it if you want. In case you did skip it you can lock it again with a passphrase using the following.
Then it will prompt to put the key file path and you should enter then the password which must be more than five chrs.
Of course using keys is not only useful for security reasons, but also for not asking for password every time you use ssh. But thanks to ssh-agent we could save ourselves a few keystrokes, and more importantly use ssh in automated scripts without interrupting the script to prompt for passwords.
SSH Agent
$ eval `ssh-agent`
$ ssh-add /home/buddies/.ssh/buddies_rsa
$ ssh root@myremote.serverbuddies.com
We first ran the ssh agent, which is actually a service.
Then use ssh-add to add the key, then ssh the remote server with only the user name and the remote server address, without providing the key, and if you have protected the key with passphrase you will be asked for the passphrase when you add it.
The ssh-agent help in opening a session so we can use ssh to access remote server without giving any keys or password.
