Blog 16 – Security

There were two more security aspects that I wanted to explore.

1 – Security Group Rules

The first being the security groups that allow access to the Web Server and MySQL database. At the moment I have added inbound IP address, to the AWS security group, for the locations that I am working at. This is for access to the web servers SSH and HTTP connections. For the MySQL server I just set it to accept traffic from anywhere to make it easier when connecting to it to configure and the so the Webserver can call it as well.

19-10 Inbound Rules.PNG

Now that I have some data in the database allowing the MySQL server access from anywhere is not best practise, as anyone can attempt to connect to it. Therefore I need add access restrictions. For this I am going to remove the accept all traffic condition and add the address of the Webserver as when the system is operating no other inbound access rules are needed. I will also add my personal IP address so that if I need to configure it I can connect using MySQL workbench. I can remove and add the address that I am connecting from at anytime by logging into the AWS console and changing the inbound rules.

To find the IP address of the Webserver, I went to it’s dashboard. I needed its private IP address. This is an internal IP address used by the server.

28-10 Private IP.PNG

I then went to the security group section and added a new security group for the database. Before I had both the web server the database in the same security group. This meant that some rules that I could apply might apply to both. I decided to separate them so I have better control over their access rules. I then went to the security group settings and added the IP address to the inbound rules. This means the server will be the only one that can access the database. I did add my local public IP address as I still need to connect and configure the database. I repeated this for the outbound rules too.

28-10-new-sg28-10-new-sg-out-bound
This means the the database can only receive execute procedure calls from the web server and can only send information back to the web server. If someone wanted to try connect to the database they would need to create a server with the same internal IP address, which is virtually impossible, as the internal IP address are allocated by AWS.

For added security when I’ve finished the project I can turn off the publicly accessible option on the database. This means that only internal connections, like the web server can access the database.

For the web servers IP inbound rules I kept them the same. I added the same rules to the outbound rules. I also included the security group of the Database in both inbound and outbound rules. This allows the web server to contact the database to perform queries. In a future blog I am going to go over enabling HTTPS on the web server. When I have done this I will set a rule that allows HTTPS access from anywhere. This means that anyone that wants to access the website can only do it over a secure connection. I will then remove the HTTP rules as they are no longer needed.

28-10 Outbound rules webserver.PNG

2 – MySQL Accounts

The second security aspect that I wanted to include was creating MySQL accounts for certain users. As I briefly discussed in Blog 11 – Procedures when you create procedures you can have users that only have access to execute procedures.
When I started creating the website I used the Admin account when connecting the website to the database. This was so that I could test different queries if I encountered a problem. But now that the website is up and functioning I can move to connection user account that have limited access. I went into MySQL workbench and using the database configuration tools made a new user with only execute permissions.

19-10-mysql-new-account

For the user login details I made sure that the password was long and included both capitals, lowercase, and special characters. The login name represented the accounts use.

19-10-connection-limits

Although the above limits that I have set on connections are very high, they are still a restriction. I based these connection limits off what could be the highest use case scenario. However if the server was attacked this will provide some limit.

19-10-no-admin-privilages

I made sure that the user had no admin privileges at all.

19-10-schema-rights

I added the project’s Schema as the only Schema that the user can access. They don’t need access to any others that may be on the MySQL server. In this screenshot I selected both SELECT and EXECUTE privileges. I have since removed the SELECT privilege as it isn’t needed anymore. All interaction by the website are done through procedures now, therefore only EXECUTE is needed.

19-10-connection-denied

I also tested to make sure the account worked correctly. I went and tried to perform an UPDATE query on the schema and it was denied. This confirmed that the user account worked. You can also see that the Schema for the project is the only one shown. I have other schema yet they don’t show as the user doesn’t have permission to access them.

Advertisements

One thought on “Blog 16 – Security

  1. Pingback: Blog 17 -SSL (HTTPS) turned on | Digital Insaniti

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s