Juniper’s SRX family offer the ability to perform much more than firewalls, access-lists, and NAT. As a part of their Unified Threat Management suite (UTM), Intrusion Detection and Prevention (IDP) is a vital part to a layered approach to security. This post is part one of a few I plan to produce. We will explore design considerations, deployment in the branch, managing your IDP with JUNOS space, and creating custom attack objects.
IDS and IPS can have a good and bad reputation depending on who you speak to. It is a sworn must have by some and sworn at by others. This is due I believe, in part that IDS and IPS technologies require a sound knowledge of application and the TCP/IP model. Knowing how an application communicates is just as important as to how it operates. By leveraging this knowledge, you increase your chances at a successful IDS or IPS deployment.
We have ACLs’ Firewalls, Application Firewalls, which all amount to protection from L2 to L7. Why do I need to add IDS or IPS to this? Think about currently practice. You have ACL’s which help span layers 2 with VACL’s or MACL’s to 3 with SRC and DST IP and finishing at layer 4 with port information. Firewalls work at layers 3 and 4 controlling state information to build sessions. This is controlled by allowing to and from based on port. Application firewalls denote how an application is allowed to communicate and includes actions based on certain happenings. Where an IDS/IPS shines is payload inspection. By looking into the payload an IDS/IPS can determine if that GET request is malicious or heading to a well-known Command and Control server.
The above image is sums up the previous paragraph. At a glance you can see you are providing a layered approach to your security portfolio. I would recommend visiting your environment and considering what you have and what you could do. Sure, there are outside forces that might sway purchase but what can you do to add a layer to your network security.
In the land of IDP technologies, Application contexts are configured to match certain parts of an application. This aids in the detection of attacks. HTTP is a great example and very commonly scanned signature. You can choose to look at such applications request like ‘http-header-user-agents’ or ‘http-header-accept-language’ and based on results you can perform an action on the packet. By being in control and aware of the payload within a packet you are in a powerful position to customize application contexts and how they look at an attack.
My 5 Considerations regarding IDP technology
These are in no particular order.
- Identify the assets that require protection including the scope and creation of targeted policies.
- When using a deployment methodology it is wise to consider where it is place – in line or out-of-band – and the subsequent impact domain.
- IPS/IDS technologies that make up the IDP suite are only one layer in the overall security onion. There is no one magic solution to your layered security environment. The diagram earlier highlights each technologies place and how you can build depth.
- Do no apply IDP technology to every policy you have. CPU and Memory are what drives the signature engine and resources are finite. Think about traffic flow and what is residing behind it? You may not need to perform IDP on a vMotion network or zone!
- Update. Keep your platform up to date. Your signatures, device code, rule-base and policies all benefit from being up to date. Every day new attacks and exploits are thrust at Internet edge and desktop end points. Safe safe!
This post is only a tip toe into the water when it comes to design but it’s the entrée to a series that aims to give you more insight into IDP solutions. The next post will look at the SRX in particular, the modes it operates in and downloading and install the IDP solution.