All right, normal traffic signatures.
So what is normal?
Right, normal is normal activity on your network.
It can be assessed by doing some basic
baselining, which is just a sampling interval.
Okay, the longer that sampling interval, the better baseline you have.
So again, if I do a short duration
sampling, anything that occurs that didn't occur in that sampling is considered to be
anomalistic and it may or may not be malicious.
So normal traffic signatures are
acceptable traffic patterns allowed to enter network, normal activity.
Attack Signatures, suspicious traffic patterns not allowed to enter the network.
So again, we've seen examples of that in
intrusion detection system, intrusion prevention.
We looked at snort rules, we know how that works.
Same thing with antivirus Signatures.
So remember, anything signature based, you have seen it before.
You've analyzed unique signature strain, you've told the system to look for it.
The Signature can not only be content, but specific source destination IP addresses,
ports, TCP flags, packet length, time to live, etc.
Those can all contribute to a signature.
They used to define the type of activity on a network.
When we look at things like footprinting
and reconnaissance, there's some very specific flag configurations in TCP.
There's very specific behaviors for host
discoveries, and we've touched on that a bit in the previous module.
So again, baselining normal traffic signatures is getting a sample set.
The longer the sample set, the more accurate the baseline is, and any
difference from that baseline should be investigated.
Some considerations.
To create a normal baseline for normal traffic, normal TCPIP communication
involves a three way handshake for normal traffic.
If you see a variation of that, you don't see a full three way handshake.
You see a two way handshake and an RST.
That's somebody's in stealth scanning your network.
If you see funky flag configurations like
Fin Urgent push set, that's a Christmas tree scan.
If you see no flags set, that's weird.
Can't really have a TCP packet with no flags set.
That's a null scan.
So the fin flag appears at the beginning
and a fin flag at the end of the connection.
So any variation from that would definitely be a non holistic.
Right?
Normal communications happen a certain way.
You do have a breadth session terminations, RSTs, things like that.
When you see them consistently and
strategically, that definitely warrants investigation.
All conversations originating inside the
Demilitarized Zone are trusted traffic items.
Any traffic violating network policies is malicious traffic.
The existence of FTP when the type is restricted, indicates a potential issue.
Again, that falls under the category of
protocol anomalies, which can be really twofold.
Protocols that are not normal activity and
then the abnormal or misuse of protocols, tunneled payloads, that thing.
Categories of suspicious traffic signatures.
Informational. Traffic containing certain signaturessthat
may appear suspicious but might not be malicious.
Reconnaissance, traffic containing certain
signaturessthat indicate an attempt to gain information.
We're going to talk about that.
Pingsweeps, port scans, etc.
Unauthorized access, traffic containing
signaturessthat indicate an attempt to gain unauthorized access.
For example, repeated login attempts on an FTP server.
Ftp response codes of 530 indicating it's been rejected.
Response codes of 230 indicating it's been accepted.
You see a big long series of 530s.
Some is getting rejected, rejected, rejected, rejected.
You see 230 they get accepted.
Our Denial of Service, traffic containing Signatures that indicates a DOS attempt
flooding a server with a large number request.
Now you can see, for instance, lots of random inbound Send packets with random
addresses where there's no completion of the handshake.
There's a bunch of different indicators of Denial of Service.
It really depends on what you're looking for.
The attack signature analysis techniques.
Content based signature analysis.
You're actually looking for the Signatures in the packet payload, looking for
suspicious strings occurring in the suspicious payload.
We looked at our snort rules that content
matching, great example of content based Signature Analysis.
Context based Signature Analysis, the
attack Signatures are contained in the packet headers.
You're seeing things like source and
destination IP address, IP options, protocols, checksums, source and
destination port numbers, IP fragmentation flags, offset, and so forth.
The indicators are in the header, not the payload.
Lots of manipulation of header information
for different types of scans, fragmentation attacks, etc.
Content, payload, context, header.
And then atomic signature based analysis means a single packet gives an indicator
of malicious activity versus composite, which requires multiple
packets required to detect attack signatures.
So for example, if I see a signature in a packet for a SSH protocol violation or
whatever, but it exists in a single packet, it's atomic based.
If it requires multiple packets, like I
see a sequentially incrementing port number from one IP to the other across
multiple packets, that indicates a port scan, and that's a composite variety,
multiple packet analysis required to detect signatures.
Then you've also got your event
correlation engines, which combine different types of events and different
types of activities, your splunks, your arc sites, QRadars, etc.