This list will occasionally be updated with tips for securing insecure environments, some that can’t be secured using best practices. These solutions may fix certain Security issues, but keep in mind best practices work the best. Some of these fixes are also for situations that you weren’t even aware were secure (such as the common myth that Linux is secure by default)
Shared workstations and usernames
The best practice is that you should use separate usernames. And if a workstation is shared that the same username shouldn’t used to log a user in. Some organizations even use multi-factor authentication or keycards to provide non-repudiation. The reason being that in Security we need non-repudiation. An example is Alice and Bob share a workstation, and they use the same username/password to login. Let’s say we have to investigate who made a transaction from a workstation, that wasn’t accounted for. Alice will say Bob did it and Bob vice versa. This can be a common issue on counter and kiosk workstations. A solution is to rely on something else to provide non-repudiation. One solution is in the case where employees sign into another system like a database, where a unique username/password is used. This actually will solve the issue and provide non-repudiation. Keep in mind incident responders will have an extra step to take. Instead of just finding computer and logged in user. They will need to take the extra step of finding out, who was signed into the database from that machine during a certain time period.
Another solution is to use something like cameras. The cameras can be used to find out who was at a certain workstation during an investigation. The cameras work great in cases where one user could be signed in uniquely in the database, but other users are using their workstation temporarily.
Linux/Unix Business system allows passthrough authentication
There are a lot of these business systems that run over Unix and Linux that pass users in Linux/Unix to the database system hosted on the OS. Consultants that sell you these ERP or business systems, may tell you that you can fix this issue by adding /sbin/nologin or false in the etc password and shadow files. Thus preventing any shell access. Problem is this won’t fix all cases. Consultants may even lie saying that the users are only used to get into the business system. Numerous such systems I have analyzed, have actually allowed regular users to gain access to other areas of the Linux/Unix system. Meaning users aren’t just allowed to access the database system, they can get into other areas. You may even have cases where that etc password and shadow file needs to have a specific shell in there to get into the database. Also if the system has FTP by default those regular users will be able to FTP in, using that as an attack avenue. So to secure this you will need to make sure users are limited in other services they can access. I won’t go into all the details but services like FTP and SSH can have users or groups prevented from logging in.
The final fix should be to block who can Sudo and run as root. You don’t want regular users having this ability which is there by default. A Linux noob may say will if they sudo they still need to know root password, so I am safe. Problem is it makes it easier for privilege escalation exploits to work. A hacker running as a regular user, won’t be restricted from running sudo and potentially escalating privileges. /etc/sudoers can be used to limit Sudo access to certain groups. A popular group used is the wheel group, where specific users like root are added to. Keep in mind this won’t block all privilege escalation avenues. Red Hat has a great guide on how to do this https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/managing-sudo-access_configuring-basic-system-settings
You also have the su command that allows users to switch to other users. If your running a business system be it an ERP or whatever. You don’t really need regular users being able to switch to another user. To block this one can use something like PAM. Red Hat has a guide going over how to do that https://access.redhat.com/solutions/64860
Here I set su to only allow users in wheel group. On this particular business system there really was no need for regular users to switch to another user. Before they could switch to root user now they can’t switch to root. As seen below root switched to the user, but that user can’t su into any other user including itself.
Red Hat Cockpit access
By default Red Hat Linux has Cockpit which is like Server manager for Windows. This is accessible over port 9090. Now if your companies system is running over Linux and using RedHat. Guess what your regular users can use this to get in, then open a shell session in cockpit, and run sudo /bin/bash to run as root nuking your whole database system. Also this is a great example to show, why you should build a map of what a user can do on the system. Just because your business system runs on Linux, doesn’t mean users are only restricting to the GUI on your system. Are those users able to FTP in, how about get in to Cockpit web GUI?
This guide goes over how to block access to Cockpit https://access.redhat.com/solutions/5074601 As seen below I set auth requisite to only allow users in wheel admin group to get into Cockpit which has only admin users in that group.
