Verify current active and inactive users on it-vm machine and lab server

carlosparadis commented 7 years ago

Inactive users should have their keys expired.

USER COMMANDS

- useradd   <-- by default, user belongs to their own private group
    - "useradd -m <name>"  <-- creates user and home directory  
    - "useradd -m -g <group_name> <name>"
        - '-g' sets primary group
        - '-G' sets decondary group
    - "useradd -N -m <name>" <-- creates user, and overwrites group to be default
- userdel (BE VERY CAREFUL...)
    - "userdel <name>"
    - "userdel -r <name>" <-- deletes home directory as well 
- usermod
    - "usermod <name> -c <"comment">"
    - "usermod -G <group_name> <name" <-- adds existing user to secondary group
            - "usermod -p <name>" DOES NOT ENCRYPT PASSWORD AND ITS EXPOSED IN /etc/shadow SO USE PASSWD COMMAND INSTEAD

USER LOCATIONS

- /etc/passwd     <-- typically does not contain user passwords
    - 7 fields
        1. login name
        2. optional encrypted password or "x"
        3. numerical UID   <-- user id
        4. numerical GID   <-- group id
        5. user name or comment
        6. user home directory
        7. optional command interpreter

    - for help enter command "man 5 passwd"

- /etc/shadow    <-- contains encrypted passwords
    - 8 fields
        1. login name
        2. encrypted password (if starts with !, account is locked)
            - begining values specify encryption used (ie. $6 means sha512)
        3. date of last password change
        4. minimum password age
        5. maximum password age (if you want users to frequently change pw)
        6. password warning period (warning before passwords expire)
        7. password inactivity 
        8. account expiry date

    - for help enter command "man 5 shadow"

- /passwd
- /etc/login.defs

- SOME COMMANDS
    - pwconv   <-- move passwords from passwd to shadow
    - pwunconv <-- move passwords from shadow to passwd
    - passwd   <-- change password 
        - "passwd <name>"     <-- changes password
        - "passwd -l <name>"  <-- will lock the account
        - "passwod -u <name>" <-- unlock account 
        - "passwd -e <name>"  <-- force new password at login

    - useradd -D   <-- see defaults

GROUP COMMANDS

- groupadd  
    - "groupadd <group_name" <-- adds new group
- groupdel
- groupmod
- gpasswd
    - "gpasswd -M <name,name..> <group_name>" <--sets the members of a group
    - "gpasswd <group_name>"  <-- lets you set the group password for the group
- newgrp  <-- log in to a new group
    - "newgrp <group_name>"  <-- will log you in to that group, use "id" to verify 
        - only for the session, you are not a permanent member
        - this is good for picking up group permissions temporarily 
        - type "exit" to exit out of interactive shell

- Private Group Notes
    - if enabled users will beolong to a group with the same name as the user
        when they are added
    - if disabled users will belong to the groups users specified in /etc/default/useradd
    - "useradd -N <name>" to overwrite private group
    - enable tr disable private groups by editing 'USERGROUPS_ENAB' in /etc/login.defs

- Primary Group is used as the group owner when creating a file. 
- Secondary groups are more traditional groups and we can access resources that we 
    have rights to through any of our secondary GIDS

- Find out who belongs to what group: "grep <group_name> /etc/group" or 
    "grep <group_name> /etc/gshadow"

GROUP LOCATIONS

- /etc/group
    - 4 fields
        1. group name
        2. password
        3. numerical GID
        4. user list, comma separated

    - for help enter command "man 5 group"

- /etc/gshadow
    - 4 fields
        1. group name
        2. encrypted password (* means no password for group yet)
        3. admin list, comma separated (-A with gpasswd to manage admins)
        4. members (-M with gpasswd to manage member passwds)

    - for help enter command "man 5 gshadow"

- /gpasswd

MISC COMMANDS

- id: this will display your user info in terminal

carlosparadis commented 7 years ago

@ryantanaka don't forget to add here commands to manage users. Most of those are add/delete etc.

ryantanaka commented 7 years ago

update on topics mentioned in our 10/12 conference call

figure out what users we have

You can use the following command to view what users we currently have on the server: cat /etc/passwd

To make this a little more readable, you can run the following command: cat /etc/passwd | cut -d: -f1

cat /etc/passwod will print the contents of the file containing our server's users
| will pipe the output of the command on the left hand side into the command on the right hand side
cut -d: -f1 will print the stream such that only the first column is printed (-d:) defines : as the delimiter

we want split up users based on project

Currently looking at best practices. For now, I will go ahead and look into using survey_display as the username for the survey_display project instead of webuser

figure out what users have what permissions

We know what permissions users have based on the groups they belong to.

cat /etc/group will reveal our current groups and members that belong to them

Since it looks like the server was not initially set up or managed with groups in mind, everyone pretty much belongs to their own private group. When adding users, by default they will end up in their own group UNLESS specified otherwise in /etc/default/useradd.

we need to reduce the privileges that are not necessary

Right now, this applies to scrape-util running as root. Other users (unless given sudo) belong to their own group which is a standard group.

does a standard user have write permissions outside of their own /home/username directory?

This post has some insights into this. Almost every single file outside of someones home directory shows up as not being writable by other in terms of permissions.

find out users on server that correspond to users on the database

Files are on slack.

@ryantanaka as part of this, don't forget to check what user is running what that makes the data come back from survey_display into a folder. When you do, first discuss with me on Slack just in case there are holes in it, then we decide what to post here (which is public).

Navigating to /var/www/www-data/occquse/responses and typing ls -alh in your terminal will show who created the the response file. This line of code in survey display is what does this. Additionally the location to which it is written to is specified in the first line of the /var/www/www-data/occquse file.

The reason why survey_display is allowed to write to /var/www/www-data/occquse/responses/ is because that folder was given permission. The output of ls -alh on the directory shows this for the responses folder:

drwxrwxrwx 2 blahhblahh blahhblahh 4096 Oct 17 11:19 responses (its not really blahhblahh)

Under normal circumstances, a standard user can't write to files outside of their home directory, but this specific directory had its permissions changed so that it could be written to.

I'm almost positive that whoever initially created this folder used the command sudo chmod 777 responses because files usually don't have complete r/w access for other, group, and owner all at the same time...

Running the command ps -ef | grep thatuserblahhblahh shows that the process is running the apache web server and nothing else.

don't forget to add here commands to manage users. Most of those are add/delete etc.

usermod and groupmod are the commands we can use to manage current users. The man pages for both commands have more details. I found this to be an informative post on usage examples.

find out how to create users such that they don't have a home folder (these users will be for running scripts)

Great post on this using the usermod command mentioned above. TLDR: useradd -M <username> : this adds the user without creating a home directory usermod -L <username> : to lock the account such that it cannot be logged into usermod -s /bin/false <username> : to disable the shell

OR use

useradd -M --shell /bin/false <username> usermod -L <username>

Now we can use that user for running scripts and not have to worry about home folders taking up space, or people trying to log into those users. Additionally the user has its shell disabled so it can't be interacted with.

I will test this method on my machine to run scripts from a locked down user with no shell or home folder then report back on the results..

Update: Tested it out, works great. I will put a detailed description of what was done in #5 as it relates to that.

moving forward as of 10/17

new tasks:

then create the `survey_display` user with the right permissions and default junk

[1:17] 
so thats step 1

[1:17] 
step 2 is, edit the config file

[1:17] 
step 3 is run the notes you did to test everything is fine in `survey_display`

versioning for scrape-util

erdl / server