Secure File Storage Server
First World Bank Savings and Loan has a need to deliver highly confidential customer data in PDF format for online customers. This can be done by uploading data to a Linux file server by bank employees within the LAN. This however is inaccessible for customers. First World Bank Savings and Loan has created a plan to make a secure web server so clients can access the data. In order to do this, we will set up a separate Linux virtual machine that will be running SFTP service that only works with a SSH connection. In order to connect with a SSH connection, users have to pre-authenticate through the web server and traffic needs to be forwarded from that web server to the SFTP server. The SFTP server will then take off the SSH “shell” and be able to read the SFTP traffic. In order to do this, we will implement MySecureShell software that will be installed on an Ubuntu release server. According to http://xmodulo.com/, MySecureShell is an OpenSSH server system that:
•Limit per-connection download/upload bandwidth
•Limit the number of concurrent connections per account
•Hide file and directory owner/group/rights
•Hide files and directories which user has no access to
•Limit the life time of a connection
•Chroot SFTP user into his/her home directory
Secure Web and Database Servers

Based on what is being asked I am recommending a database and Web server architecture along with this there will be explanations as to how they are secure and stable. It is important to have both a web server and database on a banks network in order to be able to do what is being required. A key part of having a web server and database server is how we choose to implement them. this can be done many ways but we will need to explore our options to ensure we chose the correct option, the reason for this being if the implementation process is not done correctly our network and information may be vulnerable.
We chose to go with Apache HTTP Server, looking at Apache HTTP server here is some background information on it. It was a project to develop and maintain an open- source HTTP server for modern operation systems. These systems include Unix and Windows NT. Apache HTTP web server is the most popular open source web server available being used at 60% over all other web servers. We chose to go with MySQL for our database server primarily for security reasons and because of the ability to expand our business in the future. Due to the fact that we are a bank and deal with very sensitive information we will be taking many precautions to ensure that our servers are protected. So first we want to ensure that we separate the web server from the database server and have them on two different physical servers. With this being said the web server will have to authenticate with the database server. MySQL can be protected with password verification, this way if the web server is compromised they cannot touch the database server and if the physical database server is compromised they cannot reach MySQL. These will be some of the steps taken to secure the database server. When it comes to protecting our web server you will want to remove all unnecessary plugins and update CMS, you will also want to ensure that apache is not running as root. You want to make sure you want to remove any network services that will not be used on the web server like print services along with RAS.
Now we have to make sure we select a secure way to have administrators be able to remote access the servers. We must ensure that remote access is secured properly, this can be obtained by using encryption protocols and tunneling. You can also use security tokens paired with single sign on. This should be restricted to a limited amount of accounts.

Provide Layered Security
Layer One: Firewall Configuration In order to configure the firewall settings for the web server, iptables will be used. This will allow a configuration that greatly controls what type of traffic can enter the web server. The rules of the iptables configuration for acceptance and rejection will be as follows:

-A FWBSL-Firewall-1-INPUT –m state --state NEW –m tcp –p tcp --dport 22 –j ACCEPT -A FWBSL-Firewall-1-INPUT –m state --state NEW –m tcp –p tcp –dport 443 –j ACCEPT
-A FWBSL-Firewall-1-INPUT –j REJECT --reject-with icmp-host-prohibited

These inputs will allow for SSH traffic (for approved administrators to access the web server over the internet) and HTTPS (Hypertext Transfer Protocol over TLS/SSL). All other traffic will be rejected.

Layer Two: TCP Wrappers TCP wrappers will be employed to “wrap” any services and filter them through the protection employed in the /etc/hosts.allow and /etc/hosts.deny files. It is important to note that the allow file is checked before the deny file. Initial configuration of these files will include placing more restrictive rules in the /etc/hosts.deny file first. This will deny all access to TCP Wrapper protected services that is not specified in the allow file. The allow file will feature additions that explicitly allow certain users (such as the web server administrator) access to the services they will need. Services that should be configured for use with TCP Wrappers can be found in the /etc/inetd.conf and /etc/xinetd.conf files. Certain services must be explicitely added to TCP Wrappers such as SSH by using the ldd command (such as ldd /usr/sbin/sshd). This particular command will be used for layered security of SSH. The layered security that TCP Wrappers provides can also be used to deny specific IP addresses, users, or domains. Any known malicious domains will be added to /etc/hosts.deny. Furthermore, the /etc/hosts.allow file should be configured with exceptions to allowed subnets by specific IP address by using the EXCEPT command.

Layer Three: SELinux SELinux only supplies a security layer if it is turned on. To enable SELinux (after the initial server configuration, since SELinux could causes problems with installation). To turn on SELinux, the /etc/selinux/config file must be accessed and SELinux must be set to Enforced. Once SELinux is turned on, it can be configured just as other security measures. Best practices state that initial configuration should begin with a denial of all actions. From that point users, applications, and services can be allowed to function within desired parameters by being allowed access to necessary configuration files and program libraries. For the web server, the web administrator will be given specific access to configuration files which are necessary and users placed in the customer database will be given access to their specific data. All other access should be restricted by SELinux.

Conclusion: With these three layers in place, the web server for First World Bank Savings and Loan will have maximum protection against unauthorized users. In case of a breach in one layer, another layer should act as a stop-gap. An example of this would be if someone found a way to use port 23 to create an SSH connection in, TCP Wrappers would then check their username against the /etc/hosts.allow and /etc/hosts.deny lists (since SSH is set up to use TCP Wrappers) to determine if that user can continue. Even if the person find their way onto the allow list, they will then be checked by SELinux whenever trying to perform an action with a configuration file or program library to see if they’re approved to commit such an action. With all of these layers combined, security has become much more robust.