Introduction
Alert Logic® provides network intrusion detection (IDS) capabilities in order to inspect network traffic for signs of attack or compromise within a deployment. It is important to consider various factors when deploying an IDS, such as how traffic will be collected for analysis.
Alert Logic IDS appliances can accept network traffic in two primary ways. The most common method traditionally has been to receive mirrored traffic from a span port that is configured on a network switch. This is most often seen in physical data center or corporate environments. Collecting traffic with the use of an agent is growing in popularity and is the required method of traffic and log collection when deploying in cloud environments.
Both methods work well when properly configured for the environment in which they are deployed. Some customers experience deployment issues when utilizing configurations that are not optimal, but this is easily corrected with proper guidance.
This article highlights some key examples of deployment configurations that should be avoided, including details on making the configuration experience easier and avoiding some common mistakes.
Avoid Overly Large Address Ranges
Customers may not have a list of specific networks or internal address spaces that they are currently using. To ensure that nothing is missed, they may add all RFC1918 address ranges (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12) as a Protected Network (HOME_NET) in the Alert Logic console. While this may ensure that every possible internal address is accounted for, it will result in severely degraded performance.
If /16 or /24 networks are used, you will have more visibility into the health of the network you are monitoring. You will also be able to take advantage of creating collection alert rules, which will alert you when one of your networks stops sending traffic to the Alert Logic appliance.
Recommendations:
- Use /16 or /24 networks to achieve granular visibility into RFC1918 traffic in the Alert Logic console.
Avoid Duplicate Traffic Collection with Agents and Network Spans
In data center deployments, most customers utilize span ports on network switches to mirror traffic to the IDS appliance. This can also be achieved by using network taps. A common problem is that customers will assign a Protected Host agent to an appliance that is already monitoring the host through port mirroring. This results in duplicate traffic being sent to the appliance.
If an agent shows an error state in an environment that is utilizing port mirroring and Protected Host agents, it is important to ensure that the error state is not the result of an agent lacking assignment to an appliance. If that is the case, verify that the host is not already being monitored through port mirroring.
Recommendations:
- When assigning Protected Hosts to an appliance, check if the host is already being monitored via SPAN/tap in the Networks section of the Alert Logic console. You can view or export the list of Networks and confirm that the Protected Hosts you want to monitor are not already being monitored.
Assign Protected Hosts to an Appliance in the Same Location
Assigning Protected Hosts to an IDS appliance that is in a separate geographic location is problematic. The role of an agent is to duplicate traffic it collects from a host and send a copy of that traffic to the IDS appliance. The appliance will then analyze the traffic locally, and for any portion of the traffic that matches a signature from our database, it will create an event. These events get transported to the Alert Logic backend.
This method prevents the gateway from being flooded with duplicate traffic. Similarly, RSPAN forwards a copy of all traffic to the appliance. Therefore, it is important that the appliance is in the same local physical environment to avoid traffic floods at the gateway.
Recommendations:
- Verify that networks/Protected Hosts are assigned to an appliance in the same local physical environment.
Comments
0 comments
Please sign in to leave a comment.