first task almost done just need to add an example of an Bash we use for scanning
هذا الالتزام موجود في:
269
Security_Audit/README.md
Normal file
269
Security_Audit/README.md
Normal file
@@ -0,0 +1,269 @@
|
|||||||
|
# this is a 15 basic clause
|
||||||
|
|
||||||
|
|
||||||
|
## 1-Container Authentication
|
||||||
|
- No container should run as the root user.
|
||||||
|
|
||||||
|
- This is not a minor error; it can lead to a problem that is difficult to resolve.
|
||||||
|
|
||||||
|
- An attacker could exploit this error to access highly sensitive information or even create a security vulnerability.
|
||||||
|
|
||||||
|
## 2-cheack Container image
|
||||||
|
- Let's assume we're working on an Ubuntu image in Dockerfile, and the user executes a command like:
|
||||||
|
```
|
||||||
|
FROM ubuntu:20.04
|
||||||
|
RUN apt update && apt install -y nginx openssl
|
||||||
|
COPY . /app
|
||||||
|
```
|
||||||
|
- Here, the user is running an older version, and their OpenSSL might contain serious security vulnerabilities.
|
||||||
|
|
||||||
|
- The solution is to use a scanning tool such as Trivy or Clair, which will indicate that there is a problem.
|
||||||
|
- Trivy will output somthing like this if the image contains outdated packges
|
||||||
|
```
|
||||||
|
Target: myapp:latest
|
||||||
|
|
||||||
|
CRITICAL: 2
|
||||||
|
HIGH: 6
|
||||||
|
MEDIUM: 15
|
||||||
|
|
||||||
|
openssl
|
||||||
|
CVE-2025-12345
|
||||||
|
Severity: CRITICAL
|
||||||
|
Fixed Version: 3.0.17
|
||||||
|
```
|
||||||
|
## 3-Update the image and remove unused packeges
|
||||||
|
|
||||||
|
- unused packeges increases the attack surfacec
|
||||||
|
|
||||||
|
- Every software package has the potential to contain security vulnerabilities, especially those that are not used because the programmer usually forgets to update them.
|
||||||
|
|
||||||
|
- For example, if the application is built using only the Python API, there is no need for the gcc compiler.
|
||||||
|
|
||||||
|
- We typically use the `apt clean` command, which removes the cached package file.
|
||||||
|
## 4-Port Scanning
|
||||||
|
|
||||||
|
- All network ports should be reviewed regularly to ensure that only required services are exposed.
|
||||||
|
|
||||||
|
- For Ghaymah, PostgreSQL is one of the core services. By default, PostgreSQL listens on port 5432. If this port is publicly accessible, attackers can detect the database server, attempt brute-force attacks, or exploit known vulnerabilities.
|
||||||
|
|
||||||
|
- To identify exposed ports, administrators can use Nmap.
|
||||||
|
```Bash
|
||||||
|
nmap -sV <server-ip>
|
||||||
|
```
|
||||||
|
Example output:
|
||||||
|
```Bash
|
||||||
|
PORT STATE SERVICE
|
||||||
|
80/tcp open http
|
||||||
|
443/tcp open https
|
||||||
|
5432/tcp open postgresql
|
||||||
|
```
|
||||||
|
- If PostgreSQL (port 5432) is accessible from the Internet, it should be restricted so that only authorized application servers or internal networks can connect to it. External users should communicate only with the web application over ports 80 and 443.
|
||||||
|
|
||||||
|
## 5-Firewall Rules and Monitoring
|
||||||
|
|
||||||
|
- Firewall rules should follow the least privilege principle by allowing only the traffic required for the application to operate.
|
||||||
|
|
||||||
|
- For Ghaymah, only public web services such as HTTP (80) and HTTPS (443) should be accessible from the Internet. Database services, such as PostgreSQL (5432), should only accept connections from authorized application servers or internal networks.
|
||||||
|
|
||||||
|
Example firewall policy:
|
||||||
|
```
|
||||||
|
ALLOW 80/tcp from Any
|
||||||
|
ALLOW 443/tcp from Any
|
||||||
|
ALLOW 5432/tcp from 10.0.0.0/24
|
||||||
|
DENY 5432/tcp from Any
|
||||||
|
```
|
||||||
|
- In addition to firewall protection, firewall logs should be forwarded to Splunk for continuous monitoring and threat detection.
|
||||||
|
|
||||||
|
Using Splunk, administrators can:
|
||||||
|
|
||||||
|
- Detect repeated connection attempts to blocked ports.
|
||||||
|
- Identify brute-force attacks targeting PostgreSQL.
|
||||||
|
- Monitor unusual traffic patterns or port-scanning activities.
|
||||||
|
- Generate real-time alerts when suspicious network behavior is detected.
|
||||||
|
|
||||||
|
By combining firewall rules with Splunk monitoring, Ghaymah can both prevent unauthorized access and quickly detect potential attacks against its infrastructure.
|
||||||
|
## 6-Encrypt Data Using TLS/HTTPS
|
||||||
|
|
||||||
|
- All communication between clients, application servers, and backend services should be encrypted using TLS (Transport Layer Security).
|
||||||
|
|
||||||
|
- For Ghaymah, all web traffic should be served over HTTPS instead of HTTP to protect sensitive information such as user credentials, API tokens, and personal data from interception or man-in-the-middle (MITM) attacks.
|
||||||
|
|
||||||
|
- valid SSL/TLS certificates should be installed of weak TLS old versions
|
||||||
|
|
||||||
|
- Encrypting all network communication helps maintain the confidentiality and integrity of data throughout Ghaymah's infrastructure.
|
||||||
|
## 7-Protect Against SQL Injection
|
||||||
|
|
||||||
|
SQL Injection is one of the most common web application attacks. It occurs when user input is inserted directly into SQL queries without proper validation or parameterization.
|
||||||
|
|
||||||
|
For example, an insecure login query might be written as:
|
||||||
|
```SQL
|
||||||
|
SELECT * FROM users
|
||||||
|
WHERE username = '$username'
|
||||||
|
AND password = '$password';
|
||||||
|
```
|
||||||
|
An attacker could enter malicious input to modify the SQL query and bypass authentication or access unauthorized data.
|
||||||
|
|
||||||
|
To prevent SQL Injection, Ghaymah should:
|
||||||
|
|
||||||
|
- Use parameterized queries (prepared statements) instead of concatenating user input.
|
||||||
|
- Validate and sanitize all user input.
|
||||||
|
- Apply the principle of least privilege by ensuring the PostgreSQL application account has only the permissions it requires.
|
||||||
|
- Enable detailed PostgreSQL logging to record failed queries and suspicious database activity.
|
||||||
|
- Monitor database logs with Splunk to detect repeated SQL errors or unusual query patterns that may indicate an SQL Injection attempt.
|
||||||
|
|
||||||
|
These measures significantly reduce the risk of unauthorized database access and help protect sensitive data stored in PostgreSQL.
|
||||||
|
## 8-Protect Against Cross-Site Scripting (XSS)
|
||||||
|
|
||||||
|
Cross-Site Scripting (XSS) is a web application vulnerability that allows attackers to inject malicious JavaScript code into web pages viewed by other users.
|
||||||
|
|
||||||
|
For example, if Ghaymah allows users to submit comments or other text without proper validation, an attacker could submit:
|
||||||
|
```XML
|
||||||
|
<script>alert("XSS Attack")</script>
|
||||||
|
```
|
||||||
|
If this input is displayed without being sanitized or escaped, the script will execute in every user's browser who visits the page. In more serious cases, attackers may steal session cookies, hijack user accounts, or redirect users to malicious websites.
|
||||||
|
|
||||||
|
To prevent XSS attacks, Ghaymah should:
|
||||||
|
|
||||||
|
- Validate and sanitize all user input.
|
||||||
|
- Escape HTML characters before displaying user-generated content.
|
||||||
|
- Implement a Content Security Policy (CSP) to restrict unauthorized JavaScript execution.
|
||||||
|
- Store session cookies with the HttpOnly, Secure, and SameSite attributes.
|
||||||
|
- Monitor web server and WAF logs with Splunk to detect repeated XSS payloads such as `<script>` tags or suspicious JavaScript patterns.
|
||||||
|
|
||||||
|
These measures help protect users from client-side attacks and improve the overall security of Ghaymah's web applications.
|
||||||
|
## 9-Enable Multi-Factor Authentication (MFA)
|
||||||
|
|
||||||
|
Multi-Factor Authentication (MFA) adds an extra layer of security by requiring users to verify their identity using two or more authentication factors instead of relying only on a password.
|
||||||
|
|
||||||
|
For Ghaymah, MFA should be enabled for all administrator accounts, DevOps engineers, and users with access to sensitive resources or cloud management dashboards.
|
||||||
|
|
||||||
|
For example, the authentication process may require:
|
||||||
|
- Username or Email
|
||||||
|
- Password
|
||||||
|
- One-Time Password (OTP) from an Authenticator App
|
||||||
|
|
||||||
|
Even if an attacker obtains a user's password through phishing or a data breach, they cannot access the account without the second authentication factor.
|
||||||
|
|
||||||
|
In addition, authentication logs should be forwarded to Splunk to monitor suspicious login activities, such as repeated failed MFA attempts, logins from unfamiliar locations, or multiple authentication requests within a short period. Real-time alerts can help
|
||||||
|
## 10-Implement Access Control and Resource Isolation
|
||||||
|
|
||||||
|
In a cloud platform, each user should only have access to their own resources and should not be able to view or modify resources belonging to other users.
|
||||||
|
|
||||||
|
For Ghaymah, proper Identity and Access Management (IAM) policies should be implemented to enforce the principle of least privilege, where users receive only the permissions required for their tasks.
|
||||||
|
|
||||||
|
This can be achieved by:
|
||||||
|
|
||||||
|
- Implementing role-based access control (RBAC).
|
||||||
|
- Assigning unique permissions for each user or organization.
|
||||||
|
- Isolating user containers and databases using network policies.
|
||||||
|
- Ensuring API endpoints verify resource ownership before allowing access.
|
||||||
|
- Logging access events and monitoring them using Splunk to detect unauthorized access attempts.
|
||||||
|
## 11-Implement Rate Limiting
|
||||||
|
|
||||||
|
Rate Limiting is a security mechanism that controls the number of requests a user, IP address, or API key can send within a specific time period.
|
||||||
|
|
||||||
|
For Ghaymah, Rate Limiting should be applied to critical services such as login APIs, public APIs, and database-related endpoints to prevent abuse and protect system availability.
|
||||||
|
|
||||||
|
|
||||||
|
If a user exceeds this limit, the server should temporarily block additional requests and return:
|
||||||
|
```
|
||||||
|
HTTP/1.1 429 Too Many Requests
|
||||||
|
```
|
||||||
|
Rate Limiting helps protect Ghaymah against:
|
||||||
|
|
||||||
|
- Brute-force attacks targeting user accounts.
|
||||||
|
- API abuse and excessive resource consumption.
|
||||||
|
- Denial-of-Service (DoS) attempts.
|
||||||
|
- Automated data scraping.
|
||||||
|
## 12-Encrypt Sensitive Data Before Storage
|
||||||
|
|
||||||
|
Sensitive information should not be stored in plain text because a database breach could expose confidential user data.
|
||||||
|
|
||||||
|
For Ghaymah, sensitive data such as personal information, API keys, authentication tokens, and other confidential records should be encrypted before being stored in databases such as PostgreSQL.
|
||||||
|
|
||||||
|
|
||||||
|
For passwords, Ghaymah should never use reversible encryption. Passwords should be stored as secure hashes using algorithms such as Argon2, bcrypt, or scrypt.
|
||||||
|
|
||||||
|
Additional security measures include:
|
||||||
|
|
||||||
|
- Encrypting sensitive database fields.
|
||||||
|
- Managing encryption keys separately from the database.
|
||||||
|
- Applying proper access controls to limit who can decrypt sensitive information.
|
||||||
|
- Encrypting backups to prevent data exposure.
|
||||||
|
|
||||||
|
Database and application logs can also be monitored using Splunk to detect unauthorized access attempts or unusual data access patterns.
|
||||||
|
## 13-Implement Secure Backup and Recovery
|
||||||
|
|
||||||
|
Regular backups should be implemented to protect critical data and ensure service recovery in case of hardware failure, cyber attacks, or accidental data deletion.
|
||||||
|
|
||||||
|
A proper backup strategy should include:
|
||||||
|
|
||||||
|
- Performing automated database backups using scheduled jobs.
|
||||||
|
- Storing backups in a separate and secure location to prevent loss if the main infrastructure is compromised.
|
||||||
|
- Encrypting backup files to protect sensitive information.
|
||||||
|
- Testing backup restoration regularly to ensure backups can be recovered successfully.
|
||||||
|
- Applying access controls so only authorized administrators can access backup files.
|
||||||
|
|
||||||
|
For example, PostgreSQL backups can be created using:
|
||||||
|
```SQL
|
||||||
|
pg_dump database_name > backup.sql
|
||||||
|
```
|
||||||
|
and restored using:
|
||||||
|
```SQL
|
||||||
|
psql database_name < backup.sql
|
||||||
|
```
|
||||||
|
## 14-Apply the Principle of Least Privilege
|
||||||
|
|
||||||
|
Users and services should only receive the minimum permissions required to perform their tasks.
|
||||||
|
|
||||||
|
For Ghaymah, excessive permissions increase the impact of compromised accounts. If an attacker gains access to an account with unnecessary administrative privileges, they may be able to access sensitive resources, modify configurations, or delete important data.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
Developer Account:
|
||||||
|
- Deploy applications
|
||||||
|
- View application logs
|
||||||
|
|
||||||
|
Administrator Account:
|
||||||
|
- Manage users
|
||||||
|
- Configure security settings
|
||||||
|
## 15-Maintain Detailed Audit Logs
|
||||||
|
|
||||||
|
A cloud platform should maintain detailed audit logs that record all important user and system activities. These logs provide visibility into what happened, who performed the action, and when it occurred.
|
||||||
|
|
||||||
|
For Ghaymah, audit logs should record critical events such as:
|
||||||
|
|
||||||
|
- User login and logout activities.
|
||||||
|
- Creation, modification, and deletion of containers.
|
||||||
|
- Changes to user permissions and security settings.
|
||||||
|
- API requests and administrative actions.
|
||||||
|
- Database access and configuration changes.
|
||||||
|
|
||||||
|
Example audit log:
|
||||||
|
```
|
||||||
|
[11:24:05] User: Ahmed
|
||||||
|
Action: Login successful
|
||||||
|
Source IP: 192.168.1.10
|
||||||
|
|
||||||
|
[11:50:32] User: Ahmed
|
||||||
|
Action: Deleted container
|
||||||
|
Resource: container-123
|
||||||
|
Status: Successful
|
||||||
|
```
|
||||||
|
Audit logs should include:
|
||||||
|
|
||||||
|
- User identity.
|
||||||
|
- Timestamp of the activity.
|
||||||
|
- Source IP address.
|
||||||
|
- Performed action.
|
||||||
|
- Target resource.
|
||||||
|
- Result of the operation.
|
||||||
|
|
||||||
|
These logs should be stored securely and forwarded to Splunk for centralized monitoring and analysis. Splunk can be used to:
|
||||||
|
|
||||||
|
- Detect suspicious activities.
|
||||||
|
- Create alerts for unusual administrative actions.
|
||||||
|
- Investigate security incidents by analyzing the timeline of events.
|
||||||
|
- Track unauthorized access attempts.
|
||||||
|
|
||||||
|
Maintaining detailed audit logs improves accountability, supports incident response, and helps Ghaymah quickly identify and investigate security incidents.
|
||||||
المرجع في مشكلة جديدة
حظر مستخدم