All
right, intrusion, detection, and prevention system.
Now, the first thing we want to do is differentiate between the two.
An intrusion detection system doesn't stop anything from happening.
If I have a smoke detector and the smoke
detector goes off, I've already got a fire.
A intrusion prevention system is IDS logic
on a gateway or perimeter device that has the ability to actually stop the packet
from entering the network, thus being truly preventative.
Now that we've got that out of the way,
you'll hear the two terms used somewhat interchangeably and sometimes
incorrectly, but now we know the two different aspects, two different flavors.
The IDPS system is meant to detect or stop intrusions from happening, and it uses a
variety of methods to actually accomplish that objective.
First off, how does an IDS work?
It may work on Signature File Comparison,
let me back to red here, Anomaly Detection, or Protocol Anomaly Detection.
We'll take a look at examples of each here in just a second, or definitions of each.
The role of an IDS in network defense.
An IDS works from inside the network.
Like I said, it is detective in nature,
unlike a firewall which only looks outside the network for intrusions.
An IDS is placed behind the firewall, inspecting all the traffic, looking for
heuristics, and a pattern match for intrusions.
Our two basic categories
are Signature based or pattern matching and then Anomaly based
or heuristical looking for abnormalities or variations from the norm.
All right, so speaking of which, how an IDS detects an intrusion.
Signature based recognition does specific syntax and pattern matching.
So you have definitions rules when you see
the content specification in the rule in a packet, it flags an alert.
Anomaly detection detects intrusion based
on fixed behavioral characteristics of users and components in a computer system.
So Anomaly and then protocol anomaly
detects anomalies in the way which vendors deploy the TCPIP specification.
Think of it like this.
I can program the IDS specifically to look for everything.
What's the problem with that?
I've got to program it specifically to look for everything I wanted to detect.
Exactly.
So we got zero day threats, unknown attacks.
We don't know exists.
How are we supposed to program an IDS ahead of time for that?
So an answer to that is anomaly, just looking for abnormalities.
If something abnormal is occurring, it may be an intrusion.
So imagine this works way better in a live classroom environment, but imagine I was
implementing anomaly detection, and you were sitting in front of me in the front
row of a classroom, and I go into a learning or baselining template mode.
I do a sampling of what looks like normal activity.
I'm watching the students in the front row.
I'm like, I got it.
This one's looking at the board.
This one's taking notes.
This one's on their phone.
This one's nodding off.
I need to pep it up a little bit.
But I see what's normal activity and then
sampling is over and then I start monitoring.
Now let's say that one of them sneezes.
Intrusion, intrusion.
I've never seen it before.
It's a variation from the norm.
Now, obviously, we're not going to detect
sneezes in a network, but when I see something that's not part of a sample
interval, that gets identified as an anomaly.
The problem with that is false positives.
The longer the sampling interval, the better of a baseline template you have.
When something like that happens, it may
not be as an anomaly, but you can also adjust the sensitivity of the system up or
down on variations from remote traffic patterns.
We'll call those clipping levels or thresholds.
So tuning your IDS up or down can decrease
the number of false positives, but at the same time, it might increase the number of
false negatives, which we're going to be talking about here shortly.
So we'll hold off on the whole
false positive, false negative thing until the appropriate slide.
Protocol Anomaly. Hey, look at that.
An ICMP packet with a payload that's not half of the alphabet in Windows.
That doesn't look right.
Tonnelled or encapsulated data and so forth could be an example of anomalistic
patterns for protocol or just the abnormal support protocols.
Look at that.
We got finger protocol running on the network.
Nobody uses that anymore. Why am I seeing port 79 traffic?
That's weird.
So you get the idea.
The definition of anomaly is variation from the norm.
Definition of Signature is I program it
specifically to look for very specific syntax.
General indications of intrusions.
The file system, new files, changes in files permissions,
unexplained changes in the file size, rogue files on the system that don't
correspond to the master list of signed files or missing files.
Network intrusions. You'll see things like repeated probes of
available services on your network, connections from weird locations, repeated
login attempts from remote hosts, sudden influx of log data.
System intrusions, short or complete logs,
unusually slow system performance, missing logs, that's always a little bit dicey.
Modifications to system software, unusual graphic displays or text messages,
gaps in the system accounting, system crashes or reboots, unfamiliar
processes, etc. All right, so the approach based IDS.
The way the slides are entitled here, I want to clarify a little bit here.
The approach based IDS, this is the type of IDS based on the approach it takes.
I'm going to clarify that in each title slide.
But the first time I read that, I was like, Approach based IDS.
It didn't quite click for me because I was reading a little bit differently.
The approach would be whether it's signature based or nonalytic based.
That's the approach the IDS takes, which really is not basing the decision on
the approach, it's how it formulates its conclusion.
For some reason, I read that wrong,
so I figured I'd clarify just in case you're reading it the same way.
It's not the IDS's approach, it's the approach that it takes.
It's a based IDS. Different flavors based on approach.
Let's go with that.
Signature based detection
and known as misuse detection monitors patterns of traffic packets in the network
that is knowledge based that signature matching.
Advantage is lots less false positives.
If your intrusion signatures are written
correctly, disadvantages is limited to only known threats.
That's again, the big drawback with knowledge based detection.
Anomaly based detection.
Again, watches for abnormalities, we just described how that works.
The advantages is it catches more
variations, unknown threats, things like that.
Disadvantage is it generates automatically a higher number of false alarms.
Stateful protocol analysis.
Again, watches normal traffic patterns and
watches for variations from normal traffic patterns.
The Misuse Detection System and the Anomaly Detection System.
Again, you're watching for anomalies or
variations from normal patterns, plain and simple.
For example, Bob has been a model employee for the last 20 years.
Bob logs in at 8 AM on the dot every
morning like clockwork from his local workstation on a known internal IP, etc.
Now, let's say that Bob's account is logged into at 234 AM on a Saturday from
an IP address in Thailand or something weird like that.
Kind of weird. Maybe Bob's on vacation.
He's got jet lag.
He's still awake, forgot to get some work done, but maybe he's not.
Again, the misuse or the weird behaviors
could be normal activity, but it's abnormal, it varies from normal patterns.
Any way you measure what's normal and
what's not, statistical analysis can be an omnibased detection.
Are the behavior based.
The IDS, the behavior that it exhibits.
Let's go with that.
Ids based on its behavior classification.
Not detect based on behavior, but what it does.
A active IDS detects and responds to detected intrusions.
It actually does something about it.
That send message,
email message to an administrator, we got a problem here, you want to check into it.
So it actually responds or does something reactively.
Passive IDS only detects intrusions.
May log an alert in a file and just look at that, an alert.
Writes it down, doesn't necessarily notify response.
The difference between those would be real
time intrusion detection versus post mortem.
Investigations that are done real time,
there's a notification at the time of the event and response force is dispatched.
In a post mortem, it's after the fact, something's been detected much later and
you're going back to log files looking for anomalies or correlating information.
Protection based IDS.
Based on what it protects.
I would probably put IDS at the beginning of these.
Ids that protects the network is called a NIDs.
Ids that protects a host is called a HIDS.
An IDS that detects both is called a hybrid IDS, which I guess would be a HIDS,
but then that would conflict with the HIDS acronym.
A hybrid combines the advantages of both low false positive rate of a NIDS and
anomaly based detection of a HIDS to detect unknown attacks.
Fantastic. Okay, we're not going to differentiate
anomaly heavy versus signature heavy NIDS or HIDs.
The host based is meant to detect weird activities locally on the host.
The nids is meant to detect weird activities on the network.
Think of it like traffic cops, nids.
Think of it as your own personal security detail in your living room, hids.
Because not all attacks originate from the network.
You could have a user sitting down in a local system or a malware infection that
the nids would never be able to see because there's no network traffic.
Structure based hits.
This is the structure that it may be deployed in.
So distributed versus centralized are the two flavors of structural models for IDS.
An IDS can be classified as centralized or distributed.
In centralized, all data is shipped to a central location for analysis.
That's a good model because it gives you a couple of things.
Number one, centralization.
Puts everything in one location so you
don't have to go pull log files from all these different hosts.
It also gets the log data off the systems
doing the monitoring, which helps because attackers, the fifth step of the hacking
cycle, we talked about that in a previous module, is to clear log files.
Alerts, things like that.
Those local sensors might be attacked, that can be a problem.
In centralized, everything is shipped to a central location.
In a distributed, several IDSs are deployed over a large
network and each IDS communicates with each other for traffic analysis.
You do have a non consolidation or a
decentralization, which means you have to go to each IDS.
The whole concept of a security operations
center is to convert everything in one location for analysis and quick response.
Whenever you decentralize anything, it's a
lot more fragmented and you might not have as readily accessible data.
There's also each individual IDS could be
potentially compromised, but also in a centralized IDS,
one of the attacks on that would be to DOS or Denial of Service the IDS, the
Centralization of the Server, which then neutralizes all detection.
There's pros and cons to each, but the two models, central location or more
distributed, and then of course, there's a combination of both.
An example of centralized control, and get
beautiful graphics on the EC Council slides.
No other course has quite this polished course, I love their graphics.
In a centralized, again, everything
reports to a central console and a decentralized or agent based, everything
is installed on local resources or individual subnets.
Which in centralized, you still have some agents forwarding to the server.
Ids based on its analysis timing.
So interval based IDS is information about an intrusion does not flow continuously.
From monitoring points and analysis
engines, it's stored and forwarded at regular intervals.
So in a real time scenario, everything's
being sent as it comes in, an interval based it's transmitted in batches.
So it performs analysis of a detected intrusion potentially offline.
In a real time based IDS,
information flows continuously from the monitoring points to the analysis engines,
performs analysis of the detected intrusion on the fly.
Again, real time versus interval based,
which you can throw post mortem in real time in there as well.
All right, source data analysis.
How about an IDS again based on the source data?
Intrusion detection using audit trails versus network packets.
Both of these can give you insight into an
attack that's being performed on the network.
Audit trails help the IDS detect
performance problems, security violations, and flaws in applications.
That's logging.
So you're talking about log files.
You're talking about SIS Log servers and splunks, which
an SIEM, Security Information and Event Management System, which we are going to
define here shortly, is a consolidation point for pretty much everything.
Logging data, IDS alerts, and so forth, everything in one central console.
So forwarding log file informationsto a
central location, that's intrusion detection using audit trails.
Intrusion detection using network packets,
that's scanning the protocols or scanning the packets and looking specifically at
the packet content versus the activities being logged on the system.
The IDS components.
You have network sensors, alert systems, a
command console, a response system, and an attack signature database.
The first item, the network sensor.
They're hardware and software components
that monitor network traffic and trigger alarms if abnormal activity is detected.
These guys need to be connected to a span port on each switch at each subnet
or be plugged in each VLAN to be able to monitor all those local subnets.
So a network sensor needs to be deployed
on every subnet and needs to be able to view all traffic.
It is a packet sniffer by default, most basic form,
and then it analyzes those packets looking for evidence of intrusions.
So they should be placed at entry points, internet gateways between land
connections, remote access servers, VPN devices, and either side of the firewall.
The command console.
The command console is your central reporting console.
Software installed runs on a separate
system that is dedicated to the IDS, and guess what?
All the agents report to the command console.
That's your centralization or your consolidation point.
It provides user interface for the purpose
of receiving and analyzing security events.
And again, the advantage of all this is it's in one location.
It can be filtered and sorted in one location.
A good caution point here.
The command console is installed on a non dedicated computer system.
It'll drastically slow down the response
to security events as those systems may be busy handling other tasks.
So you want to be sure that you are not impacted by other services running on the
system, which that goes back that whole bash and host discussion,, but depending
on what the system is doing, you don't want it to affect any security operations.
So always keep that in mind.
Alert systems.
The system sends an alert message when an anomaly or misuse is detected.
Couple of examples here, you have Osec
kids in Seagull, which is our centralized console, and Snort NIDs alerts as well,
which again, these can all be forwarded to that central command console.
A response system.
A response system issues countermeasures against any intrusion that's detected.
So may or may not be a corrective measure, but you do have some APIs with firewalls
where alerts can shut down ports, IP addresses, things like that.
But a lot of this may also require
decision making by the incident response team.
You should have the ability to respond on your own.
You need to make decisions on how to deal
with false positives and when a response needs escalation.
That's all part of your incident handling and response policies.
Recommendation, you should not solely rely
on an IDS response system for intrusion response.
It should be verified because they get them wrong a lot, right?
False positives.
An attack signature database.
Again, it needs to be defined since the IDS does not have the capability to make a
decision unless it maintains a database of attack signatures patterns.
So again, in a knowledge based or signature based system.
If any matches are found, the IDS will
raise an alert and block the suspicious traffic.
Traffic is compared against the known
attack signatures and then a decision can be made.
You need to periodically update your IDS attack signature database.
So for example, this is an example of a Snort Rules file.
So the alert, the action external net,
we're not going to go too much into the anatomy of the rule, but I want to show
you what the signature looks like just so you can visualize.
These are the actual signatures.
All right, the content in a Snort rule identifies the pattern matching.
So this content is looking for a string of hexadecimal zeros or hexadecimal 90s.
That's actually indicative of what's
called a Knobsled, which usually means buffer overflow attacks.
Or it's looking for specific pattern matching like who is 3A?
Or it's looking for things like get aCTP
1.1. So if it sees this content, it flags an alert, which that means you need to
assimilate a unique, reliable signature for each type of attack.
And the evasion of all this is just to
preserve the functionality but evade the signature.
Case variation, slash orientation, additional alternate coding, etc.
Are all different ways to evade detection.
So the attack signature database in a Snort system is manifested in multiple
rules files that are categorical listings of different signatures.
Are deploying a network based IDS.
An effective deployment requires a lot of attention concerning the topology.
Think of it like this.
If you want to detect a fire in your house, you want a smoke detector in every
room because the fire could originate in any room.
Same thing with a network based IDS, you want to sensor on every subnet or every
VLAN, however you lay it out, so you can detect intrusions on those segments.
The possible deployment options are
categorized based on the location of IDS sensors.
Consider all possible options and its
associated advantages and disadvantages when placing a network based IDS.
Basic example, have a sensor on every segment.
If you had more subnets, sensor on every segment.
More subnets, sensor on every segment.
You get the idea.
Deploying a host based IDS.
A lot of times host based IDSs are deployed on specific sensitive systems,
but deploying a host based IDS provides an additional layer of security.
Must be installed and configured on each critical system in the network.
You generally don't put a host based IDS on absolutely everything.
It does actually impact performance.
You also want to determine whether or not
it impacts the performance of the critical system that you're monitoring.
You should consider installing it on every
host in the organization, provided it doesn't give you the performance hit.
That's been my experience that will put them on more critical systems.
But if you've got the funds and the
resources for it, you definitely can put them on every host if you like.
When deploying host based IDS, it's recommended that it
has centralized management reporting functions, which
reduces the complexity for managing alerts from a large number of hosts.
Remember also, the more you monitor, the more you have to respond to.
I'll tell you what, we're going to put host in an IDS on absolutely everything.
Be careful what you ask for, because now you got a lot of alerts to address.
Speaking of alerts, what is an IDS alert?
An alert is a graduated event which notifies that a particular event or
a series of events has reached a specified threshold or specific threshold
and needs proper action by a responsible party.
Clipping levels, acceptable thresholds.
After one, two, three invalided password attempts, you've been locked out.
Or you can up it or down it.
That's tuning the sensitivity of the IDS.
It sends the notification indicating that
something is wrong and requires immediate attention monitoring.
And again, more false positives, more to respond to.
However, it's better to have false positives than false negatives.
I will take false positives over false negatives any day of the week.
And we're about to describe what a false
positive or false negative is. All right, a positive.
Okay, first off, a positive means an alert was generated.
A negative means no alert was generated.
All right, so negative is no alert positive alert was generated.
We use checkboxes for that.
True or false means, was that the correct response?
So think of it like a fire alarm.
If a fire alarm goes off, that's a positive alert.
If there's a fire, it's a true positive. f
there is an attack and alert, it's a true positive.
If there's an attack and alert, it's a true positive.
There's an intrusion and alert, it's a true positive.
A false positive would be where the fire alarm goes off, but there's no fire.
An alert is generated, but there's no attack.
An alert is generated, but there's no intrusion.
So that, again, I would error on the side
of false positives because at least I'm not missing anything.
Now, on the flip side of the coin, a false negative, no alert.
The false means that was the wrong response.
In a false negative, we have no fire alarm, but man, there's a fire.
We have no alert, but there's an attack.
We have no alert, but there's an intrusion.
The condition is incorrect to warrant the response.
In a true negative, no fire alarm, no
fire, no attack, no alerts, no intrusion, no alert.
So all is quiet and it should be.
All is quiet and it shouldn't be, all is
noisy and it shouldn't be, all is noisy and it should be.
Those are the different types of IDS alerts.
Now, intrusion detection with Snort.
Snort is the de facto standard IDS.
Been around for decades.
It's currently owned by Cisco.
It's a packet logger by default by basic function and design, and then it matches
those packets with pattern matching, and it's been around for eons.
The Snort rule configuration, which we've already seen an example of, is your
signature based detection, and then you also have heuristic engines
that can run as well, which gives you the anomaly side of things.
Snort has a flexible rules language used to describe traffic that should collect or
pass, as well as a detection engine that utilizes a modular plug in architecture.
Again, you'll have different rules files for different types of attacks.
Snort configuration is potentially incredibly complex.
It's typically done from a command line.
There are gooey interfaces for Snort.