Network Security

Serive Denial Attact: DoS and DDoS

Account management is the most fundamental element of system security. It begins with creating and maintaining user accounts, each of which is identified by a unique identifier (username or user ID) and secured by an authentication method, typically a password. The proper management of user accounts is essential for protecting resources and ensuring that only authorized users can access system functionalities.

Key Concepts

• Identification and Authentication: Before accessing a system, users must identify themselves (identification) and prove their identity (authentication). This can involve something the user knows (password), something the user has (OTP or token), or something the user is (biometric information).
• Types of Accounts: Systems usually distinguish between accounts with administrative privileges and regular user accounts. Administrative accounts (e.g., Administrator in Windows, root in Linux/Unix) have broad system control, while general user accounts are limited in scope for security.
• Group Management: Especially in operating systems like Windows and Linux, users are assigned to groups that determine their access rights. For example, the "Administrators" group in Windows has full system privileges, while "Users" or "Guests" have restricted capabilities.
• Password and Credential Management: Secure management of passwords (enforcing complexity, expiration, non-reuse) and credentials is vital to prevent unauthorized access.

1. Account Management in Operating Systems

Windows

• Account Types: Windows includes default accounts such as Administrator (full system privileges), Guest (minimal privileges), and Users (standard users).
• Group Management: Users can belong to groups like Administrators, Power Users, Backup Operators, etc., which define their capabilities. For example, only Administrators can install software or modify system settings.
• Account Listing: Accounts and groups can be managed using commands such as net users (lists user accounts) and net localgroup (lists group memberships).

Group	Description
Administrators	Full control over the system, including user and directory management.
Power Users	Most admin rights locally, but cannot manage the system remotely or change critical settings.
Backup Operators	Can back up and restore files, even those they do not own.
Users	General users, limited access; cannot perform administrative tasks.
Guests	Very limited access, often temporary or for trial use.

Linux/Unix

• Account Types: The root account has all privileges; regular users have limited permissions. Accounts are listed in /etc/passwd and their encrypted passwords in /etc/shadow.
• Home Directory: Regular user accounts usually have a dedicated home directory (e.g., /home/username), while root typically has /root as the home directory.
• Shell Access: Each account has a default shell, such as /bin/bash or /bin/sh, which defines the user's command environment.
• Special System Accounts: Accounts like sync, shutdown, halt, and operator are used for specific system functions and are not intended for general login.

2. Account Managemnet in Database

• User Accounts: Database systems, such as Oracle, MySQL, and MS-SQL, maintain their own internal user accounts. These accounts are needed to connect to and interact with the database, often with separate credentials from the underlying operating system.
• Privilege Assignment: Each account is assigned privileges appropriate to its role, such as read, write, or administrative (DBA) rights. It is important to follow the principle of least privilege, only granting the minimum permissions required for each user or application.
• Password and Authentication: Databases enforce authentication through passwords or, in some environments, integrated authentication with external systems. Secure password management, complexity, and rotation policies are necessary to prevent unauthorized access.
• Account Auditing: Regularly reviewing database user accounts and their privileges helps to detect and remove unnecessary or obsolete accounts, minimizing attack surfaces.
• Account Separation: Administrative accounts should be separated from general user accounts, and applications accessing the database should use their own dedicated accounts, not shared credentials.

3. Account Management in Application Software

• Account Types: Application software, such as business or web applications, often manages its own user accounts, separate from OS or database accounts. Each user is given an ID and password, and roles (admin, user, guest, etc.) can be assigned within the application.
• Authentication and Authorization: Applications typically implement their own authentication logic, supporting password login, multifactor authentication, and session management. User roles and permissions determine access to functions and data within the application.
• Password Policy: Enforce secure password creation, periodic password changes, and prevent reuse of old passwords to protect application accounts.
• Session Security: Proper management of user sessions (timeout, logout, secure cookie use) is critical to prevent unauthorized access through session hijacking.
• Audit Trails: Track key account activities, such as login attempts, permission changes, or access to sensitive resources, to enable detection of suspicious activity.
• Separation of Duties: Critical application operations should require multiple roles or users to reduce the risk of abuse or fraud.

4. Account Management in Network Device

• Local and Remote Accounts: Routers, switches, and firewalls require user accounts for configuration and management. Devices usually provide both local accounts (stored on the device) and the option to integrate with centralized user directories (such as RADIUS, TACACS+, or LDAP).
• Privilege Levels: Accounts are assigned privilege levels, such as read-only, operator, or administrator. For example, in Cisco IOS, different levels control access to configuration and operational commands.
• Password Management: Network device accounts require strong, unique passwords and should not use default credentials. Passwords should be changed regularly and securely stored (hashed and not in cleartext).
• Account Usage Control: Accounts should be created for individual administrators rather than sharing a common admin account. Disable or remove accounts that are no longer needed, and restrict access based on job roles.
• Logging and Monitoring: All account activities (logins, configuration changes) should be logged and monitored to detect unauthorized access or misconfiguration.
• Physical and Network Security: Restrict physical access to network devices and limit remote access to trusted hosts and secure protocols (SSH, HTTPS).

Best Practices

• Assign only necessary privileges to accounts and groups ("least privilege" principle).
• Regularly review and remove unused or obsolete accounts.
• Enforce strong authentication mechanisms (e.g., multi-factor authentication where possible).
• Monitor account usage and audit logs to detect suspicious activities.

Session Management

Session management refers to the process of maintaining and controlling an active connection or interaction between a user (or client) and a system. A session represents the period during which the system recognizes and retains the user's state and identity. Effective session management is crucial for security, as it helps prevent unauthorized access and ensures that users are properly authenticated throughout their activities.

Key Concepts

• Session Establishment and Maintenance: A session is created when a user successfully authenticates and connects to a system or application. The system must keep track of this session to allow seamless user interactions.
• Session Timeout: To prevent security risks, sessions are often set to expire after a period of inactivity (timeout). This limits the window of opportunity for attackers to hijack unattended sessions.
• Continuous Authentication: Beyond initial login, systems may require ongoing or periodic authentication to confirm the user's identity—such as password re-entry, biometric checks, or security tokens. For example, a screensaver with a password prompt in Windows, or a banking website asking for a one-time code during a session.
• Session Protection: To defend against threats like session hijacking and sniffing, sessions should be encrypted and securely managed. Session tokens or IDs should be unpredictable, transmitted over encrypted channels, and invalidated after logout.

1. Session Management in Operating Systems

• Screen Lock and Timeout: Operating systems such as Windows use screen savers and automatic screen locks to protect active sessions. After a specified period of inactivity, the session is locked and requires user authentication to resume.
• Configuration: In Windows, users can configure the screen saver and lock timeout. In Unix/Linux, session timeout values can be set in files like /etc/default/login or /etc/profile.
• Remote Access: When connecting remotely, systems may require re-authentication after session timeouts to ensure security.

2. Session Management in Database Systems

• Session Persistence: Database sessions typically do not have timeouts because they are maintained as long as the client connection exists. If a timeout is needed, the system may disconnect idle sessions.
• Reconnection Requirement: If a network disconnection occurs, users must re-authenticate to establish a new session.

3. Session Management in Network Devices

• Session Timeout: Network devices (routers, switches, firewalls) often support session timeouts to automatically log out inactive administrative sessions for security.
• Configuration: Timeout values are typically set in user environment configuration files or device management interfaces.

4. Session Management in Web and Application Services

• Continuous Authentication: Web services may require repeated entry of security codes (from tokens or smart cards) or enforce re-login after certain actions, such as changing sensitive information or after a timeout period.
• Password Expiry: Systems may enforce password changes after a set period, requiring users to re-authenticate with a new password.
• Session Security: Secure session management includes using HTTPS, regenerating session tokens after login, and invalidating sessions upon logout to prevent session hijacking.

Best Practices

• Implement session timeouts for all user sessions and require re-authentication after timeout.
• Encrypt all session communications to protect against sniffing and interception.
• Use unpredictable and securely generated session IDs or tokens.
• Monitor session activity and detect anomalies (e.g., simultaneous logins from different locations).

Access Control

Access control refers to the enforcement of rules that determine who can access specific systems, services, or data based on predefined permissions. Effective access control ensures that only authorized users can interact with critical resources, enhancing the system's overall security posture. Access can be controlled at the operating system, database, application, and network device levels.

1. Access Control in Operating Systems

• Administrative Interfaces: OS-level access control often involves managing access to terminal services or GUI-based administrative tools. Common access services include SSH (port 22), Telnet (port 23), FTP (port 21), and RDP (port 3389).
• Secure Interfaces: Telnet and FTP are discouraged due to lack of encryption; instead, SSH or secure FTP (SFTP) should be used.
• TCP Wrapper: On Unix-based systems, TCP Wrapper can be used with inetd or xinetd to enforce IP-based access control and log attempts. Configuration includes access control rules based on source IPs and services.
• Port Filtering: Unnecessary services and ports should be disabled or filtered to reduce attack surfaces.

2. Access Control in Databases

• IP Whitelisting: Databases like Oracle use configuration files (e.g., sqlnet.ora) to define allowed or denied client IP addresses using parameters like tcp.invited_nodes and tcp.excluded_nodes.
• Grant-Based Access: Systems like MySQL and MS-SQL use SQL GRANT statements to assign access privileges to users based on their IP address.
• Firewall Integration: In Windows-based MS-SQL systems, IP-based restrictions may be enforced via external firewall software, as native access control is limited.

3. Access Control in Application Software

• Application-Level Restrictions: Web servers such as NGINX or IIS support access control using IP-based filters or client certificate authentication (SSL/TLS).
• Example (NGINX): Access can be restricted by defining IP-based allow/deny rules in the configuration:

  
  server {
    listen 443 ssl;
    server_name www.example.com;
    location / {
      deny 192.168.1.2;
      allow 192.168.1.1/24;
      allow 2001:db8::/32;
      deny all;
    }
  }
        

• Layered Control: Applications may implement additional controls such as user roles, request validation, and authentication tokens.

4. Access Control in Network Devices

• Interface-Based Access: Network devices often restrict access to administrative interfaces via IP-based control, similar to Unix TCP Wrapper.
• ACL (Access Control List): ACLs are used to define which IP addresses are permitted or denied access to the device or through the network. This is commonly used in routers, switches, and firewalls.
• Port Security: Certain network equipment supports port-level access control, only allowing traffic from registered MAC or IP addresses.

Best Practices

• Identify and restrict unnecessary services and open ports.
• Use encrypted protocols (e.g., SSH over Telnet, SFTP over FTP).
• Apply IP-based access control at multiple layers (OS, DB, app, network).
• Log all access attempts and review them regularly.
• Segment networks and isolate sensitive systems from general access.

Privilege & Permission Management

Privilege and permission management involves controlling access rights to files, directories, applications, and data based on user roles. Proper configuration ensures that only authorized users and processes can read, write, or execute specific resources. Permissions must be enforced at multiple levels—OS, database, and application—to achieve comprehensive security.

1. Permission Management in Operating Systems

Windows (NTFS)

• Windows systems using NTFS allow detailed control over file and folder permissions. These permissions include:
  • Full Control: Modify all permissions and take ownership.
  • Modify: Read, write, and delete contents.
  • Read & Execute: Open and execute files.
  • List Folder Contents: View file names in a directory.
  • Read: View file content.
  • Write: Create and modify files.
• NTFS permission rules:
  • Permissions are cumulative across groups.
  • Explicit file permissions override folder-level permissions.
  • When conflicting, deny overrides allow.

Linux/Unix

• File permissions are based on owner, group, and others. Each category can be granted:
  • r – read
  • w – write
  • x – execute
• Permissions can be displayed using ls -al and set using chmod. They are often represented numerically (e.g., 755):
  • 4 = read, 2 = write, 1 = execute
• Example: drwxr-xr-x means the owner has full access, group and others have read and execute access.

2. Permission Management in Databases

• Database permissions are controlled using specific SQL queries:
  • DDL (e.g., CREATE, DROP): structure definitions
  • DML (e.g., SELECT, INSERT, UPDATE, DELETE): data operations
  • DCL (e.g., GRANT, REVOKE, DENY): permission management
• Permissions can be granted to users or roles for specific operations on tables, views, or columns.
• Views can be used to limit access to sensitive fields (e.g., birthdates or salaries) by presenting only selected columns.

3. Permission Management in Application Software

• Application-level permissions may include roles such as "admin", "editor", and "viewer", controlling what each user can do within the system.
• Insecure configuration can result in an application executing with high system privileges (e.g., root), which increases the risk of exploitation.
• Best practices include:
  • Running services under restricted accounts (e.g., nobody, www-data in Unix and Linux, non-admin users in Windows)
  • Using access control lists (ACLs) within the application logic
  • Separating privileges between code execution and administrative actions

Best Practices

• Apply the principle of least privilege to all users and services.
• Regularly audit file and database permissions.
• Use role-based access control (RBAC) where appropriate.
• Configure web services and applications to run under limited accounts.
• Restrict permissions to sensitive database columns using views.

Log Management

Log management refers to the systematic process of collecting, storing, analyzing, and reviewing log data generated by operating systems, application software, databases, and network devices. Effective log management is essential for monitoring system activities, detecting security incidents, and supporting audits or investigations.

AAA Framework in Log Management

Log management is closely tied to the AAA principles:

• Authentication: Verifying the user’s identity (such as login ID and password).
• Authorization: Determining if the authenticated user is permitted to perform specific actions or access resources.
• Accounting: Recording and tracking user activities, including logins, commands, and resource usage.

1. Log Management in Operating System

Windows

• Windows uses a centralized logging mechanism called the Event Viewer, which categorizes logs into types such as access audits, account management, logon events, process tracking, and policy changes.
• Each log entry contains details such as:
  • Date and time
  • User
  • Event ID
  • Source (system/process)
  • Result (success/failure)
  • Computer name
• Audit policies allow administrators to specify what types of events are logged, including object access, account logon, and privilege use.

Unix/Linux

• Unix/Linux logs are distributed across various files, primarily within /var/log.
• Major log files include:
  • /var/log/utmp: Tracks currently logged-in users and active sessions.
  • /var/log/wtmp: Records logins, logouts, and system reboots.
  • /var/log/secure or sulog: Logs authentication attempts, privilege escalations (su/sudo).
  • /var/log/history: Shell command history.
  • /var/log/syslog and /var/log/messages: System and kernel messages.

2. Log Mangement in Database

• MS-SQL: Supports login auditing and C2 audit tracing. By default, only failed logins are audited, but this can be expanded to include successful logins and detailed actions.
• MySQL: Provides several types of logs, such as error logs, general query logs, slow query logs, and binary logs. Administrators can enable or disable each log as needed.
• Oracle: Uses the AUDIT_TRAIL parameter for auditing, with options to log events in the database or OS. Various types of audit logs are supported, such as statement, privilege, and object auditing.
• In high-security environments, a dedicated database monitoring system is often used to capture all relevant activities without impacting the performance of the main database server.
  This setup typically uses a tapping device (network tap) that passively duplicates all network traffic between database users (or DBAs) and the database server. The duplicated traffic is sent to a separate DB monitoring system where all queries and access attempts are logged and analyzed independently from the main database server.
  
  • Advantages: All database queries—including failed and unauthorized attempts—are captured even if the database server is compromised. Because log storage and monitoring occur outside the database, attackers would have to breach the log server to tamper with evidence.
  • Operation: Logs are stored on a dedicated log/monitoring server, so even if an intruder deletes traces from the DB server, records remain for investigation and compliance.

     [DB User/DBA]
          |
          v
    [ Tapping Device ] ---> [ DB Monitoring System ]
          |
          v
      [ DB Server ]
    

3. Log Mangement in Application Software

• Web and FTP servers generate extensive logs that are critical for detecting incidents such as unauthorized access, web defacement, or data leaks.
• IIS (Internet Information Services): Supports configurable logging formats (e.g., W3C), including fields such as timestamp, IP address, request method, status code, user agent, etc.
• Apache Web Server: Uses access_log and customizable log formats (e.g., "combined"), recording details such as client/server IP, request URI, status code, bytes sent, referrer, and user agent.
• Log analysis is essential for incident response, but attackers may attempt to erase logs; thus, log files should be protected and archived securely.

4. Log Mangement in Network Device

• Network devices (e.g., routers, switches) may have limited local storage, so logs are often sent to a centralized log server via protocols such as syslog.
• Logs include:
  • Security system logs: Intrusion detection/prevention systems (IDS/IPS), firewall logs, and SIEM platforms collect and correlate network security events.
  • Network management logs: Track network traffic and device status via monitoring tools (e.g., MRTG, NMS).
  • Device authentication logs: Record authentication attempts for network equipment, often managed via dedicated authentication servers (e.g., TACACS+).
• Centralized logging makes it harder for attackers to erase their traces and enables more effective incident investigation.

Best Practices

• Centralize log collection (e.g., use a SIEM or dedicated log server).
• Encrypt logs and restrict access to prevent tampering.
• Rotate and archive logs to manage storage and retention policies.
• Implement real-time monitoring and alerts for suspicious activity.
• Synchronize system clocks for accurate log timestamps across systems.