Learn PPTP - Hardening (If It Must Be Retained)

#Introduction

Sometimes a PPTP server cannot be shut down yet — an old vendor still depends on it, or migration needs time. In that situation, you must do the best you can. Episode 15 covers hardening: closing configuration gaps as much as possible.

But there is one sentence you must remember from start to finish in this episode: hardening does not remove PPTP's fundamental weaknesses. All of the steps below are temporary risk reduction, not a solution.

#Authentication and Encryption Baseline

#Closing Weak Methods

The first step is to force the strictest configuration PPTP supports. In /etc/ppp/options.pptpd:

name pptpd
require-mschap-v2
require-mppe-128
refuse-pap
refuse-chap
refuse-eap
refuse-mschap
nobsdcomp

require-mschap-v2 and require-mppe-128 force all clients to use the strongest authentication and encryption PPTP has. refuse-pap, refuse-chap, refuse-mschap, and refuse-eap close the weaker alternative paths. After changing this file, restart the service and verify that no client is still using old methods.

#Strong Password Policy

Because the MPPE key is derived from the password, the password policy is the front line of defense. Require long, unique passwords for every user, and revoke access for inactive users.

#Verification After Restart

After restarting the service, make sure connected clients truly use 128-bit MPPE. The pppd log records the negotiation result of every session:

sudo journalctl -u pptpd | grep -i mppe

journalctl -u pptpd | grep -i mppe shows the encryption negotiation lines for every session. If a client connects without MPPE, immediately check the client options and server policy — a client that refuses MPPE should be denied entry, not downgraded.

#Firewall Rules

#Restricting Access Sources

The firewall should only accept connections from addresses that are actually entitled to connect:

sudo iptables -A INPUT -p tcp --dport 1723 -s 203.0.113.0/24 -j ACCEPT
sudo iptables -A INPUT -p gre  -s 203.0.113.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 1723 -j DROP
sudo iptables -A INPUT -p gre  -j DROP

The four rules above allow TCP 1723 and GRE only from the 203.0.113.0/24 subnet, then drop the rest. iptables -A INPUT -p tcp --dport 1723 -s 203.0.113.0/24 -j ACCEPT is the allowlist pattern that must be applied to both protocols at once — not just TCP 1723.

#Network Isolation

#Segregation with VLANs

If possible, place all PPTP servers in a dedicated network segment. With VLAN isolation, the PPTP server and its clients do not mix with the main production network.

sudo ip link add link eth0 name eth0.200 type vlan id 200
sudo ip addr add 10.10.20.1/24 dev eth0.200
sudo ip link set eth0.200 up

The example above creates VLAN 200 with address 10.10.20.1/24. The concept: all PPTP traffic is confined to this VLAN, and access to other networks is governed by strict routing and firewall rules.

#Monitoring

#Logging and Monitoring Sessions

Every session must be recorded and monitored. Make sure logwtmp is active in pptpd.conf, and monitor the logs regularly:

sudo journalctl -u pptpd | grep -iE "auth|fail|error"

journalctl -u pptpd | grep -iE "auth|fail|error" helps detect suspicious authentication attempts. Combine it with RADIUS accounting (episode 11) for complete usage records.

#Signs of Attack

Some log patterns deserve attention: authentication attempts from many IP addresses in a short time, many failures from a single source, and a surge of GRE connections without a valid control session. These patterns can indicate brute-force attacks or exploitation.

Use fail2ban or a simple log parser to alert automatically when such patterns appear. Remember, detection only shortens the exposure window — fundamental weaknesses must still be answered with migration, not just monitoring.

#Caveat: Hardening Is Not a Solution

#Reducing, Not Eliminating Risk

It must be said honestly: no configuration combination above stops the offline attack on MS-CHAPv2 or removes the RC4 weakness. An attacker who can sniff traffic still has the material to crack credentials.

Therefore, treat hardening as a temporary measure. Start the migration process at the same time you apply these steps. Episode 19 will provide structured migration guidance.

#Closing

Episode 15 provided a list of hardening steps: authentication and encryption baseline, firewall allowlists, VLAN isolation, and monitoring — with the constant reminder that all of this is only temporary risk reduction.

Key takeaways:

• Require require-mschap-v2 and require-mppe-128 in options.pptpd.
• Close weak authentication methods with refuse-*.
• The firewall must restrict TCP 1723 and GRE to allowed sources only.
• Isolate the PPTP server on a dedicated VLAN to limit attack reach.
• Monitor authentication logs and suspicious attempts regularly.
• Hardening does not remove PPTP's fundamental weaknesses.

In the next episode, episode 16, we will discuss NAT traversal and firewall issues — why GRE is not NAT-friendly, the role of ALGs in routers, iptables and nftables configuration, and source IP restrictions.