This article provides best practices to optimize Alert Logic IDS appliances performance using targeted network traffic exclusions.
For system specification recommendations based on your general network throughput, see the following tables:
To help prevent traffic drops, Alert Logic recommends creating a default whitelist in customer environments to filter out traffic with low security value. To see the list, go to Configure > Deployments > (Your Deployment), and then click the Network IDS Exclusions tab from the left-hand blade.
Monitoring the network perimeter is paramount. In cloud environments, the cost of spinning up new appliances to handle the load often times outweighs the utility of ingesting low-value traffic. Whether it is for authentication, web servers, firewalls, or end-user devices, Alert Logic wants to monitor for attacks as close as possible to their point of origin. This traffic is so important that we want to ensure it is received and analyzed, but an overloaded appliance turns this into a dice roll.
In-depth defense is critical. Certain ports and programs should never be exposed to public traffic without some form of access control. We recommend for customers to scan for exposed services and verify that logging is set up correctly. Logs will often show context not available in the traffic itself.
Below are the types of traffic Alert Logic recommends for exclusion, as well as compensating controls that provide in-depth defense:
Databases
Due to their potential for high traffic volume and typical insulation from the network perimeter, we recommend protection of databases through other methods:
-
Database audit logging, including standard OS logging (if available), using either the agent or a remote collector.
-
Application-level controls, especially if the application is available through an HTTP API. A web application firewall or web log analytics provide increased visibility into application attacks affecting the database, such as SQL injection.
-
Monitoring perimeter web servers with IDS is recommended to identify attacks such as SQL injections.
| Database | Ports | Compensating controls |
| Microsoft SQL Server | 5022 |
|
| Cassandra | 7199, 9042 |
|
| MongoDB | 27017 |
|
| Oracle Database | 2483, 2484 |
|
Storage, backup, and file shares
File transport and storage is not the ideal way to catch attacker activity, but it does produce lots of false positives when the contents of files could be inadvertently related to IDS rules, endpoint protection software, or antivirus software. When monitoring these items, we recommend instead utilizing our remote log ingestion capabilities (linked below).
| Storage / backup / file shares | Ports | Compensating controls |
| iSCSI | 860, 3260 | |
| Veeam | 902 | |
| NFS | 2049 | Remote log ingestion |
| Amazon S3 | (whitelisted by IP range) |
Data caching and control
Best practices typically advise not to expose data caching, streaming, or the Kubernetes control plane components to the open internet. Instead, if monitoring is desired, we recommend remote log ingestion. In the case of Kubernetes, the container agent will ingest control plane logs by default. The Alert Logic scan appliance also detects any openly exposed instances of these services.
| Data caching and control | Ports | Compensating controls |
| Redis | 6379 |
|
| Apache Kafka | 2181, 8082, 8083, 8088, 9092, 9093 |
|
| Memcached | 11211 |
|
| Kubernetes control plane | 2379, 2380, 6443, 10250, 10256, 10259 |
|
VPN traffic
Due to it being encrypted, ingesting IPsec traffic is unnecessary and would congest the CPU threads used for more important traffic.
| VPN | Ports | Compensating controls |
| ESP-encapsulated IPsec traffic | n/a | n/a |
If you have any questions or concerns, or would like help optimizing your security posture, contact our Support Team at support@alertlogic.com
Comments
0 comments
Please sign in to leave a comment.