CHECKING LINUX SECURITY AND INTEGRITY VIA THE TERMINAL

We all know about the speed and efficiency of Linux, the security is unmatched as well. Linux is by far more secure than Windows and Mac as the Open Source community behind Linux is always eyeballing the code and subsequently fixing bugs thereafter. Linux and Unix are about as secure and as efficient as running a computer operating system gets, but there are some issues and bugs that don’t always get fixed or noticed in a timely fashion and one of the jobs of a System Administrator would be to check for these issues to make sure they’re not a problem in a business environment. SSH is a big gap in security that gets updated frequently, however, there is nothing that can be done to prevent it from being an inherent security risk as it is facing the internet and is a hole with which data travels through from device to device. Businesses and administrators use SSH to tunnel through from their devices to effect changes in files on other machines remotely and this, along with Telnet(which is scarcely even used anymore), are just a couple of the entry points for potential attackers to get into your system.

Another possible vector is with accounts. If a user gets too much privilege(or not enough as the case might be), he/she can potentially gain root access to a system and compromise security without intending to do so. Installation of software is one such vector where users can effect significant damage or change on a device. One of the jobs of System Administrators is to always know who and what has accessed the machine, both locally and remotely on a day to day basis. Logging is a great way to check for security events, but preventing many of these open vectors in the first place is the best way to ensure protection of client data. Users and groups are areas of restriction to where users are generally granted base level privileges and so can only effect software for which rights have been specifically given to them. You wouldn’t want a mere user in accounting to effect change in company blueprints or files only accessed by the CEO or director of a job. As an administrator, you wouldn’t want your boss mucking around with files that he or she has hired people to deal with, thus leaving him/her no business to do so. Installing software should also be an administrative effort.

Another possible problem with User permissions is that the user simply doesn’t have the permissions required to access files granted to him/her via the Administrator’s office. Not granting sufficient privilege to a staff member is like telling someone to hammer a nail with their bare hands. Within Linux, users are usually started with an ID number around 1,000. This number increases by one each new user that is added or created. Users that are warranted unlimited or root access are added to the wheel and thus can install software or move files anywhere they might like, however, unlike in Windows, this can be more appropriately controlled from within Linux. In most distributions of Linux, there are ways to give user access only to the basic software such as browsers, etc. This can be done both graphically and from a CLI perspective. Alternatively, in Linux, you can give some software very specific permissions by using the CHOWN(Change Ownership) command. I will write a more in-depth article on permissions and user accounts later.

There are many other possible places that can be exploited that may not be covered here, however, these checks can be done safely from the command line interface. They are generally safe to use, however, keeping backups is another good idea to prevent data loss and or corruption and this step should be taken first before running any of these command checks.

1. sudo awk -F: '($3 == "0") {print}' /etc/passwd >> removethese.txt Ensures that the root user is the only one with the proper clearance and user id. If another user gained this id or root access, they could reak havoc on an otherwise safe system. This is mostly to deal with local user access and less to do with remote attacks. Still useful if you’re not the only one with access.
2. find /dir -xdev \( -nouser -o -nogroup \) -print >> noowner.txt When removing user accounts from systems, sometimes files may get left behind which have no owner. If this happens, it’s a nice idea to remove them so nothing gets misplaced or unaccounted for.
3. find dir -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print >> worldowned.txt Files that could potentially be owned by root, but may have open read and write access to all users.
4. ssh -G 2>&1 | grep -e illegal -e unknown -e Gg > /dev/null && echo "System clean" || echo "System infected" This searches for abnormalities within SSH and discloses a possible flaw or infection with SSH which allows possible “illegal” parameters to be utilized by SSH. A clean(proper ssh package) system would never run these.
5. netstat -nap | grep "@/proc/udevd" This checks for possible Ebury rootkits dealing with SSH. A rootkit is a piece of software that sits in a kernel and listens to or makes connections within the system's network to download more payloads from the net or send statistics and telemetry back home.

The above commands can help you to keep an eye on your system for changes. Of course, you can always install Tiger or the old Tripwire package to get email alerts of any form of change that comes to your OS, but these can be rather complex to set up. Taking notice of the output of these commands can help reduce attack vectors on your Linux machine and keep unwarranted noise to a minimum. It’s also really imperative to use a firewall when dealing with services such as SSH and Telnet. Even using email applications and utilizing the older ftp protocol can open ports to the outside so beware.