It's (log) analysis ... look at and for all traces of possible evidence
While being able to analyze packets is very important in detecting intrusions, it is not the only way of detecting intrusions.
To be able to properly analyze any intrusion event, the analyst must be prepared to look at data from any and or every possible source of information. Once a device is 'touched' evidence of this is more than likely somewhere to be found. Obviously, I'm assuming some type of logging is being done.
In this example, we will build out a scenario.
Let's start with the IDS.
The first trigger or alert, that there may be an intrusion will more than likely come from your IDS. You do have one right?! :-)
Once the IDS generates an alert, it is time to analyze that alert.
Evaluate the IDS rule against the packet which generated the event. Knowledge of your environment is assumed.
Does this look like a false positive? Example ... Is the attacker targeting a Linux Telnet Server while you are running Windows Telnet Sever?
Does this look like a true positive? Example ... Is the attacker targeting Windows Telnet Server while you are running Windows Telnet Server?
In our scenario, the IDS will generate an alert when "joe-attacker" successfully logs into the Telnet Server.
We will check ... ooops ... correlate the alert with the server logs to see what's available.
Let's put this together.
Using Snort as IDS and a Windows 2003 Telnet server, let's build this scenario out.
Configure two Snort variables
ipvar $HOME_NET 10.0.0.51/32 # This would be the Windows Box running the Telnet Server. This is the system we wish to protect
ipvar $EXTERNAL_NET !$HOME_NET # Will be the Kali system on 10.0.0.50/24. This says anything not defined as "$HOME_NET" should be considered hostile
Time to build a snort rule to identify when username 'joe-attacker' successfully logs in to our Windows Telnet server
This custom rule will go in the /etc/snort/rules/local.rules file
alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"Successful login from joe-attacker"; content:"Microsoft Telnet Server"; nocase; fast_pattern; content:"joe-attacker"; nocase; flow:from_server; Priority:1; classtype:successful-user; reference:url,security-nik.blogspot.com; rev:1; sid:40000001)
Let's test snort to ensure there is no problem with this rule
root@security-nik:~# snort -c /etc/snort/snort.conf -T
Snort successfully validated the configuration!
Looks good ... no problem with the rule
Now let's run snort to look for our traffic
root@security-nik:~/snort# snort -c /etc/snort/snort.conf -A full -i eth0 -q -l .
Time to verify Telnet Server is listening on the server
As netstat shows we are listening for Telnet traffic on port 23
C:\>netstat -anobp tcp
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:23 0.0.0.0:0 LISTENING 2164
Ok 'joe-attacker', it's time to logon and logout
root@security-nik:~# telnet -l joe-attacker 10.0.0.51
Connected to 10.0.0.51.
Escape character is '^]'.
Welcome to Microsoft Telnet Service
Welcome to Microsoft Telnet Server.
C:\Documents and Settings\joe-attacker>exitConnection closed by foreign host.
The above shows "joe-attacker" successfully logged in, got a command prompt and then exited
Once again, let's start with the IDS.
here is what the IDS saw.
root@security-nik:~/snort# cat alert
[**] [1:40000001:1] Successful login from joe-attacker [**]
[Classification: Successful User Privilege Gain] [Priority: 1]
04/13-22:27:06.951742 10.0.0.51:23 -> 10.0.0.50:47018
TCP TTL:128 TOS:0x0 ID:1503 IpLen:20 DgmLen:264 DF
***AP*** Seq: 0xC9A7854F Ack: 0x1AE0887 Win: 0xFA6A TcpLen: 32
TCP Options (3) => NOP NOP TS: 44372 1078019
[Xref => http://security-nik.blogspot.com]
Looks like "joe-attacker" successfully logged into the Telnet Server on 04/13 at 22:27:06 from host 10.0.0.50 and source port 47018
Let's verify .... oooops correlate this with the windows logs. Please note, having accurate time information is critical for proper correlation. Your system(s) should be configured to sync their time with a at least 2 NTP Servers
The Windows logs shows the following
Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 528
Time: 10:27:06 PM
User Name: joe-attacker
Logon ID: (0x0,0x5C116)
Logon Type: 2
Logon Process: Advapi
Authentication Package: Negotiate
Workstation Name: SECURITYNIK-2K3
Logon GUID: -
Caller User Name: LOCAL SERVICE
Caller Domain: NT AUTHORITY
Caller Logon ID: (0x0,0x3E5)
Caller Process ID: 3632
Transited Services: -
Source Network Address: -
Source Port: -
As can be seen above "joe-attacker" successfully logged on 4/13/2014 at 10:27:06.
It would have been nice, if we also had the "Source Network Address". However, this information is not always available
Obviously there is other information in here. However, the objective is to show why logs and any or all other sources of information should be considered and correlated.
As shown above, traces and or evidence of an intrusion can be found in many different place. Take advantage of any logs or other sources of information you may have to help make your conclusion more sound.
Additional info on gathering and reading logs:
Additional info on gathering and reading logs: