Scribd
Upload
14 views

unit 2 css

The document outlines various aspects of Unix/Linux security architecture, including user and group management, superuser privileges, and file permissions. It emphasizes the importance of strong password policies, secure login methods, and regular system updates to mitigate vulnerabilities. Additionally, it addresses specific security risks such as SQL injection attacks and the significance of monitoring and auditing user activities.

Uploaded by

siddhartha singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
14 views

unit 2 css

The document outlines various aspects of Unix/Linux security architecture, including user and group management, superuser privileges, and file permissions. It emphasizes the importance of strong password policies, secure login methods, and regular system updates to mitigate vulnerabilities. Additionally, it addresses specific security risks such as SQL injection attacks and the significance of monitoring and auditing user activities.

Uploaded by

siddhartha singh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

1.

Unix/Linux Security Architecture


1. Security is based on layers: users, groups, and
permissions.
2. Users have unique IDs, and groups help manage
collective access.
3. Every file and process has an owner, group, and
permissions.
4. The kernel enforces security by controlling user access
to hardware and files.
5. Permissions are set as read (r), write (w), and execute
(x) for users, groups, and others.
6. Critical processes and files are restricted to root or
specific users.
7. Logging monitors activities and identifies suspicious
behavior.
8. File integrity monitoring tools like Tripwire detect
unauthorized changes.
9. Firewalls like iptables add an extra layer of protection.
10. Regular updates and patches keep the system secure
from vulnerabilities.

2. User Accounts
1. Each user gets a unique UID (User Identifier) and a
home directory.
2. Accounts can be standard users or administrative
(superuser).
3. Passwords are required for secure access to accounts.
4. User account settings are stored in /etc/passwd and
/etc/shadow.
5. System administrators manage accounts and access
permissions.
6. User accounts are restricted from accessing critical
system files.
7. Disabled or unused accounts are removed to reduce
vulnerabilities.
8. Strong password policies (length, complexity) are
enforced.
9. Users can belong to one or more groups to manage
access.
10. Temporary accounts are created with expiration
dates for contractors or guests.

3. Superuser (Root)
1. The superuser (root) has unlimited privileges over the
system.
2. Root can access all files, change configurations, and
manage users.
3. Root access is restricted and logged to prevent misuse.
4. Using the sudo command allows limited root access for
other users.
5. Running processes as root unnecessarily is a security
risk.
6. Root should use secure methods like SSH with key
authentication.
7. Tools like SELinux and AppArmor restrict root-level
actions.
8. Logging and auditing root activities help detect
unauthorized actions.
9. Avoid direct root logins; use privileged accounts instead.
10. Compromised root access can lead to full system
control for attackers.

4. Groups
1. Groups allow users to share access to files or directories.
2. Each user is assigned a primary group and can belong to
multiple groups.
3. Group information is stored in /etc/group.
4. Files and directories have group ownership for
collaborative access.
5. Group permissions are applied to all members.
6. Administrators manage group memberships using
usermod or gpasswd.
7. Secondary groups provide additional access without
changing the primary group.
8. Groups make managing permissions for teams easier.
9. Group policies enforce resource access boundaries.
10. Proper group assignments prevent unauthorized
access.

5. Login/Password
1. Logging in requires a username and password for
authentication.
2. Passwords should be strong and changed regularly.
3. The login process verifies user identity before granting
access.
4. Failed login attempts are logged to track suspicious
activities.
5. Secure methods like SSH are used for remote logins.
6. Two-factor authentication (2FA) adds an extra security
layer.
7. Passwords are stored securely in the shadow file, not in
plaintext.
8. Account lockout policies prevent repeated login
attempts.
9. Only authorized users can log in to critical servers.
10. Login prompts should not reveal system details.

6. Shadow Password File


1. The shadow file (/etc/shadow) securely stores encrypted
passwords.
2. It’s accessible only to root, protecting sensitive data.
3. Passwords are hashed using strong algorithms like SHA-
512.
4. Each line in the file contains a username, hashed
password, and password policies.
5. Expiry dates and lockout periods can be set for each user.
6. Shadow files prevent direct access to passwords stored in
/etc/passwd.
7. Security tools can audit shadow files for weak or expired
passwords.
8. Compromised shadow files pose serious security risks.
9. Regular monitoring of the shadow file ensures its
integrity.
10. Use tools like passwd to manage and update
password settings.

7. The Inode
1. Inodes store metadata about files, like size, permissions,
and ownership.
2. Each file and directory on a filesystem has a unique
inode.
3. Inodes don’t store file names, only pointers to data
blocks.
4. Commands like ls -i display the inode number of files.
5. Inodes track permissions, modification times, and file
links.
6. They are crucial for locating files and directories in the
filesystem.
7. Deleting a file removes its inode and frees its storage.
8. Corrupted inodes can cause file system errors.
9. Filesystems have a fixed number of inodes, limiting file
creation.
10. Tools like fsck check and repair inode issues.

8. Permissions for Directories


1. Directories have read (r), write (w), and execute (x)
permissions.
2. Read permission allows listing directory contents.
3. Write permission lets users create or delete files in the
directory.
4. Execute permission allows entering the directory.
5. Permissions are set for owner, group, and others (e.g.,
drwxr-xr--).
6. Use chmod to change directory permissions.
7. Setting permissions incorrectly can expose sensitive
files.
8. Default permissions can be controlled using umask.
9. Root users can override directory permissions.
10. Proper permissions prevent unauthorized access and
tampering.

9. Access Control: Set UserID and Set GroupID


1. Set UserID (SUID) lets users run a file with the owner’s
permissions.
2. Set GroupID (SGID) lets users execute a file with the
group’s permissions.
3. SUID is commonly used for critical binaries like passwd.
4. SGID is useful for collaborative directories shared by a
group.
5. Use chmod +s to set SUID or SGID on files or
directories.
6. Improperly set SUID/SGID can create security
vulnerabilities.
7. Audit files with SUID/SGID to ensure they are
necessary.
8. Removing unnecessary SUID/SGID settings reduces
risks.
9. Tools like find can locate SUID/SGID files for review.
10. Limit SUID/SGID usage to trusted programs only.

10. Database and SQL Injection Attacks


1. SQL Injection occurs when attackers insert malicious
queries into input fields.
2. It exploits vulnerabilities in poorly coded database
applications.
3. Can leak sensitive data, delete tables, or modify records.
4. Prevent by using prepared statements and parameterized
queries.
5. Validate and sanitize user inputs to block malicious code.
6. Limit database privileges to reduce attack impact.
7. Use firewalls and monitoring tools to detect unusual
database access.
8. Encrypt sensitive data to protect it even if accessed.
9. Regularly test applications for SQL injection
vulnerabilities.
10. Keep database systems updated with the latest
security patches.

You might also like