08-24-2012
11:45 AM
- last edited on
02-13-2020
12:56 PM
by
Kelli Glass
With Robert Albach
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about security best practices and management for the Cisco Intrusion Prevention System (IPS) with Robert Albach. The Cisco Intrusion Prevention System is a context aware threat prevention system for your networked environments. The module unobtrusively detects and prevents problematic traffic from reaching its target; uses contextual inputs to determine the proper level of response; and tightly integrates with the ASA firewall for greater network security.
Robert Albach is a product manager in the Security Business Unit at Cisco, responsible for intrusion prevention offerings. Before joining Cisco in 2010 he held product management positions for intrusion prevention offerings at Hewlett-Packard/TippingPoint. He has more than 15 years of experience with systems management and security product offerings and has presented at the RSA trade show and other security venues.
Remember to use the rating system to let Robert know if you have received an adequate response.
Robert might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Security sub-community discussion forum shortly after the event. This event lasts through through September 7, 2012. Visit this forum often to view responses to your questions and the questions of other community members.
09-07-2012 01:01 PM
Hi Prashant,
The position sounds Ok and the policy rule is likely fine also assuming that the network surroundings are arranged in a manner where traffic is going to bypass the box.
The next step is defining what signatures and actions are configued for vs0 (virtual sensor 0) as that is where the IPS will perform its inspection.
If you find that you don't have the time to do an extensive investigation into the assets you wish to protect and all their vulnerabilities (to determine what sigs to turn on etc.), you might want to consider the use of protection templates.
If you get to version 7.1.6, there are some new pre-defined deployment specific templates available. I suggest that you set up a new virtual sensor vs1 for example and apply them there. If you can afford to mirror traffic through them as a test bed that would be nice. After analyzing the results you may select to run your live traffic through it.
Good Luck!
-Robert
09-05-2012 05:24 AM
Hi Robert, how does the Cisco IPS systems compare with those from vendors like TippingPoint and McAfee? How does Cisco differentiate itself against these other products? I frequently get these types of questions in the field, and I'm not too familiar with either TippingPoint or McAfee to answer. Any information you have that helps in this area is appreciated.
Thanks,
Pat
09-05-2012 11:42 AM
Hi Pat,
I will focus on three areas of differentiation that generally seperates Cisco from most of the other IPS vendors.
The first is the most obvious and that Cisco is first and foremost a network solution provider. As such you will find IPS security made available at whatever point in the network you desire and in a wide variety of forms. There is IOS/IPS, a switch module, we've had a router module, and integrated with firewalls. We are a very network aware and network enabled security solution.
Second is an extension of the first with regards to firewall integration. We have created a highly symbiotic relationship with the ASA such that certain functions are shared and policies impacts can be shared as well.
Thirdly Cisco IPS is largely contextually driven. We apply context not just to post processing reporting but in fact will alter the actions we take depending on the who, what, where involved. A nice example would be something like the following: If Manny the Marketer is having problems accessing an application then Nero the Network Admin can get on his box and ping the appropriate servers to see if connectivity is a problem. The Cisco solutions understands it is an IT admin and allows it. If Manny (who was looking over Nero's shoulder) tries to do the same then the system could block it because naturally lots of pings from a marketing machine might represent an owned host seeking out new victems. That is the kind of contextual story that Cisco can execute against live traffic in real time. A pretty nice story!
Hope this helps and thanks for the chance to plug some differentitors!
-Robert
09-05-2012 08:25 AM
Hi Robert,
I was wondering if you had further clarification on what the cidsHealthPacketDenialRate SNMP object shows. This is one of the objects we monitor and will alert on when this object shows that packets are being denied but I am wondering what the output from this really means. According to the description of the object it displays "the percentage of packets denied due to protocol and security violations."
Does this mean that the IPS is dropping the packets due to triggered signatures or that it is not inspecting packets because something is wrong with them or something else? It doesn't seem like it triggers when packets are dropped because of a triggered signature because we have MARS configured to alert on when traffic is dropped by the IPS because of the severity of a triggered signature and we don't get these alerts when this object shows packets being denied.
We would like to get a better idea of what the output from this SNMP object shows to see if we need to monitor the output from this object or not.
Thanks,
D
09-07-2012 12:46 PM
Hi Damien,
I see that you asked this question earlier. I am sorry to see that you did not get an answer then.
This the the % of packets denied because the policy on the box is set to drop these when the conditions described - grossly speaking when the appropriat signature matcesh and the resulting risk rating calculation matches the appropriate threshold for a drop. There is more detail on this and I suggest a listen to the IPS Tech Tips on risk ratings on this forum if you wish.
In simple terms there is two parts of inspection - that done through a normalization process - where issues like fragmentation or protocol violations are noted and then a threat detection phase where specific security risks are identified.
Now I notice your reference to MARs and your perceived gaps with the Alerts. Some policy settings may not call for an explicit alert when a signature is invoked and traffic is dropped. The normalization process itself could generate a good deal of inactionable (mostly) events that way.
For the other cases you should look over your policy and see if you are generating alerts that are associated with each drop.
Hope this helps!
-Robert
09-07-2012 01:20 PM
Thankds Robert,
As a followup, the virtual sensor doesn't show any traffic as being dropped but the analysis engine does. Does that mean traffic is getting dropped or just not inspected?
Here is the output I'm seeing:
# show stat virtual-sensor
Virtual Sensor Statistics
Statistics for Virtual Sensor vs0
Name of current Signature-Defintion instance = sig0
Name of current Event-Action-Rules instance = rules0
List of interfaces monitored by this virtual sensor = GigabitEthernet0/0 subinterface 1,GigabitEthernet0/0 subinterface 2,GigabitEthernet0/1 subinterface 1,GigabitEthernet0/1 subinterface 2
General Statistics for this Virtual Sensor
Number of seconds since a reset of the statistics = 461178
MemoryAlloPercent = 26
MemoryUsedPercent = 26
MemoryMaxCapacity = 1350000
MemoryMaxHighUsed = 423936
MemoryCurrentAllo = 361524
MemoryCurrentUsed = 357402
Inspection Load Percentage = 0
Total packets processed since reset = 8717680
Total IP packets processed since reset = 7569923
Total IPv4 packets processed since reset = 7569923
Total IPv6 packets processed since reset = 0
Total IPv6 AH packets processed since reset = 0
Total IPv6 ESP packets processed since reset = 0
Total IPv6 Fragment packets processed since reset = 0
Total IPv6 Routing Header packets processed since reset = 0
Total IPv6 ICMP packets processed since reset = 0
Total packets that were not IP processed since reset = 1147757
Total TCP packets processed since reset = 4938204
Total UDP packets processed since reset = 2611735
Total ICMP packets processed since reset = 19984
Total packets that were not TCP, UDP, or ICMP processed since reset = 0
Total ARP packets processed since reset = 68589
Total ISL encapsulated packets processed since reset = 0
Total 802.1q encapsulated packets processed since reset = 8717680
Total GRE Packets processed since reset = 0
Total GRE Fragment Packets processed since reset = 0
Total GRE Packets skipped since reset = 0
Total packets with bad IP checksums processed since reset = 0
Total packets with bad layer 4 checksums processed since reset = 72
Total number of bytes processed since reset = 2337873147
The rate of packets per second since reset = 18
The rate of bytes per second since reset = 5069
The average bytes per packet since reset = 268
Denied Address Information
Number of Active Denied Attackers = 0
Number of Denied Attackers Inserted = 0
Number of Denied Attacker Victim Pairs Inserted = 0
Number of Denied Attacker Service Pairs Inserted = 0
Number of Denied Attackers Total Hits = 0
Number of times max-denied-attackers limited creation of new entry = 0
Number of exec Clear commands during uptime = 0
Denied Attackers and hit count for each.
Denied Attackers with percent denied and hit count for each.
The Signature Database Statistics.
The Number of each type of node active in the system
Total nodes active = 53
TCP nodes keyed on both IP addresses and both ports = 6
UDP nodes keyed on both IP addresses and both ports = 4
IP nodes keyed on both IP addresses = 7
The number of each type of node inserted since reset
Total nodes inserted = 204068
TCP nodes keyed on both IP addresses and both ports = 4542
UDP nodes keyed on both IP addresses and both ports = 52903
IP nodes keyed on both IP addresses = 38632
The rate of nodes per second for each time since reset
Nodes per second = 0
TCP nodes keyed on both IP addresses and both ports per second = 0
UDP nodes keyed on both IP addresses and both ports per second = 0
IP nodes keyed on both IP addresses per second = 0
The number of root nodes forced to expire because of memory constraints
TCP nodes keyed on both IP addresses and both ports = 23
Packets dropped because they would exceed Database insertion rate limits = 0
Fragment Reassembly Unit Statistics for this Virtual Sensor
Number of fragments currently in FRU = 0
Number of datagrams currently in FRU = 0
Number of fragments received since reset = 144
Number of fragments forwarded since reset = 144
Number of fragments dropped since last reset = 0
Number of fragments modified since last reset = 0
Number of complete datagrams reassembled since last reset = 72
Fragments hitting too many fragments condition since last reset = 0
Number of overlapping fragments since last reset = 0
Number of Datagrams too big since last reset = 0
Number of overwriting fragments since last reset = 0
Number of Inital fragment missing since last reset = 0
Fragments hitting the max partial dgrams limit since last reset = 0
Fragments too small since last reset = 0
Too many fragments per dgram limit since last reset = 0
Number of datagram reassembly timeout since last reset = 0
Too many fragments claiming to be the last since last reset = 0
Fragments with bad fragment flags since last reset = 0
TCP Normalizer stage statistics
Packets Input = 4938202
Packets Modified = 0
Dropped packets from queue = 0
Dropped packets due to deny-connection = 0
Duplicate Packets = 0
Current Streams = 6
Current Streams Closed = 0
Current Streams Closing = 0
Current Streams Embryonic = 0
Current Streams Established = 0
Current Streams Denied = 0
Total SendAck Limited Packets = 0
Total SendAck Limited Streams = 0
Total SendAck Packets Sent = 0
Statistics for the TCP Stream Reassembly Unit
Current Statistics for the TCP Stream Reassembly Unit
TCP streams currently in the embryonic state = 0
TCP streams currently in the established state = 0
TCP streams currently in the closing state = 0
TCP streams currently in the system = 0
TCP Packets currently queued for reassembly = 0
Cumulative Statistics for the TCP Stream Reassembly Unit since reset
TCP streams that have been tracked since last reset = 0
TCP streams that had a gap in the sequence jumped = 0
TCP streams that was abandoned due to a gap in the sequence = 0
TCP packets that arrived out of sequence order for their stream = 0
TCP packets that arrived out of state order for their stream = 0
The rate of TCP connections tracked per second since reset = 0
SigEvent Preliminary Stage Statistics
Number of Alerts received = 518
Number of Alerts Consumed by AlertInterval = 518
Number of Alerts Consumed by Event Count = 0
Number of FireOnce First Alerts = 0
Number of FireOnce Intermediate Alerts = 0
Number of Summary First Alerts = 0
Number of Summary Intermediate Alerts = 0
Number of Regular Summary Final Alerts = 0
Number of Global Summary Final Alerts = 0
Number of Active SigEventDataNodes = 0
Number of Alerts Output for further processing = 0
Per-Signature SigEvent count since reset
Sig 3653.0 = 518
SigEvent Action Override Stage Statistics
Number of Alerts received to Action Override Processor = 0
Number Of Meta Components Input = 0
Number of Alerts where an override was applied = 0
Actions Added
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 0
deny-packet-inline = 0
modify-packet-inline = 0
log-attacker-packets = 0
log-pair-packets = 0
log-victim-packets = 0
produce-alert = 0
produce-verbose-alert = 0
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
SigEvent Action Filter Stage Statistics
Number of Alerts received to Action Filter Processor = 0
Number of Alerts where an action was filtered = 0
Number of Filter Line matches = 0
Number of Filter Line matches causing decreased DenyPercentage = 0
Actions Filtered
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 0
deny-packet-inline = 0
modify-packet-inline = 0
log-attacker-packets = 0
log-pair-packets = 0
log-victim-packets = 0
produce-alert = 0
produce-verbose-alert = 0
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
Filter Hit Counts
SigEvent Action Handling Stage Statistics.
Number of Alerts received to Action Handling Processor = 0
Number of Alerts where produceAlert was forced = 0
Number of Alerts where produceAlert was off = 0
Number of Alerts using Auto One Way Reset = 0
Actions Performed
deny-attacker-inline = 0
deny-attacker-victim-pair-inline = 0
deny-attacker-service-pair-inline = 0
deny-connection-inline = 0
deny-packet-inline = 0
modify-packet-inline = 0
log-attacker-packets = 0
log-pair-packets = 0
log-victim-packets = 0
produce-alert = 0
produce-verbose-alert = 0
request-block-connection = 0
request-block-host = 0
request-snmp-trap = 0
reset-tcp-connection = 0
request-rate-limit = 0
Deny Actions Requested in Promiscuous Mode
deny-packet not performed = 0
deny-connection not performed = 0
deny-attacker not performed = 0
deny-attacker-victim-pair not performed = 0
deny-attacker-service-pair not performed = 0
modify-packet not performed = 0
Number of Alerts where deny-connection was forced for deny-packet action = 0
Number of Alerts where deny-packet was forced for non-TCP deny-connection action = 0
Anomaly Detection Statistics
Number of Received Packets:
TCP = 4938202
UDP = 2611591
Other = 19984
TOTAL = 7569777
Number of Overrun Packets:
TCP = 0
UDP = 0
Other = 0
TOTAL = 0
Number of Ignored Packets = 0
Number of Events = 28822
Number of Recurrent Events:
TCP = 2
UDP = 60078
Other = 0
TOTAL = 60080
Number of Worms = 0
Number of Scanners = 0
Number of Scanners Under Worm = 0
Internal Zone
Number of Events:
TCP = 0
UDP = 0
Other = 0
TOTAL = 0
Number of Overrun Events:
TCP = 0
UDP = 0
Other = 0
TOTAL = 0
External Zone
Number of Events:
TCP = 1
UDP = 28405
Other = 4
TOTAL = 28410
Number of Overrun Events:
TCP = 0
UDP = 0
Other = 0
TOTAL = 0
Illegal Zone
Number of Events:
TCP = 0
UDP = 412
Other = 0
TOTAL = 0
Number of Overrun Events:
TCP = 0
UDP = 0
Other = 0
TOTAL = 0
Global Utilization Percentage
Unestablished Connections DB
TCP = 0
UDP = 0
Other = 0
Recurrent Events DB
TCP = 0
UDP = 0
Other = 0
Scanners DB
TCP = 0
UDP = 0
Other = 0
# show stat analysis-engine
Analysis Engine Statistics
Number of seconds since service started = 461274
The rate of TCP connections tracked per second = 0
The rate of packets per second = 18
The rate of bytes per second = 5070
Receiver Statistics
Total number of packets processed since reset = 8720201
Total number of IP packets processed since reset = 7572202
Transmitter Statistics
Total number of packets transmitted = 8720129
Total number of packets denied = 92114
Total number of packets reset = 0
Fragment Reassembly Unit Statistics
Number of fragments currently in FRU = 0
Number of datagrams currently in FRU = 0
TCP Stream Reassembly Unit Statistics
TCP streams currently in the embryonic state = 0
TCP streams currently in the established state = 0
TCP streams currently in the closing state = 0
TCP streams currently in the system = 0
TCP Packets currently queued for reassembly = 0
The Signature Database Statistics.
Total nodes active = 54
TCP nodes keyed on both IP addresses and both ports = 6
UDP nodes keyed on both IP addresses and both ports = 4
IP nodes keyed on both IP addresses = 8
Statistics for Signature Events
Number of SigEvents since reset = 518
Statistics for Actions executed on a SigEvent
Number of Alerts written to the IdsEventStore = 0
Inspection Stats
Inspector active call create delete createPct callPct loadPct
AtomicAdvanced 1 7572058 1 0 0 86 70
Fixed 0 64858 59108 59108 0 0 0
MSRPC_TCP 0 13186 4534 4534 0 0 0
MultiString 5 227151 2470 2465 0 2 15
ServiceDnsUdp 1 2612529 1 0 0 29 0
ServiceGeneric 1 2617063 4535 4534 0 30 1
ServiceNtp 8 5225058 106250 106242 1 59 0
ServiceP2PTCP 0 7623 4534 4534 0 0 0
ServiceRpcUDP 1 2612529 1 0 0 29 0
ServiceRpcTCP 6 2058130 1449 1443 0 23 0
ServiceSnmp 1 2612529 1 0 0 29 0
ServiceTNS 0 5983 5983 5983 0 0 0
String 6 336435 3419 3413 0 3 9
SweepICMP 2 19994 2285 2283 0 0 0
SweepTCP 5 9879066 47 42 0 113 0
SweepOtherTcp 2 4939533 22 20 0 56 1
GlobalCorrelationStats
SwVersion = 7.0(8)E4
SigVersion = 664.0
DatabaseRecordCount = 4307585
DatabaseVersion = 1347048367
RuleVersion = 1346963166
ReputationFilterVersion = 1347048700
AlertsWithHit = 0
AlertsWithMiss = 0
AlertsWithModifiedRiskRating = 0
AlertsWithGlobalCorrelationDenyAttacker = 0
AlertsWithGlobalCorrelationDenyPacket = 0
AlertsWithGlobalCorrelationOtherAction = 0
AlertsWithAuditRepDenies = 0
ReputationForcedAlerts = 0
EventStoreInsertTotal = 0
EventStoreInsertWithHit = 0
EventStoreInsertWithMiss = 0
EventStoreDenyFromGlobalCorrelation = 0
EventStoreDenyFromOverride = 0
EventStoreDenyFromOverlap = 0
EventStoreDenyFromOther = 0
ReputationFilterDataSize = 453
ReputationFilterPacketsInput = 7571702
ReputationFilterRuleMatch = 0
DenyFilterHitsNormal = 0
DenyFilterHitsGlobalCorrelation = 0
SimulatedReputationFilterPacketsInput = 0
SimulatedReputationFilterRuleMatch = 0
SimulatedDenyFilterInsert = 0
SimulatedDenyFilterPacketsInput = 0
SimulatedDenyFilterRuleMatch = 0
TcpDeniesDueToGlobalCorrelation = 0
TcpDeniesDueToOverride = 0
TcpDeniesDueToOverlap = 0
TcpDeniesDueToOther = 0
SimulatedTcpDeniesDueToGlobalCorrelation = 0
SimulatedTcpDeniesDueToOverride = 0
SimulatedTcpDeniesDueToOverlap = 0
SimulatedTcpDeniesDueToOther = 0
LateStageDenyDueToGlobalCorrelation = 0
LateStageDenyDueToOverride = 0
LateStageDenyDueToOverlap = 0
LateStageDenyDueToOther = 0
SimulatedLateStageDenyDueToGlobalCorrelation = 0
SimulatedLateStageDenyDueToOverride = 0
SimulatedLateStageDenyDueToOverlap = 0
SimulatedLateStageDenyDueToOther = 0
AlertHistogram
RiskHistogramEarlyStage
RiskHistogramLateStage
ConfigAggressiveMode = 2
ConfigAuditMode = 1
MaliciousSiteDenyHitCounts
MaliciousSiteDenyHitCountsAUDIT
09-07-2012 01:28 PM
Hi Damien,
This will probably take a bit to debug and unfortunately I am out next week. Will try to get somebody to look at what you have here.
Just to cover a very simplistic case. Are we certain that all traffic is going through this particular virtual sensor?
Thanks,
-Robert
09-05-2012 08:52 AM
Hi Robert,
My organization is planning to implement a firewall system to allow our outside employees to access a certain web application that we have on our local machines. Can you advise me on wether purchasing a Cisco router such as the 1900 series version that include cisco IOS firewall would be a solid investment or would purchasing a standalone firewall such as the ASA be a better option. The Cisco Router would be a nice addition because it would provide a dynamic device that would make monitoring and filtering traffic a little more intuitive right?
09-06-2012 02:05 PM
Hi Allen,
I would suggest the ASA/IPS combination. The code base is more up to date and has a greater upside for future expansion.The VPN capabilities for those outside empoyees is helpful as well. If you were considering the router it suggests that your throughput needs for inspection is not high. You may want to consider the ASA 5515 or lower.
Hope this helps.
-Robert
09-06-2012 07:54 AM
Hello Robert,
my name is Yenko.
we are trying to subnet our network by departments. Right now we are using the 10.0.0.0/16 network and it is just a huge network. What is the best way to subnet it so that the users can only have access to their department files.
09-06-2012 03:16 PM
Hi Yenko,
I think your question is more of a firewall question from the perspective of access. When talking to customers I frequentlyl start with an overly simplistic question set of:
(a) What do you want to protect yourself from;
(b) What do you want to protect.
The answer to (a) almost always starts out as - the set of objects and actors outside my organization. This leads to the placement of security devices at the internet edge.
The answer to (b) is typically a mirror to (a) - the set of objects and actors inside my organization. The same conclusion for device placement occurs.
Follow up with the assumption that "inside my organization" cannot be trusted. From here things get more interesting but from a survey of just under 200 Cisco IPS customers it turns out that these are the following deployment %s:
Behind the perimeter FW - 78%
In front of perimeter FW - 67%
Network core - 33%
In front of primary data center - 32%
In front of public facing web application - 31%
Behind VPN concentrtaor - 24%
Between different business units - 24%
Between corporate campuses - 22%
Between different business functions - 18%
These are just some numbers from other IPS users out there that might spark some ideas. Naturally budget and management efforts may curtail your ability to place them wherever you wish but look at those numbers as idea starters and consider that "protect me from"
I recognize that the vagueness of the answer but hope you can find something of value within.
Thanks,
-Robert
09-06-2012 02:24 PM
Hi Robert,
I want to position an IDS solution for a client who is on a strict budget. I see that the new IPS sensors (4300) are out and provide quite a bit of throughput but are very expensive. A 4240 sensor is more in line with his throughput requirements but I don't want to position something that runs older software/hardware. I was thinking that the ASA 5515X with the IPS is equal to the 4240 in terms of IPS throuput.
Is there any way to install the ASA to sit out of line with the traffic while monitoring in promiscuous mode? If I configured a SPAN port on a switch to feed the ASA all the switch traffic, and configured the policy on the ASA to pass it to the IPS in promiscuous mode, would the ASA drop the traffic or send it to the sensor?
I was also thinking I could put the ASA in layer 2 mode and set the IPS to promiscuous mode and fail open but if the ASA goes down, it will cut off the traffic. I don't want it to be a point of failure, but I don't want to position a solution that is too expensive, or too old.
What are your thoughts?
Thanks much,
Xavier
09-07-2012 01:20 PM
Hi Xavier,
As of 7.1.6 the 4240 will run the most up to date software functionally equivalent to the rest of the platforms. I can't say it reverses the hardware age though.
So your question is a good one and indeed there is a challenge here. As it is all traffic must travers the ASA prior to entering the IPS. You can configure rules as needed to get traffic through the box unchallenged as you noted but it is still a firewall and indeed you end up with the somewhat unnatural acts that you describe.
Wish I had a cleaner solution for you. I think the 5515x is a good solution if your customer can accept the conditions. You can always use different contexts to drive the traffic through and hey it is a darn good firewall.
-Robert
02-01-2013 02:04 PM
Hi Garris,
These botnets are primarily used for denial of service (DOS) attacks using HTTP. I'm uncertain if your question's focus is on either (a) detecting their presense within your network; or (b) defending against their attacks. For the sake of brevity I'm going to focus on (a) detection.
There are three means I would like to offer to detecting any form of bot and its introduction into your network: (a) its inttroduction within your environment; (b) its presence on a specific device; and (c) its activity once within your network. I think I will work in reverse operational order here.
These bots are mostly used for DOS and their "medium" is web traffic, HTTP. Consider significant outbound web requests that are out of the ordinary both in terms of volume and time of day. If certain windows hosts are sending HTTP requests at hours the user is typically not present those are pretty good clues. Unfortunately these don't seem to use the more common tell-tale IRC as a command and control communication channel so my one of my favorite advices for discovering infections is ineffective. You may want to consider looking at your IPS logs for hits to from the Reputation Fitler. I also suggest looking into the use of the Botnet Traffic Filter if you have an ASA in line.
Next - while no guarantee, keep your Anti-X up to date. There are some AV variants that detect these systems but the variants (particularly Dirt Jumper) have been spawning with regularity unfortunately which can make file based detection a challenge.
Now what we all really want is to stop these things in transit before they make it onto your network devcies. The bad news is that just as the AV vendors are challenged to capture all the variants an in-line device is even more so hampered given the real time nature of their operation. Best bet is to hopefully identify the activity of the initial intrusion prior to the dropper doing its work.
So sadly the most honest answer I can provide to you is that an in-line security system such as your IDSM2 based IPS is most likely to detect these threats by their activity. They could enter your network from a numbe of vectors some of which may be outside the view of your IPS.
-Robert
01-30-2013 01:43 PM
Hello,
I was wondering if there's a signature update that addresses the Dirt Jumper, BlackEnergy, and Optima BotNets... If not, could you help me create one to do so?
I'm currently running a WS-SVC-IDSM-2 with ver 7.0(6)E4. Signaturever. 691.0 and Eng. 4 .... I use the auto update option and have readdressed the ip address to the new server...
Thanks in advance,
Garris
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: