And you can get it here: blm849/supersimplehardening: A super simple way to harden your server.
I create a lot of Ubuntu test servers, and I find that as soon as I create a Ubuntu server on a cloud environment, it gets immediately attacked by automated software. This is obviously a concern. A bigger concern is that when I went searching for recommendations on how to harden such a server, I found a wide variety of recommendations! It can be hard to know what to do. Still, I needed something. As a result, I created this package of scripts. The scripts do a number of things:
- prevent direct root login to your server via ssh. This was one of the things I saw consistently happen and once someone cracks the root access on your machine, it’s game over.
- stop some basic security holes, like IP spoofing
- download some useful software, like logwatch, ufw and others
- upgrade all software on the server
This is just a very very limited number of things to prevent attacks. But it is better than nothing.
If you install Apache, PHP, MySQL or other software on your machine, there are even more attacks that will be launched against it. I recommend you get a firewall up and running and at least run logwatch on a regular basis to look for potential attacks being launched against you.
Finally, if it is important for you to secure your server, don’t stop with my scripts. Go out and consult with IT security specialists right away.
The following webpage has detailed instructions for installing and configuring SonarQube on a RHEL/CentOS 7 Linux server (real or virtual) and it was one of the best guides I’ve seen (and I’ve reviewed half a dozen):
The webpage outlines how to update your Linux server, how to install MySQL (as a data repository) on it, and how to then install SonarQube software on the server.
Some things to note. First, this procedures has you using wget to get v6.0 of SonarQube:
Check out the page https://www.sonarqube.org/downloads/ and see the latest version of SonarQube (e.g. 6.4) and replace “sonarqube-6.0.zip” with the latest version (e.g. “sonarqub-6.4.zip”.)
One important thing to note: this procedure creates a userid and database called sonarqube.
Later in the process, the changes made to /opt/sonarqube/conf/sonar.properties needs to match this:
If the userid, password and database you created in MySQL do not match what it is the sonar.properties file, you will see cannot connect to the database errors in the /opt/sonarqube/logs/web.log file and SonarQube will not come up.
Once you enter: sudo ./sonar.sh start
Get the IP address of the SonarQube server and then go to a browser and enter:
I just cleaned up an environment I had set up in Amazon years ago for a client. (The client wanted to use Amazon, so we did.) In doing so, I wanted to make sure I didn’t leave anything behind which would cause me to continue getting billed even though I was no longer actively using EC2. I believe that the following checklist was useful in insuring this.
My EC2 cleanup checkist:
- Delete my Elastic IPs
- Terminated instances – running and non-running (I did this before deleting volumes, since it deleted alot of them for me)
- Delete remaining volumes
- Delete my security groups ( 1 will be left – the default one)
- Deregister AMIs
- Delete snapshots (you need to deregister your AMIs before you do this)
- Check your account balance
- In a few days, check your account balance to see if there are any charges you haven’t accounted for
After following this checklist, my EC2 environment was cleaned up. Depending on how you are using EC2, you may have more things to delete. Checking your account balance will help there: if you left things behind, they may incur charges. An increase in your account balance will help flush them out.
One thing to consider: you may delete something, but it doesn’t show in admin console. If that is the case, logout and then in. I did that when I was having trouble deregistering my AMIs. I logged out and then in and when I checked them, they were now deregistered.