DDoS prevention scheme based on Synproxy PF under FreeBSD

Summary
This article describes the FreeBSD5.3 Down PFSynproxy's DDoS mitigation scheme is an available option for small and midsize businesses to withstand attacks of 30,000 packets per second.

Doubt 30,000 ......

Environment
Firewall: Desktop P4 2g,512 memory.FREEBSD5.3
Web server: Notebook PIII 256m, SUSE Linux Enterprise Server 9
Attack machine: Notebook: PIII 256M, WIN2000 SERVER
Attack Tool: Hgod v0.4
Test machine: Notebook: PIII 700

Topology:
=====
Firewall: xl0 External network card: 172.16.0.1; SIS0 Internal network card: 192.168.100.1
Web server: eth0 192.168.100.2
Attack aircraft: 172.16.0.194
Test machine: 172.16.0.195

First, compile the kernel
#cd/usr/src/sys/i386/conf
#cp GENERIC billy-PF
#vi billy-PF
Add to:
DevicePF
Device Pflog
Device Pfsync
Options ALTQ
Options ALTQ_CBQ # Class Bases Queuing (CBQ)
Options altq_red # Random Early Detection (RED)
Options Altq_rio # RED In/out
Options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC)
Options Altq_priq # Priority Queuing (Priq)
Options ALTQ_NOPCC # Required for SMP Build
#config billy-PF
#cd: /compile/billy-PF
#make Depend;make make Install
Second, edit the startup script/etc/rc.conf
PF_enable= "YES" # EnablePF(Load module if required)
PF_rules= "/etc/PF. conf "# Rules definition file forPF
PF_flags= "" # Additional flags for PFCTL startup
Pflog_enable= "YES" # Start PFLOGD (8)
Pflog_logfile= "/var/log/pflog" # where PFLOGD should store the logfile
Pflog_flags= "" # Additional flags for PFLOGD startup

Gateway_enable= "YES"

Third, modify the/etc/PF. conf
ext_if= "Xl0"
int_if= "Sis0"
internal_net= "192.168.100.1/24"
External_addr= "172.16.0.1"
Web_server= "192.168.100.2"
Nat on $ext_if from $internal_net to any ($ext_if)
# ($ ext_if): If you are using DHCP to also configure external addresses, there is a problem with not enclosing them. If your assigned IP address changes, NAT will still use the old IP address to translate the packets out. This causes the external connection to stop working. To solve this problem, you should enclose the interface name in parentheses, tellingPFThe conversion address is automatically updated.
RDR on $ext_if Proto TCP from all to $EXTERNAL_ADDR/32 Port $web_server Port 80
#这一行重定向了TCP端口80 (Web server) traffic to the internal network address $web_server. Therefore, even if the $web_server is inside the network behind the gateway, it can still be accessed externally.
Pass in on $ext_if Proto TCP from all to $web_server port, S/sa synproxy State
#连到外部地址的80端口, Synproxy to prevent DDoS attacks

Four, modify the 192.168.100.2 gateway IP is 192.168.100.1

V. Modification of/ETC/SYSCTL.CONF
Net.inet.ip.forwarding=1
IP forwarding of the firewall

Restart

VI. Testing
Access the http://172.16.0.1/index.html before attacking, normally opening the home page on the Web server
Attack:
Launch a DDoS attack on port 80 of the external IP172.16.0.1 of the firewall.
Hgod 172.16.0.1 80
Observe the 80-port connection and the number of packets received on the Web server 192.168.100.2.
Counts the attack strength (packets per second) on the firewall.
speed.sh
#!/bin/sh
Oldval=0
Curval=0
While True
Do
Curval= ' Netstat-i | grep xl0 | head-1 | awk ' {print $} '
if [$oldval = 0]; Then
Old=$curval
Else
echo ' Date ' pkg inbound rate on Xl0: $ (($curval-$oldval)) PPS "
Oldval=$curval
Fi
Sleep 1
Done
`


Vii. test Results

Under DDoS attacks, the firewall receives a packet rate of: 26,000-28,000 packets per second
InPFProtection, only DDoS attacks, the Web server did not receive a package, indicating that the firewall completely blocked the illegal packets.
When you remove Synproxy protection, the last rule, the Web server receives a packet crash rate that is equivalent to the packet received by the firewall. The Web server was denied access.
InPFUnder protection, web_server access is normal.

Conclusion:
Based onPFAnti-DDoS attacks are excellent for attacks up to 30,000 packets per second. For larger traffic attacks, further testing is needed.

Further work:

Combined with the red algorithm in ALTQ, the connection Chao is protected against attack.
While interception PF for illegal IPs can be useful, it is also important for Chao attacks on full TCP connections, and the next article will describe how to use the red (Random Early Detection) algorithm to properly protect legitimate users. Use the 28 principle to differentiate the user's legitimacy. When the legitimacy of the connection cannot be differentiated on the surface, it can only be sacrificed at the expense of the user who has suddenly come to visit.

The third sword, which protects the server from running without downtime, can also be combined with load balancing to enhance the high availability of the Web server.