On This Page
Attack Surface Reduction
Attack Surface Reduction is the first principle of designing secured architectures. The best protection against attacks from aggresive Internet is to close any ability for malicious users to attack the system or services (access to admin part, SSH, FTP, RDP, etc.)
Usually this priniciple began to use when something wrong already happened. Although it may and must be defined during architecture design phase or at last at first deployment.
Firewall is the first tool for attack surface reduction. Most of technical staff forget about it. And even if remember, firewalls usually configured to filter only INPUT traffic. Only small amount of system filters OUTPUT traffic as well although it is also important to control what external resources does the server use to interchange data. If OUTPUT traffic is not filtering, attacker just need to find a way to perform malicous code on the server (SQL Injection, Shell Injection or infect the machine in advance) and pull data from the server to any location. Just recently we participated in investigation of the incident when the system was infected by fired admin and send periodically data from business system to suspicious address in Internet.
There is typical architecture on the right left picture: web site, admin part to web site (/admin), database. 3 groups of users: anonymous and registered users, managers, techinical support. Definitely you will have much complex architecture, but this example will give understanding how to protect the system.
Requirements
Before touching servers (much better on the architectural phase) it's very good practice to take a pen and creat list of access requirements to user groups, external services, firewall rules to each area. Most of web systems work with predefined list of external Internet services and rules for filtering output traffic can be created as well.
Below is an example of table with access requirements:
Server/device | Traffic direction | Ip Address | Port | Comment |
---|---|---|---|---|
Web Server | IN | All | 80(TCP) | HTTP access to web site |
IN | All | 443(TCP) | HTTPs access to web site | |
IN | Static Ip addresses of technical support | 22 or 3389(TCP) | SSH or RDP access to the server | |
OUT | DB Server Ip | Db Server Port (3389 or 3306) | Access to database | |
OUT | DNS Server Ip | 53(UDP) 53(TCP) |
Access DNS Service | |
OUT | 123(UDP) | NTP services for time sync | ||
Protected folder (/admin) | IN | Static Ip address of tech support Static Ip address of VPN Server |
Limit access to admin part of the web site | |
DB Server | IN | Web server Ip address | DB Server Port (3306) | Access to database from web servers |
OUT | DNS Server Ip | 53(UDP) 53(TCP) |
Access DNS Service | |
OUT | 123(UDP) | NTP services for time sync | ||
VPN Server | IN | Managers Ip Address Range | 500 and 4500 | L2TP/IPSec, L2TPv3 |
IN | -//- | 443, 992 и 5555 (TCP), 1194 (UDP) | OpenVPN | |
IN | -//- | 1723 (GRE) | PPTP | |
OUT | DNS Server Ip | 53(UDP) 53(TCP) |
Access DNS Service | |
OUT | 123(UDP) | NTP services for time sync | ||
OUT | Web servers Ip address | 443(TCP) | Access to web servers |
So after this step you will have the base list of firewall rules for the first configuration as well as for regular checks.
Linux Firewall
Please see our expertize how to Configure iptables on LinuxSee Also
Published on May 15, 2017