Cybersecurity Labs - Module 2

?? Goal: Install the Snort intrusion detection system

?? Why This Matters:
Snort is the world's most widely deployed IDS/IPS, used by organizations from small businesses to Fortune 500 companies. It performs real-time traffic analysis and packet logging to detect attacks like buffer overflows, stealth port scans, and CGI attacks.

?? Command:
sudo apt update && sudo apt install snort -y

?? What This Does:
� apt update - Refreshes package lists from repositories
� apt install snort -y - Installs Snort and all dependencies automatically

?? Goal: Confirm Snort installed correctly

?? Command:
snort --version

?? Expected Output:
You should see version info like "Snort Version 2.9.x" with build details. This confirms the binary is accessible and working.

?? Goal: Define which networks Snort should protect

?? Why This Matters:
Snort needs to know your internal network (HOME_NET) vs external traffic (EXTERNAL_NET) to properly classify threats. Misconfiguration leads to false positives or missed attacks.

?? Command:
sudo nano /etc/snort/snort.conf

?? Key Settings:
� ipvar HOME_NET 192.168.1.0/24 - Your protected network
� ipvar EXTERNAL_NET !$HOME_NET - Everything else is external

?? Goal: Enable community-maintained detection rules

?? Why This Matters:
Rules are the brain of Snort - they define what traffic patterns indicate attacks. Community rules cover thousands of known threats including malware signatures, exploit attempts, and suspicious behaviors.

?? Command:
sudo snort-rules-default

?? What Gets Installed:
� Community rules (~3,800+ signatures)
� Emerging threats rules
� Protocol anomaly detection

?? Goal: Add organization-specific threat detection

?? Why This Matters:
Generic rules don't cover your specific environment. Custom rules detect threats unique to your organization - like SSH brute force on non-standard ports or access to sensitive internal servers.

?? Command:
sudo nano /etc/snort/rules/local.rules

?? Example Custom Rules:
� Detect ICMP ping sweeps
� Alert on SSH connection attempts
� Monitor access to critical servers

?? Goal: Test configuration before production deployment

?? Why This Matters:
A syntax error in snort.conf will prevent Snort from starting. Always validate in test mode before deploying to production - downtime in IDS means blind spots in security monitoring.

?? Command:
sudo snort -T -c /etc/snort/snort.conf

?? Success Indicator:
Look for "Snort successfully validated the configuration!" at the end of output.

?? Goal: Begin real-time network monitoring

?? Why This Matters:
This launches Snort as an active IDS, monitoring all traffic on the specified interface. Console mode shows alerts in real-time for immediate visibility.

?? Command:
sudo snort -A console -i eth0 -c /etc/snort/snort.conf -l /var/log/snort

?? Flags Explained:
� -A console - Output alerts to console
� -i eth0 - Monitor this network interface
� -c - Use this config file
� -l - Log to this directory

?? Goal: Send alerts to centralized logging (syslog/SIEM)

?? Why This Matters:
Enterprise security requires centralized logging. Syslog integration sends Snort alerts to your SIEM (Splunk, QRadar, etc.) for correlation with other security events and compliance reporting.

?? Snort Directive:
output alert_syslog: LOG_AUTH LOG_ALERT

?? Syslog Facilities:
� LOG_AUTH - Authentication/security messages
� LOG_ALERT - High priority alerts

?? Goal: Verify IDS is detecting and logging threats

?? Why This Matters:
The final validation ensures your complete IDS pipeline works - from packet capture to rule matching to log storage. This is what SOC analysts review during incident investigation.

?? Command:
sudo tail -f /var/log/snort/alert

?? What You'll See:
Real-time alerts showing detected threats with timestamps, source/destination IPs, and rule IDs that triggered.

?? Goal: Establish a trusted Root CA for your organization

?? Why This Matters:
A Certificate Authority (CA) is the foundation of PKI. It acts as a trusted entity that issues digital certificates. Without a CA, clients have no way to verify if a certificate is legitimate, leaving connections vulnerable to man-in-the-middle attacks.

?? Actions:
1. Click "Create CA" button in toolbar
2. Enter CA Name: TechCorp-Root-CA
3. Select Key Length: 4096 bits
4. Set Validity: 10 years
5. Enter Organization: TechCorp
6. Click "Create CA"

?? What Happens:
� A public/private key pair is generated
� The CA's self-signed certificate is created
� This certificate will sign all other certificates

?? Goal: Create a CSR for your web server

?? Why This Matters:
A CSR is how servers request certificates from a CA. It contains the server's public key and identity information but NOT the private key (which never leaves the server). This separation is critical for security.

?? Actions:
1. Click "Generate CSR" button
2. Common Name: app.techcorp.local
3. Key Length: 2048 bits
4. Organization: TechCorp
5. Click "Generate CSR"

?? CSR Contents:
� Public key (shared freely)
� Subject information (CN, O, OU, etc.)
� Digital signature proving ownership

?? Goal: Issue a signed certificate from your CA

?? Why This Matters:
When a CA signs a certificate, it cryptographically vouches for that certificate's authenticity. Clients who trust the CA will automatically trust certificates it signs. This is the entire trust model of PKI.

?? Actions:
1. Click "Sign Certificate" button
2. Select the CSR: app.techcorp.local
3. Set Validity: 365 days
4. Certificate Type: Server
5. Click "Sign"

?? Signing Process:
� CA creates a hash of the CSR data
� Hash is encrypted with CA's private key
� Encrypted hash = digital signature
� Signature is attached to create final certificate

?? Goal: Review your certificate infrastructure

?? Why This Matters:
Certificate lifecycle management is crucial. Expired or misconfigured certificates cause outages. Organizations must track all certificates to ensure timely renewal and proper chain of trust.

?? Actions:
1. Click "View Certificates" button
2. Verify CA certificate is listed (Root CA)
3. Verify server certificate is listed (app.techcorp.local)
4. Check certificate chain shows valid trust path

?? What to Verify:
� Serial numbers are unique
� Validity dates are correct
� Subject names match intended use
� Status shows "Active"

?? Goal: Remove trust from a compromised certificate

?? Why This Matters:
If a private key is stolen or an employee leaves, their certificate must be revoked immediately. Otherwise, attackers can impersonate legitimate services. Revocation is a critical incident response capability.

?? Actions:
1. Click "Revoke Certificate" button
2. Select certificate from the list
3. Select Reason: Key Compromise
4. Click "Revoke"

?? Revocation Reasons (RFC 5280):
� Key Compromise - Private key exposed
� CA Compromise - CA key exposed
� Affiliation Changed - Employee left
� Superseded - Replaced by new cert
� Cessation of Operation - Service decommissioned

?? Goal: Update and publish the CRL

?? Why This Matters:
Revocation is useless if clients don't know about it! The CRL is a signed list of revoked certificates that clients download to check certificate validity. Without CRL updates, revoked certs remain trusted.

?? Actions:
1. Click "Update CRL" button
2. Verify CRL contains the revoked certificate
3. Note the CRL update timestamp and next update time

?? CRL Distribution:
� CRL is signed by the CA
� Published at CRL Distribution Point (CDP)
� Clients download periodically to check revocation
� Alternative: OCSP for real-time checking

?? Goal: Create a security administrator role with appropriate permissions

?? Why This Matters:
Role-Based Access Control (RBAC) is a cornerstone of enterprise security. Instead of assigning permissions to individual users (which doesn't scale), you assign permissions to roles, then assign users to roles. This simplifies management and ensures consistent access policies.

?? Actions:
1. Click "Create Role" button
2. Role Name: SecurityAdmin
3. Check permissions:
� IAM Full Access - Manage users and roles
� Security Audit - Review security logs
� Log Viewer - Access system logs
4. Click "Create Role"

?? RBAC Benefits:
� Simplified user management at scale
� Consistent permission enforcement
� Easier auditing and compliance
� Reduced risk of privilege creep

?? Goal: Create a user and assign to the SecurityAdmin role

?? Why This Matters:
Proper user provisioning ensures employees have correct access from day one. Linking users to roles (not direct permissions) means when someone changes departments, you simply change their role - not dozens of individual permissions.

?? Actions:
1. Click "Add User" button
2. Username: alice.johnson
3. Email: alice@techcorp.local
4. Department: Security
5. Assign Role: SecurityAdmin
6. Click "Add User"

?? Provisioning Best Practices:
� Use standardized naming conventions (firstname.lastname)
� Always associate with a role, never direct permissions
� Set account expiration for contractors
� Require password change on first login

?? Goal: Configure MFA to add a second authentication factor

?? Why This Matters:
Passwords alone are not enough - they can be phished, guessed, or stolen. MFA adds a second factor (something you have) that attackers cannot easily obtain. This blocks 99.9% of automated attacks according to Microsoft research.

?? Actions:
1. Click "Configure MFA" button
2. MFA Type: TOTP (Time-based One-Time Password)
3. In a real environment, scan QR code with authenticator app
4. In this simulation, simply click "Enable MFA"

?? Authentication Factors:
� Something you know - Password, PIN
� Something you have - Phone, hardware token
� Something you are - Fingerprint, face scan
� Somewhere you are - Geolocation
� Something you do - Typing pattern

?? Goal: Integrate with enterprise identity provider for SSO

?? Why This Matters:
SSO lets users authenticate once to access multiple applications. This improves security (fewer passwords to manage/attack) and user experience. SAML 2.0 is the enterprise standard for SSO, used by organizations worldwide.

?? Actions:
1. Click "Setup SSO" button
2. IdP Entity ID: https://idp.techcorp.local
3. SSO URL: https://idp.techcorp.local/sso
4. Paste X.509 Certificate (any text for simulation):
-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----
5. Set Name ID Format: email
6. Click "Save Configuration"

?? SAML Components:
� IdP (Identity Provider) - Authenticates users (e.g., Okta, Azure AD)
� SP (Service Provider) - Your application
� Assertion - XML document proving authentication
� X.509 Certificate - Validates assertion signatures