Don't blow off another's candle for it won't make yours shine brighter.

It has been almost a month now since I brought to life a Decent Witness node. After much discussion and motivation from @tjpezlo, we finally executed the first phase of The Plan - a plan to make a world a better place for you and for me and the entire human race (nah! pfft! we just want to make an app for the Decent Network).

This is the first part of the Maintenance Series which aims to guide readers and like minded individuals who want to setup their own Decent Witness Node. Part 1 of this series is not specific to the Witness node, rather this will guide you through some general maintenance tasks of running a server in general.

Server Status

To begin with, let us connect to our server through ssh ( shell access) and check storage spaces
by using the two commands:
$ ssh decent
$ df -H
The first command creates a shell access to the remote server, I have used an alias here which can be configured at ~.ssh/config, this is a shortcut to using <user@server-address>.

Once logged in to the server df -H command shows the status of storage spaces on the server. As we can see, since I started running this node, the decent blockchain is taking up around ~22GB of my SSD. Now, I want to see how the server is taking up its load. To do this we issue the top command which shows the screen below.

The load average is showing almost at ~0.00 which means the server is taking a stroll in the park. Only decentd is taking much of the server's processing power and memory. Although I am not yet an active witness (so please vote for me ), the role of the decent daemon (decentd) is to broadcast transactions, download blocks, and optionally sign them.

Witness Status

Now, let's check how my witness is doing. First, I need to run the cli_wallet which by default is connecting to the local node. The cli_wallet is the interface connecting us to the DECENT Network. It's responsible for creating accounts, broadcasting transactions, signing transactions, account retrieval etc. If you want to know further uses of the cli_wallet see here. As of this writing I gathered around 4.8 TV (teravotes) and very hopeful that the community will help me and vote for me to be an active witness.

Now unto the good stuff...

Basic Security Audit

This part of the Maintenance Series will briefly tackle the most basic but nonetheless important techniques/tips on securing your server.

• Background processes and cron jobs

A common way of an attacker to maintain access to a compromised server is to hide and run a backdoor and add it as a cron job.

A cron job is a Linux utility used for scheduling a task to be executed in the specific time according to its schedule at designated time. (source)

To inspect your cron jobs use the command:
crontab –l - this will show the list of cron jobs running under the current user
crontab -l <username> - will show the list of cron jobs run by a specific user

To check the current running tasks/processes use this command:
ps ax - this will show you the list of processes, it's id and the user running it.

For both inspections, one thing to watch out for is an unrecognized user or process. An active backdoor normally hides on system directories and have access rights similar to the root (admin) user.

• Network Connections

Below an audit of my server to check incoming and outgoing network connections. The mostly redacted column is my server's ip address and opposite to it is the external ip address that have established a TCP connection. The rightmost column is the process id and the process name responsible for the connection. Now we can see decentd is the only process creating these connections and we know that this is the decent daemon running which is as expected. I was also logged in through ssh hence, the connection on port 22. If you suspect an active backdoor process based from the previous inspections (cron and background process) it will show up in here.

• SSH / auth logs

Now here comes the interesting part!

Brute force attack is one of the most common attack against servers. This is the endless attempt to guess the username/password combination to gain access to the server. To filter out the possible brute-force attack issue the following command on the terminal:
grep sshd.\*Failed /var/log/auth.log - this will search the auth.log file for "Failed" login attempts as shown in the photo above. Interesting enough, my server has been subject to these attacks. In the next posts I will show you how to harden a server to prevent these attacks.

For now, Good luck to these script kiddies, I could be running a honeypot somewhere right? Bring it on!

But just out of interest as Sun Tzu's Art of War, let us know our enemy.
With the help of my geoip server I was able to query some of these ip addresses:

1. {"ip":"121.18.238.119",
   "country_code":"CN",
   "country_name":"China",
   "region_code":"13",
   "region_name":"Hebei",
   "city":"Hebei",
   "zip_code":"",
   "time_zone":"Asia/Shanghai"
   ,"latitude":39.8897,"longitude":115.275,
   "metro_code":0}

2. {"ip":"109.201.152.8",
   "country_code":"NL",
   "country_name":"Netherlands",
   "region_code":"GE",
   "region_name":"Provincie Gelderland",
   "city":"Rozendaal",
   "zip_code":"6891",
   "time_zone":"Europe/Amsterdam",
   "latitude":52.0074,
   "longitude":5.9654,
   "metro_code":0}

3. {"ip":"200.77.190.120",
   "country_code":"EC",
   "country_name":"Ecuador",
   "region_code":"P",
   "region_name":"Provincia de Pichincha",
   "city":"Quito",
   "zip_code":"",
   "time_zone":"America/Guayaquil",
   "latitude":-0.2167,
   "longitude":-78.5,
   "metro_code":0}

4. {"ip":"59.45.175.11",
   "country_code":"CN",
   "country_name":"China",
   "region_code":"21",
   "region_name":"Liaoning",
   "city":"Shenyang",
   "zip_code":"",
   "time_zone":"Asia/Shanghai",
   "latitude":41.7922,
   "longitude":123.4328,
   "metro_code":0}

5. {"ip":"190.48.139.176",
   "country_code":"AR",
   "country_name":"Argentina",
   "region_code":"C",
   "region_name":"Buenos Aires F.D.",
   "city":"Buenos Aires",
   "zip_code":"34034",
   "time_zone":"America/Argentina/Buenos_Aires",
   "latitude":-34.6033,
   "longitude":-58.3816,
   "metro_code":0}

I can see i'm quite popular and this is just the last few lines of the logs.

• Other log files

1. /var/log/syslog - shows system operations, root access, cron jobs, system info/debug logs
2. /var/log/ufw.log - if you are using and have installed Uncomplicated Firewall, this log file shows the blocked traffic

Moving Forward

For the next part of this Maintenance Series, I will tackle some of the most complicated attack vectors which could compromise your servers. Mitigations and prevention techniques will also be discussed with case studies particularly focusing on my Decent Witness Node. I will also discuss the concept of Offensive Security.

In these posts I aim to share my experience and offer a guide to people who might find this useful in maintaining their own servers. If you have comments, suggestions and reactions just comment below and let me know your thoughts. If you think this post is helpful upvote or resteem so anyone who needs it, will find it.

---

Random Thoughts to Ponder:

I code with purpose. I am @precise.