Network Security Analyzer

Network Security Audit and Hardening Plan: SaaS Bookkeeping Platform (HQ and AWS)

1. Risk Summary

Overall rating: Critical

The configuration allows several direct paths to customer bank-account and payroll data:

• Internet to database. MySQL port 3306 is allowed from 0.0.0.0/0 in the application security group, possibly reaching the database directly.
• Internet to office. RDP and SSH are exposed from the internet into the office, and one SSH rule lands on an internal LAN server.
• Office to database. A flat office VLAN is tunneled to the entire AWS VPC. Any compromised workstation, including the finance workstation from the recent phishing incident, may be able to reach RDS on 3306.

Detection is close to nonexistent. The environment has no IDS, no SIEM, no EDR beyond default Defender, and only 7 days of firewall logs. The firewall logs covering the phishing beacon two weeks ago have almost certainly already rotated out. You therefore cannot currently show that the incident was contained, and it should be handled as an open incident rather than a closed one.

2. Assumptions and Gaps (please verify)

3. Attack Surface Map

Internet ingress (pfSense WAN)

AWS ingress

• The ALB in front of the app on 8080 is correctly scoped to the ALB SG.
• 22 and 3306 are allowed from 0.0.0.0/0.

Trust-boundary violations

• DMZ to LAN: allow-all.
• VPN clients to each other: client-to-client allowed.
• Office LAN to entire AWS VPC: no filtering.
• Inside the LAN: the network is flat, so workstations, the DC, the file server, and finance hosts can all reach each other.

Egress

• LAN to any: allow-all. This is how the beacon succeeded.
• AWS app servers to 0.0.0.0/0: allow-all.

Likely attack chains

1. Phished workstation to database. Phished finance workstation → flat LAN → IPsec to 10.20.0.0/16 → RDS:3306 or app servers:22.
2. Internet to domain. Internet → RDP 3389 or SSH 22 (password auth) → LAN host → DC → domain-wide ransomware.
3. Stolen VPN password to everything. Stolen VPN password (no MFA) → LAN plus all other VPN clients → the same paths as chain 1.

4. Findings Table

5. Remediation Plan (prioritized)

Phase 0: Emergency containment (0–48 hours)

0.1 Treat the phishing event as an open incident (F5)

• Stop log loss now. Increase pfSense log size and set up remote syslog (see 2.3) before anything else rotates out.
• Collect what still exists:
  • DC Security logs
  • Defender quarantine details and the MpCmdRun -GetFiles support bundle
  • The workstation's disk and memory image, if it has not been reimaged
  • The beacon destination IP
• Hunt for the beacon IP. Check every source that might still hold it: DNS server logs, Defender Advanced Hunting (if licensed), and AWS VPC Flow Logs (if enabled).
• Reset credentials:
  • The affected user's AD password, VPN password, and any saved browser credentials
  • Kerberos tickets and sessions (klist purge; disable and re-enable the account if needed)
• Review AD for persistence. Look at the last 30 days for new accounts, group membership changes (4720/4728/4732/4756), and new services or scheduled tasks on the host.
• Reimage the workstation. Do not trust AV cleanup.
• If you lack in-house IR capacity, engage a retained IR firm. Findings may need legal review (§6).

0.2 Close database and SSH exposure in AWS (F1, F2)

Before revoking, pull VPC Flow Logs, and RDS logs if enabled, for 3306 and 22 connections from non-VPC IPs. They are evidence for §6.

# Revoke world-open rules
aws ec2 revoke-security-group-ingress --group-id <app-servers-sg-id> --protocol tcp --port 22   --cidr 0.0.0.0/0
aws ec2 revoke-security-group-ingress --group-id <app-servers-sg-id> --protocol tcp --port 3306 --cidr 0.0.0.0/0

# Dedicated DB security group: MySQL only from app servers
aws ec2 create-security-group --group-name rds-mysql-sg --description "MySQL from app tier only" --vpc-id <vpc-id>
aws ec2 authorize-security-group-ingress --group-id <rds-mysql-sg-id> --protocol tcp --port 3306 --source-group <app-servers-sg-id>
aws rds modify-db-instance --db-instance-identifier <db-id> \
    --vpc-security-group-ids <rds-mysql-sg-id> --no-publicly-accessible --apply-immediately

• Replace SSH access with AWS Systems Manager Session Manager, which needs no inbound port. If SSH is temporarily unavoidable, allow 22 only from bastion-sg.
• If there is any evidence of external 3306 connections, rotate the MySQL master and application credentials.

0.3 Remove internet-exposed RDP and SSH (F3, F4)

• Delete the WAN rules and the associated NAT for 203.0.113.13:3389 and 203.0.113.14:22.
• Disable the contractor's account.
• Review the jump box and file server authentication logs (Windows 4624/4625 with logon type 10; /var/log/auth.log) for successful logins from unexpected IPs.
• Remote admins and vendors connect through the VPN with MFA (0.4). Vendor access is time-boxed and just-in-time.
• On the file server, regardless of the above, set the following in /etc/ssh/sshd_config (or a drop-in under sshd_config.d/):

  PasswordAuthentication no
  KbdInteractiveAuthentication no
  PermitRootLogin no
  AllowGroups ssh-admins
  

  Then run sudo systemctl reload ssh and sudo ufw allow from <admin-vlan-cidr> to any port 22 proto tcp, with ufw default deny incoming.

0.4 Harden OpenVPN (F6, F12)

• Enable MFA.
  • Preferred: SAML or RADIUS against your IdP/AD with MFA enforced.
  • Minimum: Access Server's built-in TOTP (Admin UI → Authentication → MFA, or User Management → require TOTP), enforced for all users.
• Disable inter-client communication. Admin UI → Configuration → Advanced VPN → "Should clients be able to communicate with each other?" → No.
• Force re-enrollment of all 20 remote users.
• Exact sacli key names vary by AS version; confirm them against your version's documentation before scripting.

0.5 Cut DMZ-to-LAN allow-all (F11)

• Replace it with explicit rules for what the backup job actually needs. Example: DMZ mail relay → LAN backup server, TCP <backup port>.
• Better still, invert the direction: the backup server pulls from the DMZ, so the DMZ never initiates connections into the LAN.

Phase 1: Tunnel, egress, and detection foundation (week 1–2)

1.1 Rebuild the IPsec tunnel (F8, F9, F10)

• Rotate the PSK to a random secret of 32+ characters, stored in a password vault and never sent by email. Certificate authentication is better if supported.

• Crypto settings. In AWS use modify-vpn-tunnel-options; in pfSense use VPN → IPsec:

  Setting	Recommended value
  IKE version	IKEv2
  Phase 1 cipher / integrity	AES-256, SHA-256 or SHA-384
  Phase 1 DH group	20 (ECP-384); minimum 14
  Phase 2 cipher	AES-256-GCM
  PFS group	20
  Groups to remove	DH 2, SHA-1

  aws ec2 modify-vpn-tunnel-options --vpn-connection-id <id> --vpn-tunnel-outside-ip-address <ip> \
    --tunnel-options 'IKEVersions=[{Value=ikev2}],Phase1EncryptionAlgorithms=[{Value=AES256}],Phase1IntegrityAlgorithms=[{Value=SHA2-384}],Phase1DHGroupNumbers=[{Value=20}],Phase2EncryptionAlgorithms=[{Value=AES256-GCM-16}],Phase2DHGroupNumbers=[{Value=20}],PreSharedKey=<new-psk>'
  

• Scope the tunnel. Narrow the traffic selectors, and enforce filtering on the pfSense IPsec interface rules and AWS SG/NACLs. Selectors alone are not access control.

  • Office admin VLAN → bastion (or nothing, if you use SSM) on the required ports only.
  • No office subnet may reach RDS.
  • pfSense IPsec tab: pass specific source VLAN → specific AWS host:port, then a final block with logging.

1.2 Egress filtering on pfSense LAN (F14)

Replace pass LAN_net → any with the following, evaluated top to bottom:

• Delete the redundant icmp from any rule (F21). If ICMP is needed, allow echo-request from LAN_net only.
• Add DNS-layer threat filtering: pfBlockerNG on pfSense, or any protective DNS service. The DC forwards to it.
• Apply the same model to the DMZ (F22): each DMZ host gets only the egress it needs, e.g. the mail relay → 25 outbound.

1.3 Deploy IDS/IPS (F15)

• Install Suricata on pfSense on the LAN (inside) and WAN interfaces.
• Start with the ET Open ruleset in alert mode, tune for 1–2 weeks, then switch to inline IPS for high-confidence categories (malware, C2, exploit, policy/TOR).
• Once VLANs exist (Phase 2), put a sensor on inter-VLAN traffic.

1.4 AWS detection and hardening (F19, PCI 10/11)

• Enable GuardDuty (including RDS Protection), CloudTrail (all regions, log file validation), VPC Flow Logs, and Security Hub with the PCI DSS standard.
• Restrict app-servers-sg egress to:
  • rds-mysql-sg:3306
  • 443 to required endpoints only, using VPC endpoints for AWS services where possible
• If broad outbound is required, consider Route 53 Resolver DNS Firewall or AWS Network Firewall.
• RDS:
  • require_secure_transport=ON in the parameter group
  • Encryption at rest (verify it is enabled)
  • Deletion protection, automated backups, and a cross-account snapshot copy
  • Enable the audit log, or the general/slow logs, and export to CloudWatch

1.5 OpenVPN cipher and least privilege (F13)

• Upgrade Access Server to the current release.
• Set data ciphers to AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305 and remove BF-CBC.
• Clients older than OpenVPN 2.4 must be upgraded.
• Use Access Server group ACLs so finance users reach finance resources and admins reach the admin VLAN. Nobody gets the whole LAN by default.

Phase 2: Segmentation and endpoint hardening (≤30 days)

2.1 VLAN segmentation (F7)

Route between VLANs on pfSense (router-on-a-stick) so every inter-VLAN flow passes through firewall policy and Suricata. The example assumes an L2-only 2960.

vlan 10
 name MGMT
vlan 20
 name SERVERS
vlan 30
 name FINANCE
vlan 40
 name STAFF
vlan 50
 name VPN-POOL
vlan 999
 name BLACKHOLE
!
interface range Gi0/1 - 12
 description FINANCE-WS
 switchport mode access
 switchport access vlan 30
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable
!
interface Gi0/48
 description UPLINK-pfSense
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30,40
 switchport nonegotiate
!
! Unused ports
interface range Gi0/40 - 47
 switchport access vlan 999
 shutdown
!
ip dhcp snooping
ip dhcp snooping vlan 10,20,30,40
interface Gi0/48
 ip dhcp snooping trust
ip arp inspection vlan 10,20,30,40
! DAI will drop traffic from any static-IP host that has no binding: add ARP ACLs for static-IP hosts first
!
! Management hygiene
ip ssh version 2
line vty 0 15
 transport input ssh
 access-class MGMT-ONLY in
no ip http server
no ip http secure-server

Inter-VLAN policy on pfSense (default deny between all VLANs):

• STAFF and FINANCE → SERVERS: only AD ports (53, 88, 135, 389/636, 445 to the DC, 464, 3268/3269, dynamic RPC as needed) and 445 to the file server.
• FINANCE ↔ STAFF: deny.
• Workstation ↔ workstation within a VLAN: block SMB/RDP/WinRM with Windows Firewall GPO (see 2.2), because the firewall does not see intra-VLAN traffic.
• MGMT: the only VLAN allowed to reach switch/pfSense management, RDP/SSH to servers, and the AWS admin path.
• VPN-POOL: treated like STAFF/FINANCE according to the user's group.

2.2 Endpoint and AD hardening (F17, F18)

• Windows 10. Upgrade to Windows 11 or enroll in ESU immediately, and isolate any stragglers.
• Patching. Establish a patch SLA: critical fixes within 14 days, others within 30 days (align with PCI 6.3.3).
• EDR. Deploy an EDR with 24×7 monitoring (MDR if staff is limited). If you stay on Defender, move to Defender for Endpoint P2 or equivalent. At minimum turn on:
  • Tamper Protection
  • Cloud-delivered protection at High
  • Network Protection in Block mode
  • Controlled Folder Access for finance users
  • ASR rules in Block mode, especially "Block credential stealing from LSASS", "Block Office child processes", "Block executable content from email", and "Use advanced protection against ransomware"
• Windows Firewall GPO. Deny inbound 445, 135, 3389, and 5985/5986 on workstations except from the MGMT VLAN.
• Credential hygiene:
  • Windows LAPS for local admin passwords
  • Separate admin accounts, with no domain admin logons on workstations (tiering)
  • Protected Users group for privileged accounts
  • Credential Guard
• Legacy protocols. Disable LLMNR, NetBIOS-NS, SMBv1, and NTLMv1. Require SMB signing.
• File server (Samba). server min protocol = SMB3, server signing = mandatory, share ACLs by AD group. Snapshot-capable storage (ZFS/LVM/Btrfs snapshots) for rapid ransomware rollback.

2.3 Centralized logging and alerting (F16, F20)

• Stand up a SIEM or log platform: open-source options such as Wazuh, Security Onion, or Elastic, or a managed SIEM/MDR.

• Retention: 12 months, with 3 months immediately searchable (PCI 10.5.1).

• Sources:

  • pfSense firewall logs and Suricata alerts (Status → System Logs → Settings → Remote logging)
  • DC and server logs via Windows Event Forwarding plus Sysmon
  • Linux auth logs
  • OpenVPN AS logs
  • CloudTrail, GuardDuty, VPC Flow Logs, RDS logs

• Minimum alert set:

  Signal	Source
  Failed logon bursts / password spraying	4625, 4771
  Account lockouts	4740
  Privileged group changes	4728/4732/4756
  New services	7045
  Log cleared	1102
  Kerberoasting	4769 with RC4 encryption
  VPN logins from new countries	OpenVPN AS
  Suricata C2/malware hits	Suricata
  GuardDuty High findings	GuardDuty
  RDS logins from non-app hosts	RDS logs

Phase 3: Resilience and governance (≤90 days)

• Backups (F24):
  • Follow 3-2-1 with an immutable or offline copy, e.g. S3 Object Lock in a separate AWS account, or an offline or immutable backup appliance.
  • Back up AD using system-state backups.
  • Run quarterly restore tests and document them as SOC 2 Availability evidence.
• Infrastructure lifecycle (F23):
  • Upgrade pfSense to the current supported release.
  • Confirm the 2960's support status and plan replacement if it is past end-of-support.
  • Maintain a hardware/software inventory (PCI 12.5.1).
• Bastion. Retire it in favor of SSM Session Manager with session logging to S3/CloudWatch, or lock its SG to VPN egress IPs plus MFA.
• Vulnerability management.
  • Quarterly internal and external scans; external scans by an ASV if card data is in scope (see §6).
  • Annual penetration test that includes segmentation testing (PCI 11.4.5).
• Change control. The stale RDP rule and the "temporary" SSH rule both come from a missing change-control process. Require an owner, ticket, and expiry date on every firewall and SG rule, with semi-annual rule reviews (PCI 1.2.7, SOC 2 CC8.1).
• Awareness. Run phishing simulations and a one-click "report phish" button.

6. Findings Requiring Compliance or Legal Review

1. Possible data exposure (F1, F5). If RDS was publicly accessible with 3306 open, or if the phishing incident cannot be ruled out as a data compromise, counsel should assess obligations under:

   • State breach-notification laws
   • Customer contracts
   • Nacha rules (for ACH data)
   • Card-brand and acquirer notification (if PCI applies)

   Preserve evidence (Flow Logs, RDS logs, CloudTrail, DC logs) under counsel's direction before making further changes wherever possible.

2. PCI DSS applicability. PCI DSS governs payment card data (PAN). Bank account and routing numbers for ACH are not cardholder data by themselves. The Nacha Supplementing Data Security Requirements and possibly GLBA/FTC Safeguards Rule are more directly applicable to them. Confirm with your QSA or counsel whether any card data is handled.

   • If card data is handled, the flat LAN plus the whole-VPC tunnel puts the entire office in CDE scope, and segmentation (Phase 2) is the main lever to reduce it.
   • If no card data is handled, the controls above are still appropriate and map closely to SOC 2 CC6/CC7 and Nacha's requirements.

3. SOC 2 Type II observation period. These issues exist during your audit window. Remediate and document them (dates, tickets, evidence) and disclose them to your auditor as exceptions or management responses. Silently fixing them without documentation creates a worse finding.

4. Contractor access (F3). Review the contract and NDA terms for the vendor whose RDP rule was left open, and whether their access and activity must be reported or audited.

5. Email-shared PSK (F8). Determine who received that email and whether it sits in any external or personal mailbox. This may affect incident scoping.

7. Quick Wins (highest risk reduction for lowest effort)

1. Close the AWS world-open rules and make RDS private. Revoke 22 and 3306 from 0.0.0.0/0, attach a dedicated rds-mysql-sg that allows 3306 only from app-servers-sg, and set RDS to not publicly accessible. This takes about 15 minutes and removes the most direct path to customer financial data. Capture Flow Logs first.
2. Delete the WAN RDP (3389) and SSH (22) rules and NATs on pfSense. This takes about 5 minutes and eliminates the two most common internet-to-ransomware entry points. Route vendor and admin access through the VPN.
3. Enforce MFA on OpenVPN and disable client-to-client. This takes about an hour plus user re-enrollment. It neutralizes stolen or phished passwords, the exact attack you just experienced, as a path into the LAN.

Immediately after these three, configure remote syslog on pfSense so you stop losing forensic evidence, and replace the DMZ-to-LAN allow-all rule.