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.
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
