Friendly IPS Appliance and Layered Switch (Cisco IPS and Catalyst 6500)

Good day to all!
In this article I would like to share my experience in one not very trivial question: how to connect box IPS to a multilevel switch in Inline mode. It will be about the “iron” version of IPS in the form of an appendix (a separate box) and about its Inline implementation. The article is mainly focused on Cisco equipment: IPS 4510 and Catalyst 6500.


The task, from the point of view of implementing best practices and recommended designs, would seem to be typical: in any whitpaper with a security design, almost every functional segment of the campus network must certainly be “covered” »IPS system. But in practice, the introduction of IPS in a segment, the core of which is implemented on an L3 switch, covers a number of unobvious subtleties, tricks and pitfalls.
The article is a description of a solution that has been developed, tested, implemented and has been successfully operated for more than a year.

In the course of the article, I will go from simple to complex. First, I’ll describe the general theory a bit, go over the operating principles and methods for connecting IPS systems, and, of course, I will describe the circuit itself and give an example configuration.

1) General information about IPS


Why do you need IPS on its own - it makes no sense to explain in detail. There is enough information on this subject in the vast spaces of the web.
Some fundamental points should still be listed:

1.1) How does IPS work?

Cisco has the following methods used to catch malicious traffic:
  • signature (search using regular expressions in L3 / L4 data, traffic correlation by the number of calls from / to one / many source / destination addresses, exceeding specified thresholds in a unit of time, search for initially incorrect flags in headers, etc.) ;
  • abnormal (comparison of current indicators with collected statistical values);
  • “Cloud” (downloading source reputation data from external servers);

At Cisco, the main emphasis is placed on the signature one, in which the IPS module needs to inspect each packet, check for the presence of “crooked” flags and values ​​in the fields. If there was an IP fragmentation, eliminate data overlap, rebuild the TCP session, and drive the content in it over the set of signatures.

Also, the sensor needs to be able to interpret the data in different ways depending on their encoding.
For example, an attacker wants to exploit a PHP vulnerability. To do this, he puts this payload into the http request:

Such a payload in a “pure” (ASCII) form will be caught by the signature. But if we convert this query, say, to UNICODE, then the string will take the form
& #! 060; & #! 063; & #! 032; & #! 115; & #! 121; & #! 115; & #! 116; & #! 101; & #! 109; & #! 040; & #! 034; & #! 099; & #! 100; & #! 032; & #! 047; & #! 116; & #! 109; & #! 112; & #! 032; & #! 059; & #! 032; & #! 119; & #! 103; & #! 101; & #! 116; & #! 032; & #! 115; & #! 111; & #! 109; & #! 101; & #! 046; & #! 112; & #! 119; & #! 110; & #! 101; & #! 100; & #! 045; & #! 104; & #! 111; & #! 115; & #! 116; & #! 046; & #! 100; & #! 111; & #! 109; & #! 097; & #! 105; & #! 110; & #! 047; & #! 115; & #! 101; & #! 101; & #! 100; & #! 046; & #! 106; & #! 112; & #! 103; & #! 032; & #! 059; & #! 032; & #! 116; & #! 097; & #! 114; & #! 032; & #! 045; & #! 120; & #! 122; & #! 118; & #! 102; & #! 032; & #! 115; & #! 101; & #! 101; & #! 100; & #! 046; & #! 106; & #! 112; & #! 103;& #! 032; & #! 059; & #! 032; & #! 099; & #! 104; & #! 109; & #! 111; & #! 100; & #! 032; & #! 043; & #! 120; & #! 032; & #! 115; & #! 101; & #! 101; & #! 100; & #! 032; & #! 059; & #! 032; & #! 046; & #! 047; & #! 115; & #! 101; & #! 101; & #! 100; & #! 032; & #! 032; & #! 059; & #! 032; & #! 114; & #! 109; & #! 032; & #! 045; & #! 114; & #! 102; & #! 032; & #! 042; & #! 032; & #! 034; & #! 041; & #! 059; & #! 032; & #! 063; & #! 062;& #! 102; & #! 032; & #! 042; & #! 032; & #! 034; & #! 041; & #! 059; & #! 032; & #! 063; & #! 062;& #! 102; & #! 032; & #! 042; & #! 032; & #! 034; & #! 041; & #! 059; & #! 032; & #! 063; & #! 062;

and will no longer be detected by regexp in the signature. However, the web server itself completely “successfully” eats it, interprets it and, specifically in this case, becomes part of the botnet (the request is taken from a real attack like “PHP remote code execution”).
ASCII to UNICODE Translation
In the converted text I had to add the symbol "!" after the lattice, because Habr engine also successfully UNICODE eats and translates into source code.


1.2) IPS Connection Approaches

There are only two of them in general:

A) Promiscuous / mirroring / "side"
The main idea of ​​this approach is that IPS stands next to the network, does not affect its throughput in any way and receives a copy of the traffic from which it subsequently tries to restore the original sessions and go over them with your set of signatures.

Pros:
  1. It does not create bottlenecks (IPS sensors differ greatly in performance, therefore bandwidth is one of the main criteria when choosing them). Those. if in Promisc mode some fragment of the TCP session didn’t get on the sensor, say, due to the congestion of the SPAN port (the mirrored port, which takes a copy of the traffic for IPS), then the worst that can happen is we won’t detect a possible attack .
  2. If IPS fails, there will be no network impact.

Minuses:
  1. Since there is no direct effect on traffic, functions such as normalization and de-obfuscation will not be available, which is fraught with False Negative (no attack was detected). Normalization mainly allows you to identify attacks that can be masked at the 3rd or 4th levels: due to the bit shift flags during IP fragmentation, sending a TCP segment with zero TTL or a check-sum curve. The sensor, receiving a copy of the traffic, tries to reassemble it (collect IP fragments together and restore TCP sessions) in order to understand how the traffic will be interpreted on the final host. In promisc mode, you can only specify for which operating system to try to simulate IP-ressambley.
  2. Preventive actions (blocking malicious traffic) is possible only "after" by sending the appropriate commands to higher gateways / firewalls. If the "bad" package reached its goal earlier than the directive to block it - alas.


B) INLINE / to break
In this approach, it is assumed that the sensor directly stands in the way of the passage of traffic. At the same time, IPS has the opportunity to directly influence transit traffic:
- provide normalization by checking and discarding packets and segments / datagrams that have “curved” fields
- check checksums and various values ​​in TCP headers, drop or correct invalid segments
- eliminate data overlay during fragmentation even before this data reaches the final goal
- to correctly arrange the order of sessions in order to analyze the content
- to block attacks when signatures are triggered.
Those. in fact, this mode is the preferred option in which you can expect the most from IPS.
If we talk about AIP-SSM IPS modules built into ASA, or NME / AIM-IPS modules (they already have EOL) built into ISR platforms, or even about IOS-IPS software solution - implementing Inline mode in this case is quite simple because most often, these devices are already standing in the way of traffic. But if we talk about applications - here everything is already somewhat more complicated.

Pros:
  1. The ability to use many mechanisms to identify masked attacks.
  2. The ability to directly block malicious traffic (the truth here is that many have a panicky fear that IPS nafig will block the operation of legitimate applications).

Minuses:
  1. IPS is becoming a bottleneck. Accordingly, if it is “overloaded” by the amount of traffic, this already has a direct impact on the network. If any of the fragments of the TCP session did not reach the sensor, it will be discarded, and the hosts that participated in the session will receive a session timeout. If the sensor "dies", then in general traffic will not go anywhere anymore. Fortunately, the attacks will not work either. How to live with it and what to do - will be described in a separate section "Fault tolerance."
  2. With incorrect / insufficient configuration of signatures and exceptions - false positive triggers can really cause problems.


1.3) How IPS modules behave in terms of network equipment

If we consider IPS as network equipment, then we need to perceive it as something between a wire (more precisely, a “smart” wire) and a bridge:
  • IPS appliance interfaces successfully negotiate duplex and speed;
  • skip all L2 frames (including BPDUs). There is only one option - (not) filter CDP;
  • IPS "understands" the VLAN-ID;
  • the only operation that is not related to blocking / normalization that IPS can perform with traffic is to replace the VLAN-ID and only in VLAN-pair mode (the mode will be discussed later);
  • IPS does not know how to perform routing. For equipment to which IPS is connected, it's just a wire;
  • in inline mode, the traffic received on interfaces is transmitted by IPS (after analysis) further to “paired” interfaces;
  • monitoring of TCP sessions and the choice of a specific Virtual-Sensor for analysis depends on the settings: the recommended (and default) mode for Inline TCP session tracking mode: Virtual Sensor. Those. in the event that individual segments from one TCP session arrive at different physical IPS interfaces, they will still be “assembled” and sent for analysis to the selected Virtual Sensor;
  • IPS can reassemble TCP sessions (in the case of Promisc-mode) or normalize them (in the case of Inline-mode) in two modes: Strict and Asymmetric (for Promisc mode there is an additional Loose mode). For adequate IPS operation, you only need to use the strict mode: i.e. the entire TCP session should go through the sensor in both directions. All other modes actually reduce the meaning of IPS to zero.
  • if in Inline + Strict mode IPS for some reason (overloading physical interfaces or out of memory in Analysis Engine) missed at least one fragment of the TCP session, all subsequent fragments of this session will be reset.
  • individual IPS boxes / modules do not have any protocols / tools for transmitting information about current sessions (aka statefull redundancy). Those. in the case of using several sensors, traffic from any host to another should always go through only one sensor.


2) INLINE implementation methods


I hope that in the previous part of the article I was able to explain that for the effective operation of IPS it is necessary to enable it in Inline mode and ensure symmetric routing of traffic through it.
Now we list the Inline connection options that are supported by Cisco sensors and look at the scenarios that are provided in the official documentation. When considering the scenarios, I intentionally give them exactly in the form in which they are presented in the Tsiskov documentation. In the part devoted specifically to my scenario, I will explain what Cisco really meant.

2.1) Inline Interface Pair Mode

Such scenarios for applying this mode are described in the official literature:

A) IPS connects two physically separated segments.

Everything is clear here. There are two L3 switches, each of which provides Inter-vlan routing for m / y connected networks. Traffic to networks that are behind another L3 switch will go through IPS.

B) IPS connects two VLANs.

Here's a more interesting situation: two VLANs on the same physical switch are combined using an IPS sensor. When I saw this scheme, the first question I had was: why should traffic from VLAN10 go to VLAN11 through IPS itself? The answer to this question will be given later.

2.2) Inline VLAN Pair Mode

The next Inline mode in which sensors can work is VLAN Pair. It is also called IPS on a stick. In this mode, the IPS interface (s) operate in 802.11q Trunk mode. Tagged traffic from one VLAN arrives at the same IPS interface, IPS analyzes this traffic, replaces the VLAN-ID tag in the frame, and sends this frame back through the same port. It is worth noting here that traffic sent from one VLAN to another passes through one physical interface twice, so the actual throughput of this interface is halved. Also, in fact, this is the only mode in which the sensor independently modifies the traffic, not related to its blocking and normalization.

As in the previous scenario, a reasonable question arises: what actually causes traffic from VLAN11 to go to VLAN12 via IPS? The answer to this and the previous questions will be later.

2.3) Inline VLAN Group Mode

Well, the last of the existing Inline modes is VLAN Group Mode. The general idea is exactly the same as with the Interface-pair: IPS physical interfaces are paired. After that, a “sub-pair” of interfaces is created on each pair of interfaces (by analogy with the sub-interfaces on routers) and VLAN tags are assigned to it that correspond to this sub-pair. The meaning of this design is to be able to assign different VLANs to different virtual sensors (each virtual sensor has its own signature sets, Anomaly Detection statistics base and traffic exclusion / blocking policy). Accordingly, when using this mode, tagged traffic should be fed to the IPS interface.
The scenario described in the documentation assumes that the same networks exist on two different switches that are connected via IPS: I

’ll immediately explain that there is no confusion with the previous mode: traffic sent from VLAN11 from the left switch to the host in the same VLAN11, physically located behind the right switch will go through IPS. This traffic will not get into any other VLANs. The main objective of this mode is to provide flexibility in the set of signatures for different networks. For example: telephony lives in VLAN11, and mail servers live in VLAN12. We assign VLAN11 to vs0 virtual sensor, and VLAN12 to vs1. On vs0, enable signatures relevant for UC / VoIP attacks and write the corresponding exceptions, and on vs1, respectively, the same for E-Mail attacks.
If you still do not understand the meaning of the regime
When I first tried to understand the meaning of this mode, I re-read 10 times of its description in the Configuration Guide, in the Official Certification Guide, as well as in presentations of the official IPS course. I didn’t understand it until I set it up with my hands :) In the part on the configuration, I will give an example of setting up this mode.


3) Statement of the problem


Now that the main theoretical points and proposed scenarios are outlined (although they are still not fully understood), the time has come to come a little closer to a more vital scenario.

Given:
Catalyst 6500 - 1 pc.
IPS 4510 -1 pc. (10 physical interfaces, no hardware-bypass function).
Server / service VLANs (many) and user VLANs (even more) are connected to the 6500. 6500 is the core of the network and provides routing of m / v VLANs. For each VLAN on 6500, the corresponding SVI is created, which is the default gateway for each network.

Task:
Turn traffic to IPS when it passes from user networks to server networks (that is, to provide protection for server segments). In this case, in case of failure of IPS, it is necessary to ensure the ability to return to “normal” direct routing (aka fail-open mode on the ASA).


4) Step-by-step description of the solution


This is where the fun begins. Let's try to figure out how the approaches offered by Cisco actually work, and also find out how to apply them for the task described above.

4.1) How Inline Modes Actually Work

In paragraphs 2.1) B) and 2.2) I left one uninitiated question. The time has come to answer him.
One of the non-trivial points to be reconciled with is the denial of the truth “1 VLAN = 1 subnet”. In the context of IPS connectivity, this axiom has to be destroyed and forced to live with a new state of things.
The general idea of ​​the approach is to move the default gateway address to another VLAN. In this case, the source VLAN must remain without SVI, i.e. the switch in the original VLAN should only work at the second level.
Below I will give an illustration, which I personally really lacked at a time when I was just starting to plunge into this issue.

First, consider the principle of operation of the L3 switch under “normal” conditions: i.e. ports Gi0 / 2 and Gi0 / 20 are connected in the switchport mode access mode to the advising VLANs and the corresponding SVI is created for each VLAN:



When the interface with the VLAN number is created on the L3 switch, we actually connect a virtual router inside the switch with virtual L3 interface to this VLAN. At the same time, on the L3 switch when specifying the address on the SVI, this network appears as a connected route. Accordingly, the logic of the switch with each incoming in this VLAN-e frame looks something like this:
If the dst mac of the incoming frame matches the mac address of my SVI, discard the header and trailer of this frame, and route the remaining L3PDU. In other cases, continue switching.

Accordingly, if a certain host with IP 10.2.0.1 and mac 0002.0000.0001 from VLAN2 sends an ICMP packet to a host with IP 10.20.0.1 and mac 0020.0000.0001 in VLAN20, then it will look like this:



Now let's look at the situation when in VLAN20 we delete the SVI and create with the same IP address (which is the default gateway for the network 10.20.0.0/24) a new one, but in VLAN 120. In this case, the access port in VLAN120 will be connected to one of the IPS sensor ports, and the paired port will be connected already in VLAN20:



If we again consider forwarding the ICMP packet from a conditional host with IP 10.2.0.1 and mac 0002.0000.0001 from VLAN2 to a conditional host with IP 10.20.0.1 and mac 0020.0000.0001 in VLAN20, then Det the following:
  1. The host 10.2.0.1 sends an ARP request to find out the mac address of its default-gw and receives a response from SVI VLAN2.
  2. The host forms a frame with src mac 0002.0000.0001, dst mac 0002.0000.0254, with the src ip packet 10.2.0.1, dst ip 10.20.0.1 and sends it to the G0 / 2 interface.
  3. Having received a frame on the access port in VLAN2, with a mac address corresponding to the SVI mac address in this VLAN¬, 6500 discards the L2 header and trailer, looks at src ip and looks for an entry in the routing table.
  4. Since now the SVI with the address from the destination network is located in VLAN120, the network 10.20.0.0/24 is connected in this VLANe. An ARP broadcast request is sent from the SVI VLAN 120. Since the only port connected to this VLAN is Gi0 / 48, the frame only goes to it.
  5. The ARP request passes through IPS and gets to the Gi0 / 47 port, but already in VLAN20. The switch forwards the broadcast frame to all ports in this VLAN - i.e. on Gi0 / 20
  6. The ARP response from the conditional host 10.20.0.1 passes in the same way as in points 4-5, but in the reverse order.
  7. In the switching table for VLAN20, the mac address 0020.0000.0254 (SVI VLAN120) starts to be listed on the Gi0 / 47 port, and for VLAN120 the mac address 0020.0000.0001 (host 10.20.0.1) starts to be listed on the Gi0 / 48 port. On the same port (Gi0 / 48) for VLAN120 there will be records of all other hosts from the 10.20.0.0/24 network.
  8. 6500 forms a new frame with src mac 0020.0000.0254, dst mac 0020.0000.0001 and puts L3PDU with src ip 10.2.0.1 and dst ip 10.20.0.1 into it.
  9. Next, the frame is switched similarly to paragraphs 4-5.
  10. The ICMP response follows the same path, but in reverse order.

In fact, after removing the SVI VLAN20, this entire VLAN20 turns into a regular L2 broadcast domain. Those. all frames entering this VLAN are only SWITCHED according to the switching table. By the way, in fact, all SVIs have the same mac-address by default (in the diagram I changed it for clarity). Therefore, SVI must be deleted with the no interface vlan command.Just removing the ip address for this SVI is not enough, because The 6500 will continue to route responses coming from VLAN20. As a result, we get an asymmetric path - and as a result, IPS will drop TCP sessions.

The whole trick is due to the fact that IPS creates a physical bridge between two different VLANs, through access ports 6500.
In the case of using the VLAN-pair mode, the same thing happens, with the only difference being that the IPS is connected via the TRUNK port, where both VLANs are forwarded at once. At the same time, when receiving a frame, IPS gives it back, replacing the VLAN tag. Those. each frame is sent twice through the same interface, halving the actual port throughput. However, the main problem in the case of using a VLAN-pair is fault tolerance: if IPS fails, further traffic will be impossible, because no one will replace the VLAN tag. That is why this mode for solving the problem will not be considered more. But one key point from him will still be borrowed.

4.2) Putting it all together

Having figured out how the principle of creating one VLAN in Inline works, the following problem immediately arises: if you spend two physical interfaces to combine “remote” SVIs, then you won’t get many networks on IPS. The VLAN-pair mode is also not suitable due to the limitations associated with fault tolerance.

Well, and if you are closer to real conditions, then server and user networks most often also come to the kernel via trunk channels. Those. the task actually looks like this:



In fact, the main question is how to build a bridge between two TRUNK ports, and even so that traffic to certain subnets first spits out, then returns with an already changed VLAN tag. Moreover, the VLAN tag should not be changed by IPS, because this will put an end to fault tolerance in the event of an IPS failure.

The answer was found: vlan mapping .
This technology is quite specific and is supported exclusively on "thick" platforms such as the Catalyst 6500. Its essence is as follows - vlan mapping is enabled on TRUNK ports and allows you to replace the VLAN-ID number in it when passing through a frame. Moreover, mapping occurs in both directions. Thus, for the scheme above, it is necessary to ensure the replacement in the outgoing from the Gi0 / 48 port frames of VLAN tags from 120, 130, 140 to 20, 30, 40, respectively. And vice versa.

Generally speaking, you need to be extremely careful with vlan mapping. with incorrect settings, it is quite easy to make second-level loops. It is turned on at 6500 by the switchport vlan mapping enable command in the interface configuration mode. Mapping itself is configured with the switchport vlan mapping command. What is interesting is that when you configure a mapping rule on one port, it is added immediately to a group of ports under the control of one ASIC processor. But it becomes active only on ports that are in trunk mode and on which the switchport vlan mapping enable command was issued . In view of this feature, you need to select the ports accordingly if you want to communicate with IPS via etherchannel: all members of the aggregated channel must have identical settings. Vlan-mapping is configured exclusively on physical ports.
Actually in the final we get the following picture:



Accordingly, all communications within VLANs 20, 30, 40 pass without IPS. As soon as traffic from / to these subnets requires the participation of the Default gateway, it will go through IPS. Instead of the Gi0 / 48 and Gi0 / 47 interfaces, there can be etherchannels (in my combat scheme they are used). Fundamentally, nothing changes - you just need to carefully configure VLAN-mapping.
To create a new subnet in IPS, the algorithm of actions is as follows:
  1. Delete an existing SVI with the no interface vlan command.
  2. Create an SVI with the same ip, but in a different VLAN.
  3. We configure switchport vlan mapping <native-vlan> <new vlan SVI> on Gi0 / 48 .
  4. Add a new vlan to the trunk on Gi0 / 48.
  5. Add the old vlan to the trunk on Gi0 / 47.

It should be remembered that in the newly created VLAN there should be nothing but SVI!

4.3) Fault tolerance

The final step in configuring the 6500 will be to implement the “shoot” function of the IPS box, in case of failure (IPS).
Generally speaking, IPS has two fault tolerance features:
  1. Software Bypass, which, in the event of a fall in the main sensor application, must ensure that packets pass through paired interfaces without inspection. If the sensor is turned off or its OS completely hangs, this mode will not help much. Practice has also shown that under certain circumstances the sensor may freeze so that the Bypass function itself stops working ...
  2. Hardware bypass, который доступен только на отдельных сетевых платах расширения для старых моделей, которым ныне уже наступил EOL. Для новых серий (45хх и 43хх) таких плат пока что нет. Смысл этой функции заключается в том, что даже при отключении питания на определенных парах интерфейсов происходит физическое замыкание контактов. Т.е. трафик продолжает свой путь уже просто через провод.

Both the first and second options will not work when using a VLAN-Pair, which is why this mode was not considered.

To fulfill the “fault tolerant” part of the task, an EMM script was implemented in the presented scheme.

The general idea is as follows: if any of the ports that look at IPS goes into LINEPROTO-5-UPDOW down status, then you need to delete all the created SVIs for the protected networks and recreate them with the same address and in their “native” VLAN .
For the diagram above, it will look something like this:
event manager applet 48-47
event syslog pattern ".*LINEPROTO-5-UPDOWN.* GigabitEthernet0/48.* changed state to down"
action 1.1 cli command «enable»
action 1.2 cli command «conf t»
action 1.3 cli command «int GigabitEthernet0/47»
action 1.4 cli command «sh»
action 1.8 syslog msg «PORT 48 FAILED!»
event manager applet IPS_DOWN
event syslog pattern ".*LINEPROTO-5-UPDOWN.* GigabitEthernet0/47.* changed state to down"
action 1.1 cli command «enable»
action 1.2 cli command «conf t»
action 2.1 cli command «no int vlan 120»
action 2.2 cli command «int vlan 20»
action 2.3 cli command «ip add 10.20.0.254 255.255.255.0»
action 3.1 cli command «no int vlan 130»
action 3.2 cli command «int vlan 30»
action 3.3 cli command «ip add 10.30.0.254 255.255.255.0»
action 4.1 cli command «no int vlan 140»
action 4.2 cli command «int vlan 40»
action 4.3 cli command «ip add 10.40.0.254 255.255.255.0»
action 10.1 syslog msg «IPS FAILED!»


Specifically, in my case, the firmware on the Supervisor 6500 12.2 (33) SXH8b was used, so it was not possible to attach the EMM to the track or track-list object. Because of this, I had to catch patterns from syslog messages. You must also enter the logging event link-status command on the destination ports .

If you use the etherchannel to connect to IPS, you also need to take into account one detail: at the second level, 6500 will build the etherchannel with itself, however, at the first level, links will go directly to the IPS interfaces. Therefore, ports 6500 must be "put out" in pairs (by analogy as is done in the example with Gi0 / 48). "Extinguish" in pairs - means that the 6500 interfaces that are connected through the Interface-pair to IPS must turn off simultaneously.
That is, if, for example, we have a connection implemented like this:



Then in EMM you need to monitor the state of Gi0 / 48, and in case of a fall, put out Gi0 / 38. And vice versa - if Gi0 / 38 falls, put out Gi0 / 48 (etc. - for each pair of interfaces).
If this is not done, a situation may arise when, for example, when one of the ports burns out at 6500 in the first channel group, it will leave it, but the response port will still be in UP state (because it will remain connected to IPS). In this situation, the etherchannel will send traffic on the one hand, but it won’t go anywhere ...

And the last point that I would like to mention is that in addition to physically disabling IPS, there may be a situation with its software failure, in which IPS traffic will not pass through itself, but the ports will be kept up / up. To eliminate this situation, it is better to create a track-list, where in addition to the state of the interfaces, also monitor something for the IPS (make ip sla on the side of svi and ip sla responder for ips, either track some resource or check icmp accessibility IPS control interface).

5) Setting on the IPS side


For completeness, I will describe the possible configuration options for the IPS box itself. In principle, in the circuit described above, on the IPS side, you can use Interface-pair mode. Those. just pair the ports to which the 6500 is connected and direct everything to one virtual sensor. However, the presence of VLAN tags allows for more selective verification. Although the connection diagram described above is a hybrid of Interface-pair and VLAN-pair, it also allows you to use VLAN-group-mode.

We assume that ports 6500 are connected to IPS as follows:
6500 Gi0 / 48 <-> IPS Gi0 / 0
6500 Gi0 / 47 <-> IPS Gi0 / 1

Accordingly, the first step is to pair Gi0 / 0 and Gi0 / 1:



After you create a physical pair of interfaces, you can create “sub-pairs” on it. For each sub-pair of interfaces, you can specify the group of VLANs that it will process. The unassigned group implies all VLANs that were not explicitly assigned to any other sub-pair. Suppose that in VLAN20 we have especially critical servers, and in VLAN30 and 40 - all the others.

We create two sub-pairs and assign for one sub-pair all VLANs that fall on the sensor, and for the second - only VLAN20: We bind



each sub-pair to separate virtual sensors:



As a result of this setting, traffic from / to VLAN20 will get to the vs1 sensor, and everything else to vs0. For each sensor, you can enable a different set of signatures, make different rules for blocking and exceptions, and maintain independent Anomaly Detection databases.

If etherchannel is used, all steps must be repeated for each physical pair of interfaces participating in the aggregated channel. Accordingly, for each physical pair, you need to create the same set of sub-pairs and bind all of them to the corresponding interfaces.
That is, if we have, for example, such a connection scheme:



Then the VLAN-group configuration will look like this:



6) Epilogue


The proposed scheme is certainly not the only one, but it fits extremely well into the sensor settings, and is also time-tested.
It turned out of course voluminously, but I hope it is interesting.
Successfully repel attacks!
Next time I’ll write about the methods of receiving and analyzing events from IPS.

Also popular now: