32.6 Network Hardening: Segmentation, VPN and IDS/IPS

alert tcp any any -> $HOME_NET 22 (msg:"Possible SSH brute force"; flags:S; threshold:type both, track by_src, count 10, seconds 60; sid:1000001; rev:1;)
alert http any any -> $HOME_NET any (msg:"SQLi attempt - UNION SELECT"; content:"union"; nocase; content:"select"; nocase; sid:1000002; rev:1;)

sudo yum install -y suricata               # from EPEL on RHEL-family systems
sudo suricata-update                       # download the free Emerging Threats ruleset
sudo nano /etc/suricata/suricata.yaml      # set HOME_NET to "[192.168.56.0/24]" and the right interface
sudo systemctl enable suricata
sudo service suricata start
sudo tail -f /var/log/suricata/fast.log    # alerts appear here

Real incident: FortiBleed – stolen VPN and firewall logins used to lock admins out of FortiGate devices (Oct 2026)

1. What happened

On 6 October 2026 the FBI and the U.S. Secret Service issued an advisory warning that the FortiBleed campaign is still active against Fortinet FortiGate firewalls and SSL VPN gateways that are open to the internet. In some cases the attackers created their own administrator accounts and then deleted the real admin accounts or changed their passwords, so the owners were locked out of their own firewall. The FBI says this attack chain has been used as an entry point for ransomware affiliates, and public reporting names the INC/Lynx and Payload ransomware groups. FortiBleed is not a new software bug: Fortinet said in June 2026 that the activity reuses credentials from earlier incidents and brute-forces devices with weak passwords and no MFA. It was first found in June 2026, when the attackers accidentally exposed a server holding usernames and plaintext passwords for 73,932 firewall URLs in 194 countries; by SOCRadar's latest count, 86,644 devices have been compromised. Educational framing only.

2. How the hack happened (public reporting only – high-level)

1. Automated scripts scanned the internet for FortiGate admin pages and SSL VPN login portals that anyone could reach.
2. The attackers tried already-leaked logins – from old breaches, from infostealer malware logs, and through credential stuffing and password spraying. Devices with no MFA and passwords never changed let them in.
3. Once inside, they copied more login data from the device, including stored password hashes. Older devices kept admin passwords in a weaker SHA-256 format.
4. They cracked those hashes offline on a GPU cluster with Hashcat (the same tool from Ch.22 – here used by criminals), which gave them even more working logins.
5. They added their own admin account and removed or changed the real admins' passwords, so the company could not get back into its own firewall.
6. They set up persistence, tried to move deeper into the network, and packaged the working VPN access for sale – ransomware gangs used it as their way in.

3. How to stop it / defend (this lesson: segmentation, VPN and IDS)

• Never put the firewall's admin page on the internet. Admin access only from an internal management network, a separate admin VPN, or a short allowlist of IPs.
• MFA on every VPN and admin login, preferably phishing-resistant, so a leaked password alone does not open the door.
• Change every password after any leak, remove default and old accounts, and check whether your company's logins appear in breach or infostealer reports.
• Upgrade the firmware to a version that stores admin passwords with PBKDF2 (FortiOS 7.2.11, 7.4.8, 7.6.1 or later), and make every admin log in once again after the upgrade – the old SHA-256 hash is only replaced at the next login.
• Alert on the dangerous events and send them to the SIEM (Ch.31): a new admin account, an admin deleted, a config export, and many failed VPN logins from one source (the same idea as the SSH brute-force rule above).
• Segment behind the VPN, so a VPN user reaches only the systems they need, not the whole office network.
• If you are hit, patching is not enough: end all admin and VPN sessions, reset every credential, review accounts and logs for changes, and then close internet access to management.

4. How to take care so it won't happen again (checklist)

• [ ] Check from outside (for example with nmap from a home connection) that the firewall admin page is not reachable from the internet.
• [ ] Turn on MFA for every VPN user and every firewall admin.
• [ ] After a firmware upgrade, make sure every admin has logged in again so the stronger hashing is used.
• [ ] Keep at least two admin accounts and a written "locked out of the firewall" recovery plan, with an offline config backup.
• [ ] Review the admin account list and the VPN login logs every week.
• [ ] India students: many offices and colleges here run FortiGate or similar firewalls at the edge – the same checklist applies, and report incidents to CERT-In within the required time (see Ch.34).

Source: FBI and U.S. Secret Service, "FortiBleed Operations Continue Targeting Exposed Systems Leading to Reports of Lockouts", advisory dated 6 October 2026 (IC3); BleepingComputer, Bill Toulas, "FBI: Ongoing FortiBleed attacks lock out FortiGate VPN admins", 7 October 2026; Help Net Security, "FortiBleed is still active, with attackers locking admins out of Fortinet firewalls", 7 October 2026; Fortinet PSIRT blog, Carl Windsor, "Analysis of Reported Credential Compromise of FortiGate Devices", 19 June 2026; SOCRadar, "What Is FortiBleed?".

Check if you're safe: Password Strength Checker

Real incident: Ivanti Connect Secure zero-day CVE-2026-104935 – VPN login bypass used to steal credentials and data (Oct 2026)

1. What happened

On 13 October 2026, Ivanti released fixes for CVE-2026-104935, an authentication bypass in its Connect Secure VPN (CVSS 8.6, high). It lets a remote attacker with no login run commands on the VPN appliance. The same day CISA added it to its Known Exploited Vulnerabilities (KEV) catalog and said attackers were using it for credential theft and data exfiltration. BleepingComputer reported attacks since at least 1 October. Affected versions are 25.1.1.1 and earlier, 25.1.2.2 and earlier, and 22.8R2.4 and earlier; fixed versions are 25.1.1.2, 25.1.3.0, 25.1.3.1 and 22.8R2.5. Ivanti says it is aware of limited exploitation, and a fix for a related privilege-escalation flaw used in the same chain is still coming. CISA warns that Ivanti's Integrity Checker Tool may miss the attack, because the attacker's commands run in memory.

2. How the hack happened (public reporting only – high-level)

1. The company's Ivanti VPN sits on the internet, running an unpatched version.
2. The attacker sends crafted requests that skip the login check.
3. The attacker runs commands on the appliance without any username or password.
4. The commands run in memory, so file-based checks such as the Integrity Checker may show nothing.
5. From the VPN the attacker collects logins of users and admins.
6. The attacker uses that position to take data out of the network.

3. How to stop it / defend (this lesson: Network Hardening, Segmentation, VPN and IDS/IPS)

• Patch internet-facing VPNs first and fast. A KEV entry means "patch within days, not months".
• Know your edge devices. Keep a list of every VPN, firewall and gateway, with its version and owner.
• Segment behind the VPN. VPN users should reach only the networks they need, not the whole flat network.
• Send VPN logs to the SIEM. Alert on odd admin logins, new sessions from strange places and unusual outbound traffic.
• Don't trust only the vendor checker. If you were exposed, do network and memory forensics as CISA advises.
• Rotate credentials that passed through the VPN – user passwords, admin accounts, certificates and keys.

4. How to take care so it won't happen again (checklist)

• [ ] Check your Ivanti Connect Secure version today and upgrade to a fixed version.
• [ ] Plan the move off 22.8 – it reaches end of life on 31 January 2027.
• [ ] Subscribe to vendor advisories and the CISA KEV list for every edge device you own.
• [ ] Keep the VPN admin page off the public internet.
• [ ] Review VPN and SIEM logs back to 1 October for unusual activity.
• [ ] After patching, reset VPN user and admin passwords and enforce MFA.
• [ ] India students: many Indian companies use Ivanti VPNs – report major incidents to CERT-In within the required time (see Ch.34).

Source: CISA, "CISA Urges Patching Newly Exploited Vulnerability in Ivanti Connect Secure", 13 October 2026; CISA KEV catalog entry CVE-2026-104935 (added 13 October 2026); Ivanti, "October 2026 Patch Tuesday"; BleepingComputer, "CISA warns admins to immediately fix Ivanti flaw exploited as zero-day", October 2026.

Check if you're safe: Password Strength Checker