Security 101: Account Security - Account Types & Guidelines

in #security7 years ago

In this part we will examine user account types, and we'll see a few guidelines and methods we can use to protect our system a little bit by enforcing strong passwords etc.


Previous parts:

1. Introduction
2. General Principles and Guidelines
3. Physical Security: Intro
4. Physical Security: Single User Mode
5. Physical Security: Securing your Bootloader
6. Physical Security: Disk Encryption I
7. Physical Security: Disk Encryption II
8. Physical Security: Control+Alt+Delete & Wrapping it up
9. Account Security: PAM!


Root

The most powerful account on Linux is the root user. It is what we call a superuser, and has power to do anything on the system. You can't hide files or disable access to a folder from this user. He has unlimited access to the system, only limited by knowledge and... Google searching skills.

This user has also access to install/remove software, change network interface settings, create/edit/remove/disable user accounts.. Anything you can think of, this account has access to do it.

The root account always has UID (= user id) 0. The account name is not taken into account in the system. The UID is being used when executing something. Why is this important? Well, if you change another account's UID to 0, this account will become a superuser.

All accounts not using UID 0, are "normal" or "standard" accounts.

System Accounts

To better organise the system and for easier administration, accounts for system services, have a UID between 1 and 999. You can change that number in /etc/login.defs.

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN                  1000
UID_MAX                 60000
# System accounts
#SYS_UID_MIN              100
#SYS_UID_MAX              999

This is the default UID account selection on Ubuntu 16.04!

If you want to create a system account, you just have to specify the -r flag: useradd -r steemit_witness_dimitrisp

Failure to do so, the account will receive a normal UID. Keep in mind that system or no system UID, there is no difference for the operating system. For example UID 999 is a System account and UID 1000 is a Standard account. It is simply used for easier administration, as it is quicker to determine if an account is a Standard account, used by a human, or a System account, used by an application/service.

There is however a huge difference between UID 0 and UID 1!

Security Measures for All account types

Enforce strong passwords

Do not just hope that your users will use strong passwords, this won't happen anytime soon, unless you have security experts that love their extra complicated passwords, and you will end up with a user using this password and a huge headache as it increases the odds of an attacker breaking into your system. A bruteforce attack (where a software will keep trying all combinations of passwords in succession) or a Dictionary attack (where the most common passwords are used) can be used to hack into your system quickly. These are the top common passwords:

1   password    5f4dcc3b5aa765d61d8327deb882cf99    8   8   0   0   check
2   123456  e10adc3949ba59abbe56e057f20f883e    6   0   0   6   check
3   12345678    25d55ad283aa400af464c76d713c07ad    8   0   0   8   check
4   1234    81dc9bdb52d04dc20036dbd8313ed055    4   0   0   4   check
5   qwerty  d8578edf8458ce06fbc5bb76a58c5ca4    6   6   0   0   check
6   12345   827ccb0eea8a706c4c34a16891f84e7b    5   0   0   5   check
7   dragon  8621ffdbc5698829397d97767ac13db3    6   6   0   0   check
8   pussy   acc6f2779b808637d04c71e3d8360eeb    5   5   0   0   check
9   baseball    276f8db0b86edaa7fc805516c852c889    8   8   0   0   check
10  football    37b4e2d82900d5e94b8da524fbeb33c0    8   8   0   0   check

Source: PasswordRandom

To enforce strong passwords, you can use PAM's pam_pwquality module. If you are on an older system and can't find pam_pwquality, look up for pam_cracklib (the predecessor of pwquality).

The configuration of pam_pwquality can be edited at /etc/security/pwquality.conf. By default though, it's empty or non-existant.

Here's a PAM configuration example if you want to use it right away: password requisite pam_pwquality.so

You can find a list of the attributes used by pam_pwquality by reading its man page: man pam_pwquality.

Use shadow passwords

By default, passwords were being saved in /etc/passwd, encrypted or hashed. A line in /etc/passwd looked like that: dimitrisp:$6$ai3.usSAc4W:1000:1000:Dimitrisp,,,:/home/dimitrisp:/bin/bash. The first field (fields are seperated by :) is the username, the second is the password, the third is the UID, fourth is the GID etc. The downside is that the file needs to be readable by all users in the system so programs can convert Usernames to UIDs and vice-verca. This meant that anyone could read the hashed password, and use a bruteforce attack to find it.

With shadow passwords, the /etc/passwd is changed to x instead of a password (dimitrisp:x:1000:1000:Dimitrisp,,,:/home/dimitrisp:/bin/bash), and the actual password is on /etc/shadow (dimitrisp:$$6$ai3.usSAc4W:17392:0:99999:7:::) that is only readable by root user, reducing the risk of bruteforce attacks.

You can use pwconv to convert passwords to shadow passwords, on any system not using shadow passwords. To reverse this, you can use pwunconv.

/etc/shadow holds various different fields. I will use the example above (dimitrisp:$$6$ai3.usSAc4W:17392:0:99999:7:::) to explain them.

First field is the username (dimitrisp)
Second field is the hashed password ($$6$ai3.usSAc4W)
Third field are the days since Epoch time of last password change (17392)
Fourth field is days until password change is allowed (0)
Fifth field is days before password change is required (99999)
Sixth field is the days to notify the user before password expiration (7)
Seventh field is the days before account becomes inactive (not used in example)
Eigthth field is the days since epoch when account expires (not used in example)
Ninth field is used to determine if account is reserved (not used in example)

Account expiration and other details.

To view the account expiration info, you can use chage

[email protected]:~$ chage -l dimitrisp
Last password change                                    : Aug 19, 2017
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

The chage can be used to change the configuration for a specific account. For more specific information on chage you can read man chage.

A few quick examples:

  • Make user dimitrisp change his password every 30 days: chage -M 30 dimitrisp (-M switch followed by the number of days)
  • Make user's forwitness account expire: chage -E 17392 forwitness (-E followed by number of days since epoch)
  • alternative date method: chage -E 2017-08-19 forwitness
  • to reactivate an expired account: chage -E -1 forwitness
  • Force user onsteemit change his password on the next login: chage -d 0 onsteemit (-d followed by 0. This normally sets the last day a user's password changed).

You can combine 2 or more switches. Like I said before, read man chage for more information and all the switches!

If you want to change the defaults for all users, you just have to edit /etc/login.defs. Just look for those lines:

PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_WARN_AGE   7

These are the default on Ubuntu 16.04.

Keep a history of passwords

You can force users to not use the same passwords over and over again. You can use the pam_pwhistory.so module, that will keep a history of the 10 last passwords used by each account on your system.

password required pam_pwhistory.so

To change the amount of remembered passwords, append remember=N to the above line, and change the N to the number of passwords you want to remember.


Thank you for reading, leave your thoughts below and, of course, don't forget to upvote!

Main image source: SophosNews


Also, I am running a witness server.

Please consider voting me, dimitrisp, for a witness if you find what I post & do helpful and add value to the network

You can read my witness declaration here

Sort:  

A great example of a technical post on steemit. With referenced image below. These recommendations are close to best security practises and should be read by users running a witness.

So many linux servers ive seen these settings being left default with the best root passwords set.

Congratulations! This post has been upvoted from the communal account, @minnowsupport, by dimitrisp from the Minnow Support Project. It's a witness project run by aggroed, ausbitbank, teamsteem, theprophet0, someguy123, neoxian, followbtcnews/crimsonclad, and netuoso. The goal is to help Steemit grow by supporting Minnows and creating a social network. Please find us in the Peace, Abundance, and Liberty Network (PALnet) Discord Channel. It's a completely public and open space to all members of the Steemit community who voluntarily choose to be there.

So interesting.

I flagged your comment because:

  • I don't like beggers coming to my posts to say "upvote my posts" or "follow me, I'll follow you". Not enough for me to flag a comment, but
  • You also added a link to your post that is not even remotely related to my post (that's a reason to flag)
  • Last but not least, your post is not even yours. Seaching in Google for the text in your post, I found this. You didn't even try to hide the fact you plagiarised someone else's work.

More people should react this way. There's just too much spam and plagiarism going on atm.

I like your post by the way. Keep doing what you do!

Coin Marketplace

STEEM 0.28
TRX 0.11
JST 0.031
BTC 68498.38
ETH 3905.59
USDT 1.00
SBD 3.66