MARSv3 - L5731C 002 1

Cisco Security
Monitoring, Analysis,
and Response System
(MARS) v3.0 Lab Guide
L5731C-002-1
February 2009
Cisco Security Monitoring, Analysis, and
Response System (MARS) v3.0 Lab
Guide
L5731C-002-1
February 2009
Copyright Information
Copyright 2009, 2008 by Global Knowledge Training LLC
The following publication, Cisco Security Monitoring, Analysis, and Response System (MARS) v3.0 Lab
Guide, was developed by Global Knowledge Training LLC. All rights reserved. No part of this publication
may be reproduced or distributed in any form or by any means without the prior written permission of the
copyright holder.
This courseware may contain images from Cisco Systems. All Cisco images are copyright
Cisco Systems, Inc.
Products and company names are the trademarks, registered trademarks, and service marks of their
respective owners. Throughout this manual, Global Knowledge has used its best efforts to distinguish
proprietary trademarks from descriptive names by following the capitalization styles used by the
manufacturer.
Global Knowledge Project Team
JIM THOMAS Course Director
NANCY DUNHAM Project Director, Content Development
CHERYL HOLMES Project Manager, Content Development
ERIC STRAUSE Product Director, Cisco Product Management
JENNIFER SCOTT Product Manager, Cisco Product Management
9000 Regency Parkway
Cary, North Carolina 27518
Phone: 919-461-8600
1-800-COURSES
Fax: 919-461-8646
www.globalknowledge.com Printed in Canada
MARS 3.0 Lab Guide TOC-1
Global Knowledge Training LLC
Table of Contents
Lab 1: Remote Lab Familiarization ....................................................................L1-1
Lab 2: Bootstrapping the MARS Appliance.......................................................L2-1
Lab 3: Importing Hardware Devices to MARS..................................................L3-1
Lab 4: Generating Summary Reports .................................................................L4-1
Lab 5: Exploring Rules .......................................................................................L5-1
Lab 6: Creating Queries and Reports..................................................................L6-1
Lab 7: Case Management and Rule Actions.......................................................L7-1
Lab 8: Incident Handling and Mitigation............................................................L8-1
Lab 9: Tuning the MARS ...................................................................................L9-1
Lab 10: Creating a Custom Parser ....................................................................L10-1
Lab 11: IPS and MARS Integration..................................................................L11-1
Lab 12: CSM Interaction...................................................................................L12-1
Lab 13: Adding a Software Reporting Device..................................................L13-1
Lab 14: Adding a AAA Reporting Device .......................................................L14-1
Lab 15: Maintaining the MARS .......................................................................L15-1
Table of Contents
TOC-2 MARS 3.0 Lab Guide
.
1
.
2
1
0
0
.
1
0
0
.
1
.
0
/
3
0
1
5
0
.
1
5
0
.
1
.
0
/
2
4
.
1
I
N
T
E
R
N
E
T
N
T
P

S
e
r
v
e
r
t
i
m
e
.
n
i
s
t
.
g
o
v
1
9
2
.
4
3
.
2
4
4
.
1
8
O
u
t
s
i
d
e
-
P
C
1
5
0
.
1
5
0
.
1
.
2
0
.
1
M a n a g e m e n t S u b n e t
1 0 . 1 0 . 2 . 0 / 2 4
M
A
R
S

3
.
0

N
e
t
w
o
r
k

T
o
p
o
l
o
g
y
.
1
L
3
-
S
W
D
M
Z

S
u
b
n
e
t
1
7
2
.
1
6
.
1
.
0
/
2
4
O
u
t
s
i
d
e

P
e
r
i
m
e
t
e
r
2
0
0
.
2
0
0
.
1
.
0
/
2
4
(
3
)
(
2
)
(
1
1
)
(
1
0
)
P
e
r
i
m
e
t
e
r

R
o
u
t
e
r
(
I
n
d
i
c
a
t
e
s

V
L
A
N
)
2
k
1
0
.
1
0
.
0
.
0
/
2
4
A
S
A
.
2
A
d
m
i
n
-
P
C
1
0
.
1
0
.
1
0
.
1
0
X
P
M
A
R
S
1
0
.
1
0
.
2
.
1
0
0
S
e
c
u
r
i
t
y
-
S
r
v
1
0
.
1
0
.
2
.
1
0
D
M
Z
-
S
r
v
(
5
)
P
r
i
v
a
t
e
W
A
N
X
P
.
1
D
a
t
a
-
S
r
v
1
0
.
1
0
.
1
.
1
0
D
C
A
V
-
S
r
v
1
0
.
1
0
.
1
.
1
1
A
V
S
i
t
e
1
-
P
C
1
0
.
2
0
.
1
0
.
1
0
(
4
)
I
P
S
(
1
2
)
(
1
5
)
.
1
N
A
T
:

2
0
0
.
2
0
0
.
1
.
1
5
1
7
2
.
1
6
.
1
.
1
5
(
6
)
.
1
.
1
.
1
.
2
S
i
t
e
1
-
R
T
R
1
0
.
2
0
.
0
.
2
.
1
1
0
(
1
3
)
.
1
w
w
w
.
g
k
l
.
c
o
m
D
a
t
a

C
e
n
t
e
r

S
u
b
n
e
t
1
0
.
1
0
.
1
.
0
/
2
4
I
n
s
i
d
e

P
e
r
i
m
e
t
e
r
A
C
S
.
1
(
7
)
C
S
M
-
S
r
v
1
0
.
1
0
.
2
.
1
1
E
n
d

U
s
e
r

S
u
b
n
e
t
1
0
.
1
0
.
1
0
.
0
/
2
4
S
e
r
v
i
c
e
s
-
R
-
U
s
5
0
.
5
0
.
5
0
.
5
0
w
w
w
.
s
r
u
.
c
o
m
D
N
S
(
1
6
)
5
0
.
5
0
.
5
0
.
0
/
2
4
.
1
NARS Nastei Cieuentials List
Your Assigned POD Username: ________________________________________
Your Assigned POD Password: ________________________________________

Device Method Username Password
Classroom PC Windows Login Administrator Admin$Pwd
MARS HTTPS pnadmin pnadmin
Perimeter
Router
Enable
telnet
san-fran
cisco
Layer3
Switch
Enable
telnet
san-fran
cisco
ASA Enable
telnet
san-fran
cisco
Supplement
Switch
Enable
telnet
san-fran
cisco
IPS HTTPS cisco ccspattack
Site1
Router
Enable
telnet
san-fran
cisco
CSM Server Client on
Security-Srv
admin csm$Pwd
ANY VM Image Windows Administrator cisco

.
1
.
2
1
0
0
.
1
0
0
.
1
.
0
/
3
0
1
5
0
.
1
5
0
.
1
.
0
/
2
4
.
1
I
N
T
E
R
N
E
T
N
T
P

S
e
r
v
e
r
t
i
m
e
.
n
i
s
t
.
g
o
v
1
9
2
.
4
3
.
2
4
4
.
1
8
O
u
t
s
i
d
e
-
P
C
1
5
0
.
1
5
0
.
1
.
2
0
.
1
M a n a g e m e n t S u b n e t
1 0 . 1 0 . 2 . 0 / 2 4
M
A
R
S

3
.
0

N
e
t
w
o
r
k

T
o
p
o
l
o
g
y
.
1
L
3
-
S
W
D
M
Z

S
u
b
n
e
t
1
7
2
.
1
6
.
1
.
0
/
2
4
O
u
t
s
i
d
e

P
e
r
i
m
e
t
e
r
2
0
0
.
2
0
0
.
1
.
0
/
2
4
(
3
)
(
2
)
(
1
1
)
(
1
0
)
P
e
r
i
m
e
t
e
r

R
o
u
t
e
r
(
I
n
d
i
c
a
t
e
s

V
L
A
N
)
2
k
1
0
.
1
0
.
0
.
0
/
2
4
A
S
A
.
2
A
d
m
i
n
-
P
C
1
0
.
1
0
.
1
0
.
1
0
X
P
M
A
R
S
1
0
.
1
0
.
2
.
1
0
0
S
e
c
u
r
i
t
y
-
S
r
v
1
0
.
1
0
.
2
.
1
0
D
M
Z
-
S
r
v
(
5
)
P
r
i
v
a
t
e
W
A
N
X
P
.
1
D
a
t
a
-
S
r
v
1
0
.
1
0
.
1
.
1
0
D
C
A
V
-
S
r
v
1
0
.
1
0
.
1
.
1
1
A
V
S
i
t
e
1
-
P
C
1
0
.
2
0
.
1
0
.
1
0
(
4
)
I
P
S
(
1
2
)
(
1
5
)
.
1
N
A
T
:

2
0
0
.
2
0
0
.
1
.
1
5
1
7
2
.
1
6
.
1
.
1
5
(
6
)
.
1
.
1
.
1
.
2
S
i
t
e
1
-
R
T
R
1
0
.
2
0
.
0
.
2
.
1
1
0
(
1
3
)
.
1
w
w
w
.
g
k
l
.
c
o
m
D
a
t
a

C
e
n
t
e
r

S
u
b
n
e
t
1
0
.
1
0
.
1
.
0
/
2
4
I
n
s
i
d
e

P
e
r
i
m
e
t
e
r
A
C
S
.
1
(
7
)
C
S
M
-
S
r
v
1
0
.
1
0
.
2
.
1
1
E
n
d

U
s
e
r

S
u
b
n
e
t
1
0
.
1
0
.
1
0
.
0
/
2
4
S
e
r
v
i
c
e
s
-
R
-
U
s
5
0
.
5
0
.
5
0
.
5
0
w
w
w
.
s
r
u
.
c
o
m
D
N
S
(
1
6
)
5
0
.
5
0
.
5
0
.
0
/
2
4
.
1
NARS Nastei Cieuentials List
Your Assigned POD Username: ________________________________________
Your Assigned POD Password: ________________________________________

Device Method Username Password
Classroom PC Windows Login Administrator Admin$Pwd
MARS HTTPS pnadmin pnadmin
Perimeter
Router
Enable
telnet
san-fran
cisco
Layer3
Switch
Enable
telnet
san-fran
cisco
ASA Enable
telnet
san-fran
cisco
Supplement
Switch
Enable
telnet
san-fran
cisco
IPS HTTPS cisco ccspattack
Site1
Router
Enable
telnet
san-fran
cisco
CSM Server Client on
Security-Srv
admin csm$Pwd
ANY VM Image Windows Administrator cisco

MARS 3.0 Lab Guide L1-1
L1
Lab 1: Remote Lab
Familiarization
Lab 1 Remote Lab Familiarization
L1-2 MARS 3.0 Lab Guide
Lab Overview
The purpose of this lab is to introduce you to the Global Knowledge Remote Lab
Environment used for this class. You will have access to three Microsoft Windows XP
PC system desktops, six Windows 2003 Servers, one Windows 2000 Server, one
Windows 2000 Workstation, an ASA 5520 firewall, a Catalyst 3560 L3 switch, 2811 IOS
router, 1841 IOS router and one MARS 20 appliance. This lab will demonstrate how to
access the various pieces of equipment, what features are available with them, and how
they are connected in the topology.
Estimated Completion Time
30 minutes
Lab Procedures
1. Logging In
2. The PC Systems
3. The Network Devices
4. Understanding the Topology.
Logging In
When you first access the lab environment, you will notice that all of the virtual machines
(VMs) running in VMWare are in a powered down state. It is imperative for this course that you
do not turn on all of the VMs at any one time. Please only turn on the VMs indicated in the
VMs Needed Section below. In addition to not having all of the VMs powered on at any one
time, care should be taken to stagger the powering-on of the VMs. Please be sure to wait until
after you logon to one VM before powering up the next.
VMs Needed
For labs 1 through 11 of this guide you will turn on only the VMs specified below. Make sure
that you DO NOT turn on the AV-Srv or the CSM-Srv for this lab. These VMs will be used
in a later lab, and instructions for turning them on will be given at that time.
When instructed, turn on these VMs for labs 1 through 11.
Access-PC Admin-PC Dats-Srv DMZ-Srv Outside-PC Security-Srv Services-R-Us Site1-PC
VMs to leave off for labs 1 through 11
AV-Srv CSM-Srv
Please wait until after you logon to each VM before powering on the next. Again, DO NOT
turn on the AV-Srv or CSM-Srv for this lab or any other until instructed to do so. If you
mistakenly turn on either of these VMs, please try to shut them off again by choosing Start to
Shutdown once you get to the VM desktop or by selecting the Stop Button in the VM console
which resembles the following icon
The Global Knowledge Remote Lab system used for this class is accessed via the Windows
Remote Desktop Client. Once logged in, you will have access to a VMWare Server console
with the desktops of 4 different PC systems and 6 Windows Servers. Access is available 24
hours a day and typically ends at midnight on the final day of class.
1. Before getting started, consult the lab diagram at the beginning of this lab guide for
familiarity of our topology. Note that there are two copies of this topology in the lab guide.
The intention is for you to rip one of them out. Then the topology diagram is available to
you at any time during the labs without having to thumb your way back to the front of the
lab guide. It also makes a convenient book mark for keep your place between labs.
2. Your instructor will provide three credentials for you to use this week. Write them down
here:
Assigned Pod Number:__________________________________
User name:________________________________________
Password:_________________________________________
3. From the PC provided to you in the classroom, launch the Windows Remote Desktop
Client. If the RDP client is not in the Quick Launch bar of the PC you can locate the RDP
client by clicking Start > All Programs > Accessories > Communications > Remote
Desktop Connection.
4. When prompted, enter the host name launch-rdp.remotelabs.com in the Computer field,
and click Connect.
5. When prompted, enter the user name and password listed in step 2 from above, and click
OK.
6. Inside the remote desktop client window will be a VMware console window. All access to
all Servers or hosts will be provided through this VMWARE host system. The top bar of
the vmware server will list the servers you can click on throughout the lab process.
The PC Systems
There are a total of four PC systems available for your use. They are placed in three different
security zones. The Outside-PC is simulating a user on the Internet and will be used for
attacking our DMZ. Then there is the Site1-PC, this system is serving as an infected host in our
network with a virus. The Admin-PC will also play an important role in the labs, as you will
configure the MARS from this host. This can be any host in your environment but should be
limited to a particular host where access can be controlled. The Access-PC will be providing all
console access for all of your devices throughout the labs and is not a part of the network
topology.
The Server Systems
There are a total of six servers in the lab topology as well. They are also placed in various zones
throughout the topology. The DMZ-Srv is a Windows 2000 server in the DMZ providing Web
and FTP services to the Internet. The Services-R-Us Windows 2003 server is providing outside
DNS services as well as simulating the cisco.com website. The server named Data-Srv is the
Windows 2003 domain controller for our environment and currently has active directory
configured. The AV-Srv is another Windows 2003 server running Symantec Anti-Virus Server.
The CSM-Srv allows for interaction between the MARS appliance and Cisco Security Manager
in the lab environment. Lastly, the Security-Srv is the Windows 2003 server providing AAA
services ( running ACS) to our network devices as well as the MARS appliance.
The VMware Console
6.1. The Inventory panel should be displayed on the left-hand side of the VMware console
window. If it is not, it can be displayed by selecting View > Inventory or by selecting
the F9 key.
6.2. Right clicking on the name of a PC system or Server in Inventory and choosing the
Power On option will start the VM and bring the PC/Server desktop to the foreground
of the VMware Console. At this point, right click and power on each of the VMs one
at a time. Remember DO NOT power on the AV-Srv or the CSM-Srv for labs 1 11.
Also, wait until after logging into each VM before starting the next.
6.3. Now, in the main panel of the VMware console you should have one PC desktop
visible, and 9 tabs across the top. Any PC desktop can be brought to the foreground by
either clicking its name in the Inventory panel, or clicking the tab with its name. If the
tabs are not visible, select them from the View menu.
6.4. Since the Inventory panel is now redundant, and takes up display space, click the X
button in its upper right corner to close it.
Note If you accidentally close a PC window, so its tab disappears, you can always
bring the Inventory panel back temporarily with View > Inventory
6.5. To log in to a PC system, it may require sending it a Ctrl-Alt-Del signal. If you hit Ctrl-
Alt-Del, however, it will be interpreted by your local PC, not the remote lab PC. To
send a Ctrl-Alt-Del, select VM > Send Ctrl+Alt+Del. If you are an experienced
VMWare user, you know that Ctrl+Alt+Insert also bring-up the login screen on a
virtual machine.
6.6. Select the Admin-PC, send the Ctrl-Alt-Del and login. The credentials for all of the
remote PC systems is username administrator and password cisco. Make sure you log
into the Domain called gkl and not the local workstation.
6.7. Repeat this process to log in to the remaining PC systems. For the Windows Servers,
please login with the username of administrator and password cisco (also noted on the
passwords sheet for easy reference). Please remember that the classroom computer you
are currently on and the VM images presented in the course use different credentials.
The classroom computer credentials should be provided by your instructor at the
beginning of the course. Make sure you log into the Domain called gkl and not the local
workstation. The Outside-PC, Services-R-Us Server and DMZ-Srv are not a part of the
local domain therefore should be automatically logged into the local PC.
7. Optimizing the desktop display:
7.1. Select the Admin-PC.
7.2. Since you will run some GUI applications on the Admin-PC, its desktop size is set to a
higher resolution than the other systems (1024x768). It is very likely that the local PC
that you are using to access the remote lab environment is also set at 1024x768. Due to
this you will likely see some scroll bars on the Remote Desktop Client window.
Address this as follows:
7.2.1. Maximize the Remote Desktop client window. It is now running in full screen
mode. There are no borders around it, just a control bar in the top center of the
display.
7.2.2. The menus and borders of the VMware console window are still taking up space.
Switch the VMware Console window to full screen mode by hitting Ctrl-Alt-Enter.
Now there should be no borders around the VMware Console window. If the
resolution of the local PC is 1024x768, it should appear as if you are now working
directly on the Admin-PC.
7.2.3. To leave full screen mode, press Ctrl-Alt and release.
In summary:
Use the tabs to switch from one PC/Server system to another.
When using the Admin-PC, which has a higher screen resolution, use Ctrl-Alt-
Enter and Ctrl-Alt to switch between windowed and full screen mode.
If a PC/Server system window closes (so its tab is lost), use the Inventory panel to
bring it back. The Inventory panel can be toggled with View > Inventory or by
pressing the F9 key.
The Ctrl-Alt-Del sequence can be sent to a remote system from the VM menu in
the VMware Console.
Features of the PC/Server Systems
7.3. Identification: Throughout the labs, you will be directed to perform a task on a
particular PC/Server. There are 4 indicators to help determine what machine you are
working with:
The name on the active VMWare console tab.
The name on the My Computer icon (which was changed from My Computer to
the hostname of the machine).
The desktop background color.
The desktop background image which shows the systems host name, IP address,
subnet mask and default gateway.
7.4. The Quick Launch Bar: The small applications that you will use most often in the labs
are easily found on the quick launch bar. (Note: Some systems may not have these
applications installed). You can find the toolbar on the Outside-PC.
7.4.1. From left to right the icons are:
Show Desktop: Minimizes all windows and shows the desktop. Can be handy
to get a quick handle on clutter, or quick access to an icon on the desktop.
Command Prompt: Launches a Command Prompt window which will be used
to launch Windows CLI commands (like ping, telnet and FTP), and to launch
other command line tools.
Windows Explorer: When you need to access or copy files, Windows Explorer
provides a nice GUI for the task.
WordPad: For reading and editing text files.
PuTTY: An SSH terminal application. SSH is an encrypted protocol which can
take the place of clear text Telnet.
WS FTP: A GUI FTP application.
Internet Explorer: A web browser.
Kiwi Syslog: Free syslog server.
FireFox: A Web Browser.
7.5. The Status Bar: The status bar shows that there are some applications running in the
background, as well as the time. Some Servers/PCs have different applications running
in this system tray and may not match exactly to whats shown here.
7.5.1. To the far left is the program called Automachron which is a basic NTP client for
synchronizing the clocks.
7.5.2. Next is the 3CD icon is for the 3CDaemon. This is a simple FTP, TFTP and
Syslog server (Note that not all PCs will be running this application).
7.5.3. Then there is the clock. We need to make sure all the times/timezones match for
logging purposes. Perform the following on all Servers first, then the PC
systems :
7.5.3.1. Right click on the clock and select Adjust Date/Time. The Date/Time
Properties window appears. Adjust the clock to reflect the current time in your
classroom even though the time zone may be different from your current
location.
7.5.3.2. Select the Time Zone tab.
7.5.3.3. Use the drop down menu to choose the Pacific time zone for your class
location. We will be using the Pacific time zone for all classes even if your
class is not being currently held in that time zone since the Cisco MARS
defaults to PST
7.5.3.4. Select the option to automatically enable Daylight Savings Time (if not
already chosen).
7.5.3.5. Click OK.
7.5.3.6. All of the VMs should sync up to the appropriate time (except the DMZ-
Srv which doesnt have connectivity yet) within a few minutes. Do not wait for
the synchronization to complete since the domain PCs will synchronize on the
next reboot or within 45 minutes,
Note You will not have access to change the time on the Access-PC. This PC is only
used for console access to our network devices and is not included in the
network topology.
The Network Devices
In the MARS lab environment you will have access to a MARS 20 Appliance, an ASA 5520
Firewall, two IOS routers, an IPS Appliance and a Catalyst 3560 switch. In most cases you will
access these devices for management using SSH or a secure web browser connection. But in
some scenarios you will need direct console port access. For example, the MARS Appliance
doesnt even have an IP address set at the beginning of the labs. You must initialize it from the
console port before you can access it via a remote access protocol (if you do not want to use the
default ip address of the MARS). In this section of the lab you will see how to access the devices
by their console ports.
8. Access the desktop of the ACCESS-PC.
9. Launch Windows Internet Explorer if not already open.
On the main webpage for your POD, all PODs will indicate POD1, even though
you may have been assigned a different pod number.
10. On the main webpage will be a list of devices on the left :
L3-Switch: The 3560 Switch that all other devices are physically connected to.
Separation of these devices is accomplished with VLANs.
Perim-Rtr: The Internet/Perimeter Router and also the TIME.NIST.GOV server.
ASA: The Cisco AAS 5520 Firewall which will provide us DMZ access and VPN
access in subsequent labs.
MARS-Site1-Rtr: The router at the remote office.
MARS-Supp-Sw: The switch that the IPS is physically connected to. You will not
see this device in the lab topology. The instructor can give you a better understanding
of the location of this device
IPS-Sensor: The IPS appliance protecting the DMZ from outside attacks and
generating alerts to be sent to the MARS Appliance.
CS-MARS: The MARS 20 Appliance where syslog and netflow data is sent for
analysis.
11. Open Windows Explorer on the Data-Srv. You should see the D: drive named MARSv3.0.
This is an ISO CD that contains all the software and licenses necessary for the remaining
labs.
12. Select the MARS3.0 drive.
12.1. Notice there are several files located on the drive ranging from port scanning software
to the latest MARS upgrade package that we will use in later labs.
13. Test access to the Perimeter Router: You will be directed to log in to these devices at other
points in the lab. For now, login to the Perimeter Router as a demonstration.
13.1. On the Access-PC expand the Perim-Rtr link and select the hyperlink to access
Hyperterminal. HyperTerminal will start.
13.2. You will be challenged for a password. The device offering the challenge is the GK
Access Server, not the Perimeter Router itself. Enter the password that you were
assigned for remote lab access. (This is the password associated with your mars
username that provides access to the Remote Desktop Client to the remote lab
environment).
13.3. You should now have access to user mode on the router. The prompt will be MARS-
Perim-RTR>. If you want to gain access to privileged mode you can simply use the san-
fran password.
13.4. For a quick demonstration of concept, enter the command show user. You should see
there is one user logged in (you), and you are logged in to line con 0. This is a direct
connection to the routers console port.
13.5. Use the command exit to log out of the Perimeter Router.
13.6. Close the HyperTerminal window. Every time you close a Hyperterm window and go
back to access a console port, you must re-enter the password for the mars user
provided by your instructor and hit enter twice.
14. There is an additional access method which will be used in certain circumstances. Here are
two examples.
If the Access-PC gets confused, you may need to clear the line on the access server which
is attached to your devices console port.
If you use non-standard passwords for any of the devices and you forget that password,
you will have to perform password recovery, which requires a power off and power on of
the device.
15. For situations like these, you must use this alternate access method. That method will
quickly be demonstrated here:
15.1. Minimize the Remote Desktop Client window on your classroom PC, not the remote
desktop session.
15.2. On your local PC, launch Internet Explorer.
15.3. Enter the URL https://www.remotelabs.com.
15.4. Enter the same mars username and password that you used to connect to the Remote
Desktop server.
15.5. Notice that you have access to the same devices that were listed on the Access-PC in
the lab remote desktop environment.
15.6. To summarize, you can access the remotelabs.com network via the Access-PC in the
lab or web browse to it from your PC in the classroom.
Understanding the Topology
Take a moment to look at and understand the topology.
16. Note the topology displayed in the diagram. You have 8 subnets under your control:
The Data Center Subnet: 10.10.1.0/24.
The DMZ Subnet: 172.16.1.0/24
The Outside Perimeter Subnet: 200.200.1.0/24
The Inside Perimeter Subnet: 10.10.0.0/24
The Management Subnet: 10.10.2.0/24
The End User Subnet: 10.10.10.0/24
The Site1 User Subnet: 10.20.10.0/24
The Site1 WAN Subnet: 10.20.0.0/24
17. Note that the internal and the DMZ networks use RFC 1918 address space. These addresses
are not routable on the internet. So the ASA Firewall must perform address translation,
making systems on the DMZ and the Inside networks appear to be on the globally
reachable 200.200.1.0 network.
18. Access the desktop of the Data-Srv:
18.1. Launch Internet Explorer.
18.2. Browse the URL http://50.50.50.50. This is the Services-R-Us Server and will be
used to confirm that our ASA is passing traffic correctly.
18.3. Note the web page displayed indicates that you are connected to the correct website.
All of the PC/Servers are running a web server and have home pages that are similarly
configured.
18.4. Close Internet Explorer.
18.5. While it cant be demonstrated at this point, note that if the Admin-PC or DC Data-
Srv references the DMZ server they will use the real IP address (172.16.1.15) and not
the natted ip address.
18.6. On the other hand, when the Outside PC references the DMZ Server it must use the
publicly available translated IP address (200.200.1.15).
Note One final note. The Windows Clip Board works between the RDP client
application and the local PC. If you would like to capture data, such as
configurations created during class, you can use standard Windows copy and
paste procedures to highlight text in a lab PC system and paste it into, say,
WordPad on your local PC. You can then save that text file to, for example, your
USB memory key on the local PC.
LAB COMPLETE
Please let your instructor know that your
Pod has completed the lab
L2
Lab 2: Bootstrapping the
MARS Appliance
Lab 2 Bootstrapping the MARS Appliance
Lab Overview
In this lab we will be bootstrapping the MARS Appliance. We will perform a basic
configuration as well as getting used to some command line options within the MARS.
There are several newer commands available in versions 6.x that we will explore and
later revisit at the end of the course. You will log into the MARS for the first time and
enter the appropriate licensing information. Emphasis will placed on getting used to the
GUI and maneuvering around the interface of the MARS. Once the configuration is
verified, we will indentify all of our reporting devices in our network on a generic
template to be used in the subsequent lab.
45 minutes
Lab Procedures
1. Basic command line options
2. Bootstrapping the MARS
3. Device Inventory
Bootstrapping the MARS
In this section you will be performing a basic configuration on the MARS appliance. We will
walk you through the configuration process as well as some command line options to better your
understanding of the MARS product.
1. Log into the Remote Labs remote desktop session if you have not done so already.
2. Click on the Access-PC tab at the top of the VMWARE console window. Internet
Explorer should already be opened prompting for credentials. Use your credentials
provided by your instructor on the first day of class to log into the webpage.
3. Scroll down the left window and expand the CS-MARS link.
4. Click on the Hyperterminal link.
5. You will be prompted for a password after some banner information is displayed. The
password that we are requesting here is the password provided by your instructor on the
first day of class and the same password you used to log into the Remote Desktop
Connection. Press Enter twice after entering the correct password. You should now be at
the following prompt: You will be asked for the login username and password for gaining
access to the MARS console. The username is pnadmin and the password is pnadmin.
6. At first login you will notice that the MARS appliance is requesting that you change your
password from the default. Make the password the same to make the labs easy to
remember. Please enter pnadmin for the password and reconfirm the password when
requested.
[pnadmin]$
7. Please do a ? here at the prompt and notice the various commands available. Here is a
current list of available commands with 6.x version of code:
[pnadmin]$ ?
Commands are:
? - Print list of available commands
arp - Display/manipulate/store the arp table
date - Set/show date
diskusage - Report filesystem disk space usage
dns - Add/remove/show domain name resolving servers
dnssuffix - Add/remove/show domain name suffixes search path
domainname - Set/show domain name
exit - Switch to standard mode/Logout
gateway - Show/set default gateway
help - Print list of available commands
hostname - Set/show host name
hotswap - hot add or remove disk
ifconfig - Configure/store network interface
model - Display the model info of CS-MARS
netstat - Show network statistics
nslookup - Look up the IP address or domain name
ntp - Synchronize system clock with ntp servers
passwd - Change password
ping - Ping a host
pnimp - Import Gen-1 box's configuration and events into this MARS
pnexp - Export database content including configuration, events
pnlog - Show system log/ set log level
pndbusage - Show database usage info
pnreset - reset the whole box to factory defaults
pnrestore - restore system configuration and data
pnstart - Start CS-MARS applications
pnstatus - Show running status of CS-MARS applications
pnstop - Stop CS-MARS applications
pnupgrade - System upgrade
predictfsck - Predict the fsck at next reboot
raidstatus - Display the status of disks
reboot - Reboot System
route - Configure/store routing tables
show - Show inventory and health monitoring information
shutdown - Shutdown system
snmpwalk - communicates with a network entity using SNMP GETNEXT requests
ssh - User interface to the SSH protocol
sslcert - Generate a new self-signed ssl certificate
ssllist - List existing ssl certificates
syslogrelay - Show/Modify Syslog relay configuration
sysstatus - User interface to the Unix top command
tcpdump - Dump traffic on a network
telnet - User interface to the TELNET protocol
time - Set/show time
timezone - Set/show timezone
traceroute - Trace the route to a host
unlock - Unlock GUI accounts
version - Print the version
Note As of the writing of this lab the current version of software is 6.x. There are 3
newly added commands available to us which began in 4.3.1 code. The
syslogrelay which behaves like a Kiwi Syslog relaying agent to reflect syslog
data to other internal syslogs, the unlock command which allows an admin to
unlock a user who has been locked out due to failed password attempts, and
pnexp, which allows us to export configuration data as well as determine the
number of devices and rules currently configured on the appliance.
8. Execute the model and version command to get a listing of the model and current
software version you are currently working on.
What model is it? _____________________________________________
What version of software is it? ___________________________________
9. Run the diskusage command to get a listing of current drives on the system and the
current amount of drive space left. The partitions listed are important since partitions will
automatically be overwritten once the previous partition reaches 75 percent of capacity.
We will discuss this later in much more detail.
For all MARS Appliance models, the Oracle database has three partitions:
/u01: Stores the Oracle binary files.
/u02: Stores the data files.
/u03: Stores the replay log files, which are cached, in-memory working files not
yet committed to the data store.
The size of the data partition (/u02) varies based on the model.
10. Another useful command is the pndbusage command that has been recently added to the
operating system. This command is very handy in determining the current database size.
Based on an estimate, it will provide a date and time when the database will be moved to
the next available partition as we indicated in the previous step.
Note We will be coming back to these commands at the end of the course and will
describe the details of each command .There are over 40 commands available
to us at the command line. Please poke around a little to get a feel for what
some of these commands do.
11. Type in the new command pnexp. You will note that you are placed into a sub-mode.
Please enter help to get a listing of valid subcommands. You should notice the
following options:
=================================================================
pnexp> help
Commands are:
quit|exit - Quit this program.
status - Show current data exporting status.
log {all|recent} - Show all or recent data exporting log.
data - Show number of events/report results/statistics/incidents in
database.
config - Show number of devices, reports, rules etc in database.
stop - Stop the data exporting process.
esti_time [MM/DD/YY:HH] - Estimate how much time/storage will be needed to ex
port event data received after the specified time. If the last argument is not
given, default is for all event data in database.
export {config|data|all} {nfs_path} [MM/DD/YY:HH] - Export MARS config ({config
}), or events/reports/statistics/incidents ({data}), or both ({all}) to the spec
ified NFS path ({nfs_path}). If the last optional argument is given, only
data received after that time will be exported. Example: export all
10.1.1.1:/mars/archive 02/28/07:00
=====================================================================
Note The export command seen above is only used for the migration from a Gen 1 to
a Gen 2 MARS appliance. If you notice, there is no pnimport command as there
is in a Gen 2 MARS, indicating the migration path from a Gen 1 to Gen 2 only
and not the other way around.
12. While still in the pnexp mode execute the config subcommand and press enter.
Answer the following questions related to the current configuration of the MARS
appliance.
How many rules are currently on the system? _______________________________
How many devices are currently configured? _______________________________
How many various reports are there? ______________________________________
13. After typing exit, run the ifconfig command to see the current interfaces and ip
addresses. It should resemble the following:
[pnadmin]$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:8F:F5:4B
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8073 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4843962 (4.6 Mb) TX bytes:256 (256.0 b)
Base address:0xd100 Memory:f9000000-f9020000
eth1 Link encap:Ethernet HWaddr 00:30:48:8F:F5:4A
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Base address:0xb000 Memory:fa100000-fa120000
Write down the MAC address of your Eth0: ________________________________
You will need this to determine the proper license key to use for activation.
14. Basically on command line you will not be performing any configuration other than
changing the ip address of the interface. One you have changed the ip then the rest of
the configuration will be performed via the gui. There are however, very useful
troubleshooting commands you can use at the command line, some of which we have
indicated in previous steps. Lets perform a basic configuration and change the ip
address of the system. Please enter the following command to change the ethernet0 ip
address: ifconfig eth0 10.10.2.100 255.255.255.0
Note After entering the above command, the appliance will request a reboot. Please
answer yes to any prompts to ensure a clean reboot.
Expect the reboot to take a minute or two. When the reboot is complete, the login
prompt should appear again. Once the system reboots, you must once again login with
the username pnadmin and password pnadmin in order to gain access to the console.
15. On the console of MARS enter the gateway command to set the default gateway of the
appliance by entering the command gateway 10.10.2.1 as indicated by the following
output.
16. Verify your MARS appliance is setup correctly by pinging the Admin-PC upon
rebooting your MARS. Ping 10.10.10.10 (the Admin-PC) from command line of the
MARS appliance. If this is successful then you have completed this section
successfully. If you cannot ping the Admin-PC from the MARS appliance please
revisit the ifconfig commands to verify you have configured the interface correctly.
Once you have verified that you can access the Admin-PC, you can stop the ping by
issuing ctrl+c at the MARS console. The output should resemble the following:
17. In order to time sync the MARS appliance with the rest of the lab environment, enter
the following command: ntp server 192.43.244.18 (this is the ip address of the
time.nist.gov time server being used in the pod. The MARS sets its timezone to
Pacific Time by default. Your output should resemble the following:
Note This will reboot the backend service and will take a few minutes.
Verifying the GUI
18. Go to the Admin-PC and open the Internet Explorer icon on the desktop called MARS
Access. Please browse to the MARS appliance by using a https connection to
10.10.2.100 (https://10.10.2.100).
19. Accept any certificate errors or dialog boxes. You can save the certificate to the
Microsoft Certificate Store so you will not be prompted for the remaining duration of
the class.
20. The main page of the MARS appliance should appear as the following:
Note SVG Viewer is required to be installed prior to using the MARS appliance. The
first time you browse to the box it will prompt you to download the free plugin.
We have preinstalled the plugin for you since the lab topology has no direct
access to download the plugin. The location of the plugin is
http://www.adobe.com/svg/viewer/install/auto/ . Also note that this plugin is
discontinued from Adobe. Cisco will be developing their own plugin in a future
release.
21. Login using the username pnadmin and the default password of pnadmin. Choose No
if asked to remember passwords, and accept any license agreements that appear.
22. Once you login you will notice that you really cannot maneuver around anywhere in the
GUI without entering in the license key. Below you will find a license key which is
based upon your pod. Please use the appropriate key for your MARS appliance. Enter
the following license key for your appliance and click submit (License is Case
Sensitive and based upon your MAC address determined in Step 12):
License Key Ethernet0 MAC Address
3GWGR-VH65Q-ETGQM-HFBWE-MU9DV 00:30:48:8F:F5:4B
TJJTM-LR8HU-EMJ9Y-UM82P-RDLJW 00:30:48:8F:F5:5F
3OXMH-UQTHS-6D46J-7J9V1-1MM86 00:30:48:8F:F5:3D
MAV97-ZN6B6-VSYY5-FJ3UE-UOGAH 00:30:48:8F:F4:37
RGMM2-A5DA8-4BMY8-Z1GU3-GNB78 00:30:48:8F:F6:6F
43PB9-CSHC5-P6CAW-4ZMDI-5TYQP 00:30:48:8F:F6:03
1RUPS-5JKF6-F8R6K-BAKR4-BDV3X 00:30:48:8F:F6:CF
P6FMJ-2V34K-E9Q2I-VYOGB-5TG6L 00:30:48:8F:F7:4F
BVSKC-213TE-VF94H-S2Y3K-9CBXW 00:30:48:8F:F5:37
AV5D7-RRBRL-KVGYG-467PC-22EA5 00:30:48:8F:F4:2D
DAFLL-BWLQU-X8JZ6-H1DGP-MWNAZ 00:30:48:8F:F5:35
AL1JK-N8E86-N5G1G-DFS7R-S28YE 00:30:48:8F:F5:33
LWAR9-4ZXE8-MX5D3-8VEU4-1OS1T 00:30:48:8F:CD:59
FON51-WFZO5-ZGYQ1-TEQWM-6DVE6 00:30:48:8F:F4:CB
QAGE9-DKVMX-52WEU-XZOCG-UU8IR 00:30:48:8F:F6:19
AZ8WG-WRLIL-7KT2S-R5MN8-2DHED 00:30:48:8F:F5:43
H6TI2-2U7BD-TPVZB-91DA8-S3QIA 00:30:48:8F:F7:69
A6J1A-H6GAW-HCLXE-WKQW7-MR6V3
00:30:48:97:E4:E1
CNWSH-F81TM-TFMNW-Y81GI-FQNQK 00:30:48:8F:F4:03
Once you click submit, you must accept the license agreement at the bottom of the next
page by clicking on the button that says AGREE.
23. Click the Admin tab at the top right of the page.
24. The admin tab contains a few sub tabs located just under the main title bar as indicated
here.
Select the System Setup > Configuration Information option to display the next
configuration steps.
25. Take a look at the interfaces listed. The Ethernet0 interface is the interface Cisco is
recommending communicate with your network devices. Notice that it is the only
interface that has a default gateway. Notice that the Ethernet1 interface does not have a
default gateway. This means that if you plan on managing the MARS appliance on
interface Ethernet1, you should make sure that the host managing the MARS is on the
same subnet as Ethernet1. If not, there is always the option to add static routes at
command line.
26. In the name field enter the name POD#. Please replace the # with your appropriate
pod number assigned by your instructor.
27. For the Default Gateway, verify the IP that is listed is 10.10.2.1
28. The MARS appliance has the capability of generating reports and emailing them along
with cases to users you have configured in the MARS. To support this widely used
feature, enter the ip and domain information of your mail server in the Mail Gateway
section of the page. In our labs, the Data-Srv is running is providing SMTP services.
Mail Server: 10.10.1.10
Mail Server Port: 25
Email Domain: gkl.local
Note You may notice a newer option available which allows full graphics. If using
Lotus Notes in your network, selecting this option can crash your mail server
which is why the Minimal Graphics option is provided.
29. For the Primary DNS, enter 10.10.1.10 and add gkl.local to the list of search domains,
then click the Add button.
30. Click Update to accept the changes.
Note You will notice a status message popup indicating the MARS is going through a
reboot. If you have a popup blocker enabled you will not see the status
messages appear indicating a reboot is occurring. The only message you will
see in that case is the broadcast message being sent from command line.
Please allow several minutes for the reboot.
31. Click the OK button when asked to reboot. Click the OK button to any status messages
that appear.
32. Click OK on the following popup window.
33. You can verify the reboot by accessing the command line console from the Access-PC
and waiting for the login prompt to appear
34. After reboot please log back into the appliance and verify your settings by browsing
back to System Setup > Configuration Information.
Device Inventory
Many of us in the field like to jump right into the configuration of our network equipment.
Before moving through the configuration lets prepare for the install by filling out this worksheet
which will help us in the next lab. The goal is to provide you with a template you can use in
your own environment to help facilitate the install. Please fill out the following form to the best
of your knowledge based on the topology described in the lab. Include software to be monitored.
Device Name
(Based on
Topology)
Location
(Physical
Location)
Access IP,
Reporting IP
Device Type
(Router/SW/FW)
SNMP RO
String
MARS4reading
MARS4reading
MARS4reading
MARS4reading
MARS4reading
MARS4reading
MARS4reading
MARS4reading
MARS4reading
MARS4reading
MARS4reading
MARS4reading
LAB Complete
Please let your instructor know that
your Pod has completed the lab
L3
Lab 3: Importing Hardware
Devices to MARS
Lab 3 Importing Hardware Devices to MARS
Lab Overview
The MARS appliance is only as good as the data the reporting devices are sending to it.
In this lab we will provide three methods for loading the networking devices into the
MARS, Auto Discovery, Manual and Seed File. We will be configuring the appropriate
SNMP settings in the MARS to support your various networking device for resource
utilization. We will also be visiting the Routers, switches and ASA in this lab to correctly
configure the SNMP and appropriate logging commands. After all the devices are added
to the MARS appliance, we will show how to perform a basic query.
60 minutes
Lab Procedures
1. Auto Discovery of Hardware Devices
2. Managing Your Hardware Devices
3. Manually Adding a Hardware Device
4. Adding a Hardware Device with a Seed File
Auto Discovery of Hardware Devices
Its time to add reporting devices to our MARS. Remember from your discussion in class that
most hardware devices will be reporting to MARS using syslog (other option is SNMP). If you
have a firewall between the monitored equipment and MARS you will need to allow this syslog
data through which is using UDP port 514.
This first section will add most of our network devices automatically using the Auto Discovery
feature.
1. Log into the Admin-PC and access your MARS via its web interface. Remember that it
uses https and not http.
2. Click the Admin tab.
Note Notice the Authentication Configuration option available. We will be configuring
this later as this newly added function allows Radius authentication support as
of version 4.3.1
3. In order to support our topology discovery, we need to create a few basic SNMP parameters.
Click on Community String and Networks link
4. In the Community String field, enter the string MARS4reading
5. Next add in the networks that use this community string. In your own network, this option
will allow you to use different community strings with different subnets. In our network we
will be using the same community string with all our networking devices. Select the radio
button next to Network IP, then please enter 10.0.0.0 with a mask of 255.0.0.0 and click
Add.
6. Click Submit.
7. Notice the Activate button turned red on the top right of the screen. This is a newer feature
indicating when to press the Activate button. We do not need to Activate just yet since we
have a few more configuration tasks to complete.
8. Click the Back button at the bottom of the page to take you back to the main Admin tab.
Configure Hardware Devices for SNMP Support
Before going to the next step lets get a few SNMP parameters in the networking equipment.
Remember in a production environment you can have multiple SNMP community strings. It
would be advisable to use a community string that MARS can use and another SNMP string for
monitoring from you Network Management Software (NMS). It also helps those organizations
that have a separate Security Operations Center (SOC) from their Network Operations group
since those types of networks like to limit each others access to various types of equipment.
9. Go to the Access-PC.
10. On the Internet Explorer webpage, expand the L3-Switch link to the left of the webpage
(you may need to login again to the webpage if it has logged you out).
11. Click the Hyperterminal link.
12. You will be prompted for a password. This password will be your POD password assigned
by your instructor on the first day of class. After entering the password please press enter
twice. Remember that the password you are being prompted for is the Global Knowledge
console server and not the Cisco equipment itself.
13. You should now be at the user mode of the Layer3-Switch. Please enter privileged mode by
typing in enable. The password you are now being prompted for is san-fran.
14. Take a look to see if there are any current SNMP settings on the switch. Enter the command
show run | include snmp and press enter. You should see that there are no current snmp
configurations on the switch. Note that due to code upgrades that occur in our labs, you may
see default snmp commands in the configuration.
15. Proceed into Global Configuration mode by typing config terminal and pressing enter.
16. Enter the following commands to enable SNMP on the switch.
Note If you decide to use an ACL (in your own network) to restrict SNMP polling
(which you should), remember to add MARS to the allowed list of polling
devices.
MARS-L3-Sw(config)#snmp-server community MARS4reading RO
MARS-L3-Sw(config)#end
MARS-L3-Sw#write mem
MARS only supports SNMPv1 only. Currently there is no roadmap for any other
version.
17. Enter show run | include snmp and press enter to confirm the correct string is present.
If this is your first deployment using SNMP strings, you may want to use a time
saving programs such as Kiwi Cattools (located at kiwisyslog.com) which can
push out this configuration to all your devices in one sweep.
18. Repeat Steps 9 through 17 for the Perim-Rtr.
19. Repeat Steps 9 through 17 for the MARS-Site1-Rtr.
20. The SNMP command for the ASA will vary slightly. You will need to enter the following
two commands in global configuration mode of the ASA.
MARS-ASA(config)# snmp-server community MARS4reading
MARS-ASA(config)# snmp-server host inside 10.10.2.100

21. Return back to the Admin-PC to complete the remaining tasks.
22. We can perform our initial discovery of our network devices now that our SNMP community
strings have been updated in our network equipment. You may need to log back into the
MARS since the auto logout probably kicked you off by now. Click Admin > System Setup
> Valid Networks.
23. What we are going to do next is identify our seed networking device to discover the
associated network. In the SNMP target enter in 10.10.2.1 which is one of several IPs on our
Layer 3 switch.
24. Select the radio button next to the Network IP field, and enter 10.10.0.0
25. In the Mask field, enter 255.255.0.0
26. Click Add.
27. Repeat steps 23 through 26 to add the 10.20.0.0/16 network with the same seed IP address.
28. Click Submit on the bottom right of the screen. You have just identified a seed device to
start the topology discovery of our network.
29. Now click the Activate button on the top right of the screen which should appear as red. A
popup will appear indicating the completion of the activation. Close the popup after reading
its contents.
30. You may need to allow popups in the status bar for Internet Explorer in order for the page
refresh to complete.
31. Click Discover Now on the bottom right screen. You will notice the Activate button again
turn Red. This indicates new devices have been discovered and are ready to be committed
into the database.
Note A status page will appear informing you that the discovery process has started.
Depending on the size of your own production network, this could take a long
time. The process will continue in the background allowing you to proceed with
the remaining configuration tasks. In our case, our network is fairly small and we
should be able to click the click here link in the status message to see our
discovered devices.
32. The list of discovered devices should look similar to the following.
Note If no devices appear after a few minutes (be patient) and you are sure you have
completed this section of the lab correctly, go to the command prompt of the
MARS and issue the PNSTATUS command. If an error is returned to you
indicating a janus.conf file mismatch error, please go back to the GUI and
rename the MARS (use any hostname) and Reboot the MARS. After reboot,
rerun the discovery. Note that you must change the hostname from the GUI
and not command line for this to work
33. Click the Activate button if it is Red to commit these devices to the database.
34. At some point you will need to upgrade the software on devices that are already present in
the MARS. You can easily change the version of software running on the device from this
page. Select the MARS-Primary-ASA.gkl.local device and click the Change Version
button. You will notice a popup allowing us to change the revision of code running on the
ASA (8.0 and 8.1 is now supported).
35. Do not change the version of ASA code and close the popup. We just wanted you to see the
process of changing versions.
Note In the latest versions of MARS code, the software code running on the device
will automatically be determined and modified in MARS during the initial
discovery.
36. Click on Admin > System Setup > Security and Monitor Devices. You will notice that the
page displays the same information as seen in the topology discovery. You can always revisit
your list of devices by coming back to this link.
37. Click Back
38. Click Topology/Monitored Device Update Scheduler. The scheduler is a SNMP sweep
that occurs at a particular interval of your choosing. You will notice that the default settings
do not have a discovery interval setup. This is quite different from older software revs where
the default discovery interval was at midnight at the first of every month. This discovery
will allow MARS to review the configuration on devices in the network and discover routing
and ACL information (used in providing mitigation commands).
39. Select the Default Discovery Group and click the Edit button.
40. Select the schedule to be Daily at 12 Noon
41. Click Submit.
42. Click Activate at the top right of the screen.
43. Close the activation popup window.
44. Select the Default discovery Group and click the Run Now button to allow MARS to
discover configuration settings on these devices.
Managing Your Hardware Devices
45. Click on the Summary tab on the top right of the screen.
46. On the Dashboard page notice the Hot Spot Graph and the icons drawn. You really cannot
determine a full topology from this graphic. Everything in the cloud is currently hidden. On
this page the cloud indicates that there is network equipment located in the topology.
47. Click the Full Topo Graph link in the graphic to bring up the details of the network devices.
The topology should resemble the following with only three network devices plus the MARS
itself.
Icons and States in Topology
Healthy Attacker Compromised
Compromised
and
Attacking
Clouds
Firewall
Reporting Host
Host
IDS
Network
Router
Switch
Global Controller
(Global Controller
or
Local Controller)
48. Click the Dashboard link.
49. In the Hot Spot Graph click the Large Graph link. This is just a larger viewing area of the
Hot Spot Graph.
50. Double click the cloud in the diagram. You will see you have drill down capability.
51. Double click the MARS-Site1-Rtr as an example of drill down. A popup should now be
displayed showing you the current interfaces/IP addresses on the router. Lets look at more
detailed information by clicking the More info on this device link.
52. Close all of the popups when you are done viewing the device details.
Note One piece of info that does frustrate engineers is that still in version 6.0 as it did
in previous release, you still cannot drag and move the diagram icons around.
53. Go to Admin > System Setup > Security and Monitor Devices.
54. Under the Device Display column click the clouds on all three network devices. This will
allow our network devices to be seen in detail and not clouded in the Hot Spot Graph in the
Dashboard. The reason we have this option is because it may not be apparent here in our
topology but in a production environment, one hundred network devices cannot fit in the Hot
Spot Graph very nicely and it usually looks like a spider web. The clouding option allows us
to hide devices in the graph.
55. Click the Activate button if Red.
56. Return back to the Summary > Dashboard and notice the detailed Hot Spot Graph
displayed.
57. Go to Admin > System Setup > Security and Monitor Devices
58. Prior to this newer version of code, the MARS did not automatically configure the Reporting
Device IP address when auto discovery was used. This meant that we had to go back and
configure each individual device with the correct Reporting IP, which is usually the same IP
address used to access the device. We will revisit our devices to show you the various
configurable fields and to allow the monitoring of system resources. Select MARS-L3-
Sw.gkl.local and click Edit.
59. You will notice that SNMP is automatically chosen since the device was discovered using
SNMP. Unfortunately SNMP RO access only provides MARS basic information about the
device including interfaces, MAC addresses and some IP info. However, it will not discover
ACL/Configuration information. In order to support that type of discovery, Telnet or SSH is
recommended. In the Access Type field, choose Telnet. The telnet and SSH access type will
gather the same information from the network device (routing and ACL info). If you chose
SNMP as the access method, limited information will be gathered (no ACL info) such as
routing and interface information.
60. In the Password field enter cisco.
61. In the Enable Password Field enter san-fran.
62. Choose Yes to monitor system resources. MARS will go out and monitor the resources of
this device every 5 minutes (not configurable ) via the SNMP community string on this page.
63. Click Submit at the bottom of the page.
64. Click the Activate button on the top right of the page and close the Activation window when
it pops up.
65. Go back and edit the Layer 3 switch and click the Discover button to force the MARS to
perform device level discovery Click OK when done..
Note If there are any errors with login access to the device an Error Report button
will be made available in the bottom right of the screen for troubleshooting. If the
error looks as if the banner on the switch is the cause of the error, it is not. In
fact, MARS is only showing you a partial screen shot of the error. The cause is
usually the credentials not being correct on the previous steps.
66. Click the Submit button on the bottom right of the page.
67. Select the MARS-Primary-ASA.gkl.local device and click Edit.
68. Notice that the Access Type is not chosen here nor is SNMP a valid option. Choose SSH
from the Access Type drop down box.
69. In the Encryption Type drop down box select 3DES.
Note The MARS appliance will login to the ASA using SSH version 2 since thats
whats enabled on the ASA.
70. In the Login field type mars. This is an account we have created on the ASA appliance to
provide MARS access.
71. In the Password field type san-fran.
72. In the Enable Password field enter san-fran.
73. Click Yes to Monitor the Resource Usage. Remember from your discussion in class that
monitoring resource usage can burden MARS and is advisable to still use your 3
rd
party
monitoring software.
74. Click the Submit button. The popup is informational indicating that no new modules have
been added such as the AIP-SSM.
75. Click OK to submit. You will be returned back to the main devices page. Select the ASA
again and click the edit button.
76. Click the Activate button at the top of the page if it is red and then click the Discover button
at the bottom of the page. Click OK to the popup windows that appear.
77. Click the Back button at the bottom of the page.
78. Select the MARS-Site1-Rtr and click Edit.
79. Select Telnet as the Access Type.
80. In the Password field enter cisco.
81. In the Enable Password Field enter san-fran.
82. Choose Yes to monitor system resources.
83. Click the Discover button on the bottom right of the page to perform an Ad Hoc discovery of
the device. Click OK when discovery is done.
Note If there are any errors with login access to the device an Error Report button
will be made available in the bottom right of the screen for troubleshooting.
84. Click the Submit button on the bottom right of the page.
85. Click the Activate button if Red.
Running a Query
86. Lets run a quick Query against our devices to see if there are any events reported. Go to the
Query/Reports tab.
87. Lets run the default report without modifying any report parameters. Simply click the
Submit Inline button on the bottom right of the screen. You will notice the results are not
very informative. You should see a result of an unknown reporting device with several hits
associated. You cannot click on any of the fields and clicking the icon next to the
unknown reporting device only allows you to run a similar query to the one you just
generated.
88. Lets rerun the query with a different format to see these more details on the results of the
report. In the Query Type section click Edit.
89. In the drop down for the Result Format, select All Matching Event Raw Messages and
click Apply.
90. You will notice that the only parameter changed is now the Query Type.
91. Click Submit Inline. This option makes the query run immediately. If there are a lot of
events in the database, then this process will take a long time. In the circumstances where the
results can be viewed at a later time, the Batch Query button will be seen on the screen in
place of the Submit Inline. If MARS determines the query will not take a long time to run,
the Batch Query option will not be available.
92. You should see several Events at the bottom of the page. One of them should look like the
following and is used to show you a proof of concept on how to retrieve raw event details
from a Query. Notice the Raw message is indicating a reporting device is sending
information to the MARS but the MARS does not recognize it as a reporting device yet. Its
now important to mention that there is a hidden switch in our network topology. This MARS
Supplement switch is a Cisco 2950 switch and is what the IPS in our topology is directly
connected to. Feel free to issue a show cdp neighbor command from the L3-SW to see its
exact location or have your instructor walk you through our lab topology. This switch has
already been configured with the appropriate SNMP community strings and logging
commands to send messages to MARS which is what you are seeing in your query.
Note We have generated these messages for you automatically. You will notice in
the system tray on the Admin-PC. This is the Kiwi Cattools program we
mentioned earlier in class. It is setup to log into the MARS Supplement switch
and administratively shutdown and no shutdown the fastethernet 0/3 interface to
generate syslog events every 5 minutes.
93. We will add this Unknown Reporting Device in manually in the next section so MARS can
process any incidents/queries/reports based on these syslog messages.
Manually Adding a Hardware Device
Any device that is listed as an Unknown Reporting Device needs to be added into the MARS. In
our case the Unknown Device is a Layer 2 switch with the management ip address of
10.10.2.253. If we think back, we added the 10.10.x.x address range to be automatically
discovered. Based on that information, answer the following questions to the best of your
ability.
Did you expect this L2 switch to be Auto Discovered? _________________________________
Why or Why Not? ______________________________________________________________
94. To show you how to add a device in manually, click on Admin > System Setup > Security
and Monitor Devices.
95. Click Add.
96. Under Device Type select Cisco Switch-IOS 12.2
97. For the Device Name field, type MARS-Supp-Sw
98. For the Access IP and Reporting IP fields, type 10.10.2.253.
99. For the Access Type drop down, select Telnet.
100. In the Password field, type cisco.
101. In the Enable Password field, type san-fran.
102. For the SNMP RO Community string use MARS4reading. Remember that we are
only using this string for monitoring resource utilization.
103. Choose Yes to Monitor Resource Usage.
104. Click the Discover button on the bottom right of the screen. A popup should be
displayed letting you know the Discovery process is complete. Click OK in the status
window.
105. Click the Activate button on the top right of the screen.
106. Click Submit.
107. Notice that the device is now added to the list of discovered devices on the main
device page. Also notice the name of the device just added changed to MARS-
Supplement-Sw.gkl.local. It turns out it doesnt matter what name you manually enter
in the name field, the hostname of the device will automatically populate the field after
the initial discovery is complete.
108. Visit the Dashboard and notice the device is now listed on the Hot Spot Graph.
Note In your own network environment, you will probably have a lot of layer 2
switches to add. Unfortunately you MUST add these in manually. There is one
other way you can add the devices rather quickly which is the purpose of the
next section.
109. Within 5 minutes, the supplement switch will generate more syslog messages and
forward them to MARS. By running the Query again as indicated in Steps 86 through
92, you should now see the MARS processing events from the MARS Supplement
Switch.
Adding a Hardware Device with a Seed File
As you know by now, all Layer 2 switches must be added in manually and cannot be auto
discovered. This data input would usually be a job handled by a junior engineer but we want to
also show you a method of adding devices via a seed file. The file needs to be a CSV file
defined with 20 different Columns (although not all columns are used).
110. On the Data-Srv open Windows Explorer and browse to D: drive named MARSv3.0.
Open the folder named Base_Configs. Locate the Seed-File.csv file in the directory
and copy the file to the c:\FTPROOT directory.
111. Open the CSV file to view the contents. Each field requires specific contents that can
be found in your Student Course Manual.
112. On the MARS, go to Admin > System Setup > Security and Monitor Devices.
113. Click Load from Seed File.
114. In the IP Address field, type 10.10.1.10.
115. In the User Name field, type anonymous.
116. In the Password field, type mars.
117. In the Path field, type /
118. In the File Name field, type Seed-File.csv
119. Click the Submit button.
120. An error will appear in the following popup window. This error is caused by the
MARS attempting to perform a reverse DNS lookup on the IP address listed in the
Seed File for the Perimeter Router. Because there is no DNS entry for our network
device, the following error will appear but the device will still be added. Click close
when done reading the message.
121. If you would like to see the details yourself , look in the backlog located at Admin >
System Maintenance > View Log Files.
122. On the main Devices page you will see the 200.200.1.1 device now entered at the top
of the list. We will need to discover the device to pull the device specific information
(such as routes and ACL info) and update these fields listed.
123. Select the entry from the list with the IP address 200.200.1.1 and click Edit.
124. Click Yes to Monitor Resource Usage.
Note The Seed File option cannot add the option to allow monitoring Resource Usage
which is why we are doing this manually.
125. Click the Discover button at the bottom of the page. Click OK to any popups that
appear.
126. Click Submit at the bottom right of the page.
127. Click the Activate Button at the top right of the page.
128. At the main Devices page you will see MARS-Perim-RTR.gkl.local as the device
name indicating it was discovered. Youll also notice the new IOS discovery feature
automatically changed the software version.
129. Please uncloud the Device Display for the MARS-Perim-RTR.gkl.local device so
that we can see it in the Hot Spot Graph.
130. Click Activate at the top of the page to make sure all settings are committed to the
appliance.
Note The Perimeter Router has already been configured with the appropriate SNMP
strings and logging commands to allow the MARS to discover/process logs from
the device.
131. Go to the Query/Reports tab.
132. In the Query Type section click Edit.
133. In the drop down for the Result Format, select All Matching Event Raw Messages
and click Apply.
134. You will notice that the only parameter changed is now the Query Type.
135. Click Submit Inline. You should see several results in the database appear, but
nothing from the Perimeter Router yet.
136. To generate some events in MARS, go to the Access-PC and expand the link for the
Perim-Rtr.
137. Click on the Hyperterminal link. When password prompted, remember the password
is the POD password supplied by your instructor on the first day of class.
138. Log in to privileged mode using the password san-fran.
139. Gain access to the global configuration mode by typing configure terminal.
140. Type end. What this is doing is creating a syslog message and forwarding it to the
MARS. This will confirm that our device is communicating properly through the ASA.
The message being sent is the same one you are seeing on the console.
Apr 27 22:46:41.137: %SYS-5-CONFIG_I: Configured from console by console
141. Go back to the MARS and run the same Query again to report all Raw Messages in the
past 10 minutes. You should see an event with the same RAW data as you saw on the
console of the Perimeter Router.
LAB Complete
L4
Lab 4: Generating Summary
Reports
Lab 4 Generating Summary Reports
Lab Overview
In this lab we will start getting more familiar with the GUI and creating generic summary
reports. We will take a look at how Netflow is used on the MARS appliance for anomaly
detection. We will walk you through the configuration of Netflow on your Cisco IOS
Routers. There are a lot of graphs available on the MARS, in this lab we will walk
through the various graphs and provide a detailed explanation of each.
30 minutes
Lab Procedures
1. Investigating Netflow
2. Understanding other Summary Reports
3. Understanding the Network Summary
Investigating Netflow
Netflow is a Cisco proprietary feature that allows us to graphically see not only how much
bandwidth is being consumed on a particular interface of a Layer 3 Switch or Router but also the
source, destination and application a particular host is using for a connection. We cannot say this
enough that if you are looking to see who or what is using your bandwidth on your Internet pipe
then you MUST have Netflow enabled in your network. There are two main components to the
Netflow architecture. The first is enabling Netflow in the IOS Layer 3 device and the other is the
Netflow Collector software. MARS will act as that collector.
Note There is a recommended Netflow collector we like to use in production which is
free for monitoring up to two ports (2 Internet feeds). That software is located at
Adventnet.com and can be demonstrated in class.
Note In the MARS appliance, Netflow can start being collected immediately but
MARS will not act on the data until at least 7 days have passed. After that time
anomalies will be processed.
1. Log into the Access-PC and open Internet Explorer if not already done so. You may need
to log into the displayed remotelabs.com webpage if your session has timed out. Use the
credentials provided to you on the first day of class.
2. Expand the Perim-Rtr link.
3. Click the Hyperterminal link and login with the credentials provided on the first day of
class for your POD. Press Enter twice.
4. Go into global configuration mode and enter the following commands to turn on Netflow.
ip flow-export version 5
ip flow-export destination 200.200.1.100 2055
interface fastethernet 0/0
ip route-cache flow
end
write mem
Note The IP address 200.200.1.100 is statically mapped in the ASA to the MARS
5. Type show ip flow export. The output should be similar to the following where there is
no current traffic flowing through routers interface.

Flow export v5 is enabled for main cache
Export source and destination details :
VRF ID : Default
Destination(1) 200.200.1.100 (2055)
Version 5 flow records
0 flows exported in 0 udp datagrams
0 flows failed due to lack of export packet
0 export packets were sent up to process level
0 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup failures
6. Look at your topology diagram for the course. Notice the DMZ has an IPS between the
DMZ servers and the ASA Firewall. We will need to prepare the IPS to allow traffic to
pass on its interfaces before proceeding. Go to the Access-PC and on the desktop is a
folder named MARS. In that folder is a file named MARS-IPS-Base-Config.txt and
contains our initial configuration settings. Open the text file and click Edit > Select All,
Edit > Copy
Note Please read steps 7 through 11before proceeding to circumvent any errors that
may appear (such as not being in the correct mode when pasting to the IPS).
7. On the Access-PC, expand the IPS-Sensor link on the webpage of the lab.
8. Click on the Hyperterminal link to provide command line access to the IPS.
9. The password you should be prompted for is your POD password that your instructor
provided the first day of the class. Enter the password and press the enter key twice.
10. You should now be at the command prompt. Enter global configuration mode by entering
the configure terminal command.
Note If you are prompted for IPS login credentials, use the username cisco and
password ccspattack.
11. Go back to the console of the IPS. Click the Edit option in the Hyperterminal window
and select Paste to Host. Allow the file to be copied to the IPS and then continue with
the next steps. Note that there is no need to save the IPS configuration since the IPS
automatically saves the configuration. Wait until the IPS is done being configured before
proceeding.
12. Go to the Outside-PC and web to http://www.gkl.com
13. Revisit the Perim-Rtr and reissue the show ip flow export command to see that flows
are now being generated and exported to MARS.
Flow export v5 is enabled for main cache
Export source and destination details :
VRF ID : Default
Destination(1) 200.200.1.100 (2055)
Version 5 flow records
2 flows exported in 2 udp datagrams
0 flows failed due to lack of export packet
0 export packets were sent up to process level
0 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup failures
14. On the Access-PC expand the link next to the Site1-Rtr.
15. Click the Hyperterminal link and login with your PODs credentials provided by your
instructor. If necessary, gain access to privilege mode using the secret password san-
fran.
16. Issue the following commands in global configuration mode:
ip flow-export version 5
ip flow-export destination 10.10.2.100 2055
interface fastethernet 0/0
ip route-cache flow
end
write mem
17. Go to the Site1-PC and open Internet Explorer and browse to http://data-srv to generate
some traffic. Return to the Site1-Rtr and issue the show ip flow export command to
verify flows are being sent.
18. Go back to the MARS Appliance and go to the Summary tab.
19. Scroll down the page until you reach the graph Activity: All Events and Netflow - Top
Destination Ports, last 0d-1h:00m
20. Click the Legend button to display a small legend below the graph listing port numbers.
21. Choose Peak View in the list of views.
22. Select Hour in the time interval drop down.
23. You should see HTTP traffic on Port 80. There may be other traffic seen on the interface
as time has elapsed including port 123, 137, 138 and 53 traffic. This is normal since the
Outside-PC and the Site1-PC are trying to contact the Internet for updates.
24. Lets try to generate some more traffic by doing a file transfer using FTP. Go to the
Outside-PC.
25. Open Firefox from the desktop and browse to the url ftp://www.gkl.com. Remember this
is the DNS name of the DMZ Server.
26. Click the 50Meg.bin file. Save the file to the desktop when prompted. Since we have an
Ethernet connection, the transfer will take a very short amount of time. Close the
window when finished.
27. Go back to the MARS Dashboard and in the top left corner is a page refresh rate interval.
Please select the 1 minute update interval.
28. Scroll down and view the Netflow Top Destinations graph again on the bottom left of the
page. You should see that FTP traffic is now being seen as indicated by the following
graph.

Note To read the charts most efficiently, note that it is solely the thickness of a
particular color that determines its value at that point - and that a spike (or drop)
in any particular color could be caused by a spike (or drop) of a different color
lower down in the stack.
29. Click the View Report button in the graph to generate the report against the current
database. Remember that a Report is different from a Query where a Report can be run
many times and saved to your favorite reports section. A Query is a one-time request to
the database.
30. You will notice the Report automatically fills in the fields that are being queried in the
database. The status section indicates whether the Report is still in progress or finished.
31. Scroll down in the Report Results and you will see detailed information regarding the
ports seen in Netflow. The feeling you should be left with at this point is a Summary
Report only shows top level information and is not very detailed. If you want to see who
is using these application ports, we will create our own detailed reports. The data is in the
database, you just need to know how to extract it.
Understanding other Summary Reports
There are six graphs on the Summary > Dashboard page. The following chart indicates a
description of each graph.
Chart Name Description
HotSpot Graph Show all current Layer 3 devices in your network
Attack Diagram Shows any devices compromised or under attack.
The colors of the hosts have different
representations.
Events and NetFlow , last 1d-0h Total number of events generated and Netflow
packets received.
Events and Sessions, last 1d-0h Total number of events generated and determined
sessions.
Activity: All Events and Netflow - Top
Destination Ports, last 0d-1h:00m
Total number of destination application ports used.
This is a good indicator of traffic patterns through
the network.
False Positive Events, last 1d-0h Shows any type of false positive, either system
confirmed or user confirmed.
32. Go to the Attack Diagram and click the Large Graph button.
You should see an attack listed with a graph indicating the Event (Event ID) that fired and a few
lines with arrows. These indicate the flow of traffic in the attack. Below is an example
Note Event IDs are automatically associated with raw messages when they are
received on MARS. You can double-click any of the Event IDs to see the details
of the event. (The IDs here are E-1061, E-1566, E-1568, and E-1569) Double
clicking E-1568 produced the following output:
33. You will also see a red number above the lines. This number indicates the number of
sessions that match the event. You can double-click the line to get a list of these sessions.
Double clicking the 5 in the window above produced the following:
34. Close the popup and click the help button on the large graph. You will see a legend
appear at the bottom of the graph indicating some of the actions you can take on the
graph.
35. Click the Dashboard button.
36. Under the Events and Netflow chart press the Legend button. You should see a
summary of events generated by Netflow as well as non-Netflow related events.
37. To the right of that graph is the Events and Sessions graph. This chart is indicating a
summary of events received and the number of sessions determined by MARS.
38. The last graph on the bottom right is an indicator of False Positives. These can either be
system determined or user defined. You can also see Dropped Events listed indicating the
events that will not be processed once it is determined to be a false positive. Currently we
should have no False Positives since we have not tuned anything yet.
Understanding the Network Summary
There are six graphs on the Summary > Network Status page. The following chart indicates a
description of each graph.
Chart Name Description
Incidents, last 1d-0h Summary of latest Incidents. 30 minute interval
over a 24 hour period.
Activity: All - Top Rules Fired, last 1d-0h Show the Rules that have fired the most in a 24
hour period.
Activity: All - Top Event Types, last 1d-0h Top Events that have occurred in the past 24 hours.
Activity: All - Top Reporting Devices, last 1d-0h This graph will list the network devices that have
reported the most events.
Activity: All - Top Sources, last 1d-0h The graph displays the top source ip addresses in
the network based on sessions.
Activity: All - Top Destinations, last 1d-0h The graph displays the top destination ip addresses
in the network based on sessions.
39. In the Incidents, last 1d-0h graph, click the Legend button. You will notice a summary
of incidents created based on severity.
40. Click the Large Chart button.
41. Notice the traffic pattern shown. It is indicating that an event is occurring on a regular
interval. This is the Kiwi Cattools program administratively shutting down and no
shutting the Ethernet interface on the supplement switch every 5 minutes. Well dig in the
incidents further to tell.
42. Click Summary > Network Status and go to the Activity: All - Top Rules Fired, last
1d-0h graph. Click the Legend button.
43. In the Legend of the graph it will show the rules that have fired the events and should
resemble the following.
44. Notice the next to the rule description. This icon indicates a Query can be run against
the database if you want to see the detailed data. Go ahead and press the icon next to the
System Rule:Inactive CS-MARS Reporting Device.
45. Once the Query page opens, scroll down and choose Reporting Device Ranking from the
Result Format drop-down and choose a duration of 1 day.
46. Click the Apply button.
47. Click the Submit Inline button.
48. The Query Results area should list all the devices that have generated the events which
caused the rule to fire. The ranking is from the top most generated events. Note that the
MARS box itself is the device generating the events.
49. Go back to Summary > Network Status > Activity: All - Top Rules Fired, last 1d-0h
graph.
50. Click the View Report button. The following report criteria should be displayed.
51. Scroll down the list until you get to the actual report results. These results display the
total number of incidents generated by this particular rule
52. Click on the text that states System Rule: Inactive CS-MARS Reporting Device. Do
not click the icon. The two links are very different.
53. You should now be brought to the Rules page displaying the rule that has fired from our
previous report.
Note Note As you recall from class, Raw messages come into the MARS as syslog
data. Each message constitutes and Event. The events are Sessionized
(correlation made between other events). The sessionized data is run through
the Rules list. If any rules match, an incident is created. One or more events can
make up an Incident. All of this information can be Queried.
LAB Complete
L5
Lab 5: Exploring Rules
Lab 5 Exploring Rules
Lab Overview
In this lab we will investigate and create user defined inspection rules and Drop Rules
(for false positive tuning). We will define a particular set of data (source ip, destination
ip, ports, syslog message keyword, etc) for each kind of rule.
When creating a drop rule there is always a choice of completely dropping the data or
allowing it to log to the database only. Both options prohibit the data from being used to
trigger incidents. The Log to DB Only option is chosen if future forensic analysis of the
event is desirable. In addition, there are two ways to create a drop rule. One is to
manually create the rule from scratch and specify all of the parameters necessary to drop
unwanted events. The other is to use False Positive tuning based on events that have
already been received. For you as an administrator, it is important to understand both.
This lab will walk you through the manual method, while lab 9 will focus on using False
Positive Tuning of received events/incidents to Create Drop Rules.
45 minutes
Lab Procedures
1. Creating Inspection Rules
2. Creating Drop Rules Manually
Creating Inspection Rules
In the MARS appliance, incidents are triggered based on rules. There are currently 137 rules
pre-canned from Cisco as of version 4.3.4 software code. We will explore some of these default
system rules and create our own user defined rules to trigger incidents.
1. On the Admin-PC, open the web interface to the MARS appliance.
2. Go to the Rules tab.
3. Notice the Rules listed. These 140 rules are grouped together and can be easily sorted
using the drop down list. Lets create our own user defined rule to generate an incident
whenever someone logs in on VPN. Later we can tune this rule to automatically send an
email notification when the rule triggers. Click the Add button.
As of version 6.0 code you can delete rules. However, you can only delete
rules you define and not system defined rules.
4. In the Rule Name box, enter VPN User Login.
5. In the Rule Description, enter This rule will trigger an incident whenever someone logs in
on VPN. Click the Next button
6. For the Source IP, select Any from the right of the screen and click the Add button in the
center of the screen to move the selection to the selected field on the left of the
screen and click Next.
7. Repeat the previous step for the destination IP address and Service.
8. Next is the Event Type. To the right of the drop down box is a search box. We will search
through the current events to determine if there is an Event in the database we can use. In
the search box enter the word VPN and click Search.
9. The following should be displayed:
10. Click on the Info/SuccessfulLogin/SSLVPN phrase to see a popup with the Event
Description. In the popup you will also notice the various Events that are grouped under
this heading. Close the popup after reading.
11. Select the Info/SuccessfulLogin/SSLVPN option and add it to our selection list be
clicking the button and click Next.
12. Next is the Reporting Device, select the drop down on the right of the screen which
currently lists All Variables and select All Reporting Devices.
13. Check the box for the MARS-Primary-ASA.gkl.local and click the Add button in the
center of the screen to move the selection to the selected field on the left of the
screen and click Next.
14. Click Next for the Reported User option.
15. In version 6.x you can now configure the Risk Rating and Threat Rating for a particular
rule. What this does is allow you to define thresholds that must be met for events being
reported from your IPS in order to trigger this rule. Leave the default values and press the
Next button.
16. Click Next for the Keyword option.
17. For the Severity, select Green to indicate its a Low Severity and enter 1 for the count.
This means the rule will fire when only one instance of the rule triggers. Click Next.
18. When prompted if we are done creating our rule, click Yes.
19. Click Next for the Action and Time range. Remember that the Time range is related to
the count parameter. If the Count is reached within the time interval defined, the rule is
triggered. At the end of the wizard, click Submit.
20. Lets review our rule by selecting User Rules in the Grouping drop down box. You
should see you newly created rule listed. Dont forget to click the Activate button since it
should now be Red.
Note The purpose of this lab is to exemplify the creation of a MARS rule. In
subsequent labs you will be testing these rules as well as creating notification
actions.
Creating Drop Rules Manually
Drop rules allow false positive tuning on a MARS. They allow you to refine the inspected event
stream by specifying events and streams to be ignored and whether those data should be stored
in the database or discarded entirely. Drop rules are applied to events as they come in from a
reporting device, after they have been parsed and before they have been sessionized. Events that
match active drop rules are not used to construct incidents. Because the Global Controller does
not receive events from reporting devices, rather it receives them from Local Controllers, you
cannot define drop rules for the Global Controller. Also bear in mind that the drop rule will not
affect our existing data in the MARS and our incidents will not be removed once the rule is
created.
21. On the Summary tab of MARS, notice the past five incidents that have been generated.
22. One or many of the shown incidents should be related to System Rule: State Change:
Network Device, with several events that have triggered for the incident.
23. Click the Incident ID under the incident section for one of these incidents.
24. Scroll down past the rules section and notice the individual events that have triggered this
incident.
25. On the lines provided write the name of each event that caused the incident to trigger.
There should be approximately 3 events that have caused the incident. An example is the
IOS Interface hardware changed state event.
Event Name:________________________________________________________
Event Name:________________________________________________________
Event Name:________________________________________________________
26. Go to the Rules tab.
27. Click on the Drop Rules subtab.
Note For releases 4.2.3 and earlier of MARS, you cannot define drop rules for a
NetFlow-based event. For these releases, tuning of NetFlow events must be
performed on the reporting device
28. Click the Add button to create a new rule.
29. In the Rule Name field, enter Drop False Positive Interface Resets on Supplement
Switch
30. In the Description Field, enter This rule will drop events related to the Supplement
Switch interface flaps
31. Click the Next button.
32. For the Source IP, Destination IP and Service Type, Select the ANY keyword, choose to
add it and click Next. You will need to select ALL in the drop down box to the top
right of the screen in order to select the ANY keyword.
33. For the Event Type selection, click the drop down box and select All Event Types.
34. To the right of the drop down will be a search field. We want to search for each of the
events you wrote down in step 23, one at a time. Enter the first Entry such as IOS
Interface hardware changed state and click the search button. The results of the search
should return the exact event we are looking for.
35. Select the Event you searched for and click the button to add it to the selection list
on the left of the screen.
36. Repeat steps 32 and 33 for the remaining Events you have listed in step 23 of this lab.
When you are done, the results should look like the following output.
37. Click the Next button to proceed.
38. For the Devices, select the Device Type: Cisco Switch-IOS 12.2. The MARS-
Supplement-Sw should now appear in the list of available devices. Select the switch and
click the Add button.
40. The option for choosing the severity should be the next selection criteria. From the drop
down box, select Any and click the Next button.
41. The action is going to be important if you need to perform forensics analysis later. If we
choose the drop option, we will never be able to run a query/report on any of the data in
the future since we will not retain any of the data. The other option is to drop the data
from matching any rules so that it will not create an incident, yet still log the data for
forensic analysis. Obviously its a resource question versus forensics. Select the option to
Drop the matching events and click the Next button.
42. For the Time Range, select ANY and click the Next button.
43. At the main Drop Rule page you should see the following:
44. Click the Submit then Activate buttons.
Note Note The interface on the Supplement switch is still flapping. Even though this
is occurring, the raw events received on MARS are now being matched against
your Drop Rule and will not create any new incidents.
LAB Complete
L6
Lab 6: Creating Queries and
Reports
Lab 6 Creating Queries and Reports
Lab Overview
Up to this point you have been configuring the MARS and getting familiar with the GUI
and where everything is. In this lab we assume your MARS is fully functional. We will
be running Queries against the database, similar to what we have been doing all along.
We will now save those Queries as Reports to be recalled for later use. We will be using
some reports that Cisco has predefined for you, some of which are very useful for
auditors and SOX compliance. We will also explore a few new commands available in
IOS to have every global configuration command executed sent to the MARS where we
will run a Query on the data to see who typed what and at what time. At this point you
will need to think in terms of your own network environment and decide what predefined
reports you can use. If you need a report that is not included in the canned reports from
cisco, we will walk through how to create them.
45 minutes
Lab Procedures
1. Using Queries
2. Newer Logging Commands and Reports
3. Saving your Query as a Report
Using Queries
2. Log into the remotelabs.com web page and select the ASA.
3. Click the Hyperterminal link to gain console access to the ASA.
4. If prompted for credentials, use your password provided by your instructor on the first
day of class and press Enter twice.
5. We need to get the syslog data from the ASA to the MARS. Enter the following
commands in global configuration mode. These commands start sending debug level
syslog messages to the MARS appliance.
MARS-Primary-ASA(config)#Logging host inside 10.10.2.100
MARS-Primary-ASA(config)#Logging trap 7
MARS-Primary-ASA(config)#Logging on
MARS-Primary-ASA(config)#End
MARS-Primary-ASA#Wr
6. On the Admin-PC, web into the MARS appliance and login.
7. Go to the Queries/Reports tab.
8. Under the Load Report as On-Demand Query with Filter you will see two drop down
boxes. In the second box select the predefined report called Configuration Changes:
Network All Events (Total View). This is one of many predefined queries available on
the system. You will want to scroll through the list and look at the results of the various
queries until you find the ones that match the criteria you are looking for. If none of these
meet your needs, you can easily create your own query in the form provided and save as a
report for later use.
9. Next to the Query Type: Custom Columns ranked by Time, 0d-1h:00m, click the
Edit button.
10. In the Result Format section pull down and choose Event Type Ranking.
11. In the Filter By Time section, select the Last 3 days. This will show us any configuration
changes that have occurred in the past 3 days from any device.
13. Click the Submit Inline button back at the Queries page to view the results. The results
should display some configurations that have taken place on the firewall within the past 3
days. There should be some output after submitting the query. To generate more traffic
go to the Access-PC and log into the ASA. Enter the command no logging message
111111 in global configuration mode. This is just a random value and used to just
generate some syslog traffic. Enter the following commands in global configuration mode
of the ASA.
MARS-Primary-ASA#config t
MARS-Primary-ASA(config)#no logging message 999999
14. Refresh the Query by clicking submit. The output should similar to the following:
15. In the output above, notice the session count. Go back to the console of the ASA and
enter the following commands in global configuration mode.
MARS-Primary-ASA#config t
MARS-Primary-ASA(config)#no logging message 100000
16. The command issued will cause a new syslog message to be sent to the MARS. Refresh
the Query once more and notice the session count. It should increment. That single query
is a good method of determining accountability for commands entered into network
devices. Lets explore some more canned queries.
17. On the Queries page under the Load Report as On-Demand Query with Filter, please
select Activity: All Nat Connections (Total View) in the lower drop down.
19. You will see the results indicating the Nat translations for the past hour. Again, this is a
good report for determining what IP a host had at a particular time and date. Remember
that you can always drill down into each field be clicking the icon next to any of the
indicated fields.
Newer Logging Commands and Reports
20. We want to show you a few new logging commands available starting in IOS code
version 12.3(4)T. These commands will help you to report commands entered in your
IOS devices back to MARS without AAA. A lot of clients we have are looking for the
audit trail that the auditors are requiring on their devices. The ability to see any command
typed, including passwords (can block the viewing of passwords with the hidekeys
command) is a great tool and one worth mentioning. Enter the following command in the
Site1-Rtr under global configuration mode.
Site1-Rtr(config)# archive
Site1-Rtr(config-archive)# log config
Site1-Rtr(config-archive-log-cfg)# logging enable
Site1-Rtr(config-archive-log-cfg)# logging size 1000
Site1-Rtr(config-archive-log-cfg)# hidekeys
Site1-Rtr(config-archive-log-cfg)# notify syslog
Site1-Rtr(config-archive-log-cfg)# do wr
Site1-Rtr(config-archive-log-cfg)# end
21. On the command line of the Site1-Rtr generate some audit trail traffic by going to an
interface on the router and entering in a new description.
Site1-Rtr# config t
Site1-Rtr(config)# interface fast0/1
Site1-Rtr(config-if)# description *** This is a test description ***
22. You should now see a message scroll across the screen with the following output.
23. On the Site1-Rtr enter the following commands:
Site1-Rtr(config-if)# exit
Site1-Rtr(config)# username iosadmin password iospass
Site1-Rtr(config)# end
24. You should now see a message scroll across the screen with the following output
25. On the Site1-Rtr type the command show archive log config all to see what gets sent to
the MARS appliance
26. Go back to the Admin-PC and log back into the MARS to see if the message was
received correctly. Click on the Query/Report tab.
27. Next to the Query Type: Event Types ranked by Sessions, 0h:10m, click the Edit
button.
28. In the Result Format drop down box, select All Matching Event Raw Message.
29. In the Filter By Time section, select Last 1 Hrs.
31. At this point the MARS is receiving a lot of traffic from all the different devices
configured. We should start being selective on the devices when running Queries. Go to
the Devices column and click the Any keyword.
32. Remove the Any keyword from the selection box on the left by selecting the word Any
and clicking the Remove button in the center of the screen.
33. In the device selection drop down box to the right of the screen, select Device Type:
Cisco IOS 12.4.
34. In the selection box on the right of the screen select the MARS-Site1-Rtr and add it to
the selection box on the left by selecting the button in the center of the screen.
35. Click the Apply button. The output should be as follows back at the main Query page.
36. Click the Submit Inline button. There should be several lines of output from the router,
two of which should be the same raw message we saw on the command line in steps 22
and 24.
37. There is also another option available for the Filter by Time option. It allows an
automatic refresh to occur for the query every 3 seconds. Explore this option by clicking
the Edit button again next to the Query type:
38. In the Filter By Time: section select the Real Time: option for Raw Events.
40. Notice that the Save As Report and Save as Rule button are grayed out and cannot be
selected for a Real Time query. Click the Submit button.
41. To the bottom right of the screen is an option to have the screen displayed fast or slow.
Select an option you feel comfortable with. To generate some traffic, go to the Access-
PC and log into the Site1-Rtr. Entering into the FastEthernet interface will generate a
syslog event from the archive command.
Site1-Rtr# config t
Site1-Rtr(config)# interface fastethernet0/1
Note All commands entered while in global configuration mode or any mode
past global configuration such as the interface mode will be logged and
sent to the MARS.
42. Go back to the MARS and view the Real Time Query. You should see a log message
being received indicating that someone has gone into interface mode on the Site1-Rtr.
Saving Your Query as a Report
43. In your network environment you will find several queries being run constantly against
the MARS database. At some point going through the previous steps may be a tedious
task. Its now time to save the query as a Report so that it can be run over and over again
without having us reconfigure the query properties. We will use our previous query we
just created, next to the Query Type: Event Raw Messages ranked by Time, Real
Time (raw events), click the Edit button.
44. In the Filter By Time section, select Last 1 hour and click the Apply button.
45. Click the Submit Inline button on the main Query page.
46. Click the Save as Report button.
47. In the Report Name, enter Site1 Router- Config Command Tracking
48. In the Description field, enter
Created by Your Name on Date.
50. The next option is asking us how often this Report should run. For the Schedule, run On
Demand-Only.
51. Scroll down the page. You will see that there are several different views available for the
Display Format. Read through the various descriptions and choose the default Total
View for our report. Click the Next button after reading through the descriptions.
52. We have not created any users yet, so the default user groups are displayed on the
following Recipients page. In the labs that follow we will be adding users in the MARS
as valid recipients and have the reports emailed to these users. Click the Next button.
54. The final page of the wizard displays the Report we have generated. Verify the fields are
correct for the data we want to analyze.
55. Click the Submit then Activate then Close buttons.
56. You will be brought to the Report sub tab with your new report displayed at the top of
the page. We will get familiar with this sub tab and most available options.
57. In the Group drop down, you will notice all the options that were available to us on the
Query page. To easily parse through these reports to get to the user defined reports, select
User Reports. Only our report just created should be seen.
58. Notice to the right of page you will see a Group button. This is a nice feature to logically
group our reports together. Click the Add Group button.
59. In the Group Name field, enter GK Grouping.
60. Select User Reports in the drop down box for report criteria .
61. Select the Remote Site Router report and click the Add button.
62. Click the Submit then Activate then Close buttons.
63. You can now select the GK Grouping group from the drop down reports option to the left
of the Reports page. Your report should be listed after you select the group. Select your
report and then click the Resubmit button to see the report run.
64. Notice the Status column indicates the report is In Progress . After a few moments
refresh the webpage and the status should be changed to Finished. Select the report
and click the View Report button.
65. The following is worth mentioning since there is a resource limit to some extent with
reports as indicated in the following table
Maximum Database
Retention Limits for Report
Results
Cisco Security MARS
Model
Maximum Number of Stored
Reports
Database Purge
Interval2
CS-MARS-20-K9 1,000 ranking reports5,000 event/session
reports
3 months
reports
3 months
reports
6 months
CS-MARS-100E-K9 1,000 ranking reports5,000 event/session
reports
6 months
reports
6 months
CS-MARS-GC-K9 1,000 ranking reports5,000 event/session
reports
12 months
CS-MARS-GCM-K9 1,000 ranking reports5,000 event/session
reports
12 months
66. Notice there is a sub tab under the Query/Reports section called Batch Query. You can
not choose to run a batch query manually, a batch query is an option chosen for you.
When you run a query there are a lot of parameters we can choose as query objects as
youve noticed so far. In a production environment you will have a fairly large amount of
information in your MARS database which means a lot of overhead when querying the
database. The MARS takes the size of the current database into consideration when
running a query. If the parameters chosen are granular and the database is large enough,
the MARS will provide a Submit Batch button instead of a Submit Inline button on the
Query page. A batch query is just a query that will take a while to run and one that you
will need to come back to in order to view the results. The statuses of these results are
displayed under the Batch Query sub tab where you can select the refresh interval for the
page.
LAB Complete
L7
Lab 7: Case Management and
Rule Actions
Lab 7 Case Management and Rule Actions
Lab Overview
Its now time to be more proactive and less reactive. We want to be informed when
specific incidents occur in our network. In this lab we will take a rule (remember, rules
create incidents) and configure an action for that rule. In our case we would like to have
an email generated and sent to our admin group. Since most of our students like to see the
complete picture (end-to-end), we have created an environment complete with a SMTP
server so you can see your emails being generated. You will also want to explore the
newer CASE Management feature which allows notes and a trace log associated with one
or many incidents. You will create a case and explore the options available for adding
info to it as well as emailing the case to a user.
45 minutes
Lab Procedures
1. Case Management
2. Creating and Event Action
Case Management
The Case Management feature can capture, combine, and preserve user-selected MARS data
within a specialized report called a case. The following data can be added to a case:
Text annotations
Incident ID page
Incident device information (source IP address, destination IP address, reporting device)
Session Information page
Query Results page
Build Report page
Report Results page
View Case page (the current case can reference another case)
A case preserves and displays the selected data as it appeared when the data was added to the
case, regardless of subsequent changes to the MARS state. For example, MARS data can be
purged, topology can change from automatic discoveries or vulnerability scanning, and overall
configuration can change when you edit rules or reports, but the data reported in the case
remains the same as the time it was captured.
Activity Procedure:
1. On the Admin-PC, web over to the MARS appliance and login (https://10.10.2.100).
2. Click on the Incidents tab and then the Cases sub tab.
3. On the right side of the screen click on the Show Case Bar button . Once
cases are created, this setting will display the Case Bar at the top of each and every page
in MARS. This allows for navigation to your current case from anywhere in MARS. It
also makes it easy to add information to the case from anywhere in MARS. Once
selected, the button toggles to Hide Case Bar, giving you the option to remove the case
bar. The Hide/Show Case Bar option is only available from the Cases Sub tab.
4. Click the New Case button.
5. Select/Enter the following in the case creation fields:
Severity: Green
Type: New
Owner: Administrator
Case Name: IPS Signature Update Failure
Case Descr: This case was created to provide notes and documentation on why the IPS
signatures are not downloading.
6. Click the Create New Case button.
7. Back at the main Case page, you should see your newly created case with an assigned
case ID number. You cannot change the case ID as it is system assigned.
8. Click the Case ID.
9. You should now see the case history listed at the bottom of the page. We now need to add
some incidents to the case to be managed by our administrators. Click the Incidents tab.
10. In the Recent Incidents for last drop down, select 1 month.
11. Select System Rule: CS-MARS IPS Signature Update Failure in the rules drop down
box. You will see no results displayed currently. Go to the Admin tab and select IPS
Signature Dynamic Update Settings. Press the Update Now button to force MARS to
pull the latest signatures from CCO. Press the OK button in the popup box that appears.
Note In version 6.x code, the default polling interval for dynamic signatures from
CCO is set to NEVER.
12. Go back to the Incidents tab. You should now see an Incident for the selected Rule as
indicated below.
13. Select the incident listed and click the View button.
14. The top of the page should list the current case as being selected.
15. Click the Add This Incident button.
Note You would need to add each incident individually to this new case. There is no
current method for adding multiple incidents to a case simultaneously.
16. Click on the Cases tab.
17. Click the Case ID for the case you created to edit the contents of the case.
18. At the bottom of the page notice the history of the case. You should see an entry
indicating your incident was successfully added to the case.
19. Click the View Case Document button at the bottom of the page. Details including the
Rule associated with the incident are listed.
20. Click the Email Case button at the bottom of the page. A popup window should appear.
21. Select All Users from the drop down box. Notice that the PNADMIN user is the only
user currently in the system. We currently do not have an email address associated with
our user so we are going to create one here. Select the PNADMIN user and click the edit
button at the bottom of the page.
22. In the Email address field, enter admin@gkl.com and click the Submit button. Ignore
the password fields, you do not need to fill in those fields.
Note In version 6.x Cisco included CSM credentials at the bottom of the user page.
When CSM performs deployments it will use the user credentials supplied here.
23. When you return back to the recipients window, select the PNADMIN user and click the
button. Click the Submit button at the bottom of the page.
24. Go to the Admin-PC to check your email. From the quick launch bar click the icon for
Outlook Express . You may need to hit the Send and Receive button to force an
update of the email system.
25. An email should appear in your inbox sent from the MARS appliance. Open the email to
review its contents. Youll notice that the contents are pretty much a screen shot of the
Incident and Case History with active links to MARS. The email contains basic incident
information but to really see the details, one would have to log into the MARS and of
course would therefore require an account on MARS.
26. Go back to the Admin-PC and to the MARS and select the Summary Tab. Notice that
any cases currently assigned to you will show up in the To-do List section of the
dashboard page.
27. Click on the Incidents > Cases tab.
28. You should still show the current case as selected at the top of the page. To the right of
screen click the More button.
29. In the field provided, enter Note1 and click the submit button.
30. Select the case ID link and scroll down to the bottom of the page and you
will see the newly created comment in the Case History section.
Note At this time there is no current method to delete a case once it has been created.
31. Click the more button at the top right of the page again as you did in the previous step.
Click the Deselect Case button. This allows you select another case to
work on. We dont currently have any other cases, so simply pull down in the Select
Case field and choose the case we have been working with.
32. Click the more button and select the Drop Down list that currently displays New and
select Closed to signal other engineers we have successfully closed the case.
33. Then click submit
Note Once a case has been closed it can no longer be chosen as a current case. In
essence, no further modification of the case is allowed.
Creating an Event Action
At some point you will want the MARS to email you when a rule triggers. A MARS alert action
is a signal transmitted to people or devices as notification that a MARS rule has fired, and that
an incident has been logged. Alert actions can only be configured through the Action parameter
of a rule. An alert action determines which alert notification types are sent to which MARS user
accounts or user groups. MARS can transmit alerts by the following methods:
Alerts sent to users: (User must exist in the MARS DB with email SMS or Pager info)
Email via SMTP
SMS Small Message Service (Text Messaging) via SMTP
Pager via Telephone
XML via SMTP (for third party applications/trouble ticket systems)
Alerts sent to Devices:
SNMP Trap
Syslog
DTM Distributed Threat Mitigation to IOS IPS devices
34. Click the Incidents tab.
35. In the Recent Incidents for last drop down, select 1 month.
36. Select System Rule: CS-MARS IPS Signature Update Failure in the rules drop down
box. The results should indicate several incidents over the past month that match this
rule.
37. Click the Matched Rule Name System Rule: CS-MARS IPS Signature Update Failure.
38. The Rules page should appear. The first rule in the list is the one we want to set an action
on. Click the None link located to the right of Action.
Click the Add button.
39. In the Name field, enter Email the Admin.
40. Check the Email checkbox.
41. Click the Change Recipient button in the Email section.
42. In the popup box select the Admin Group and click the button. Doing this will
send an email to every user in the Admin group.
45. Select the Email the Admin option on the right pane and click the button to move
the selection to the left pane.
47. Click the Submit and Activate and Close buttons.
Note You have successfully completed the creation of an event action. Every time
this rule creates and incident, all members of the Admin Group will receive an
email notification. Also, it is possible to add multiple actions to a rule. For
example another action could be created that would simultaneously send an
XML message to a third party trouble ticket system for automated entry to a
database.
48. Lets test the event action. Click on the Admin tab in MARS and click on the IPS
Signature Dynamic Update Settings link.
49. Click the Update Now button. After a short wait you should receive the following
message.
50. Click the OK Button.
51. Open the E-Mail icon on the desktop of the Admin-PC again to view the email. Review
the email. If no new email is present, press the Send/Recv button on the toolbar. Notice
the email displays information that an incident was created including date and time as
well as the rule which fired the incident and the incident ID. The email also provides you
with links to MARS. There is no other information in these emails. The benefit is to let
someone know that the incident occurred. Further investigation must be carried out by
logging onto the MARS. When done with the email, please close the message and exit
from outlook express.
LAB Complete
L8
Lab 8: Incident Handling and
Mitigation
Lab 8 Incident Handling and Mitigation
Lab Overview
In this lab we will be creating and investigating incidents. In a production environment,
some incidents will be attacks coming into the network, while others will be incidents
that could be caused by misconfiguration of network equipment such as duplex or speed
issues. We will be launching an attack in this lab against our perimeter firewall to create
an incident as a proof of concept. We will show you how to investigate the incident and
in a follow-up lab, show you techniques to tune the appliance in case the incident
happens to be a false positive.
15 minutes
Lab Procedures
1. Create and Incident
2. Incident Mitigation
Create an Incident
In the past few labs you should have seen several incidents being created. Some of these are
related to not changing the default MARS password or maybe a device that hasnt reported any
log data to the MARS for the past hour. Lets start this lab by attacking our DMZ from the
outside. Remember that by default, there are 140 (in MARS 6.x) preconfigured rules in the
MARS appliance. Once the conditions of these rules are met by events, incidents will be created.
1. Go to the Outside-PC
2. Run the SuperScan4.exe file located on the desktop. This is a free port scanner provided
by Foundstone (now McAfee) and will be used to generate an attack.
3. In the Hostname/IP field enter www.gkl.com and enter 200.200.1.15 in both the Start IP
and End IP fields. Click the big arrow to the right to add the host to the scanned section
as indicated with the example. We are going to port scan the DMZ server to generate
syslog traffic from the ASA indicating the attack.
4. Click the Host and Service Discovery tab at the top of the application and uncheck the
Host Discovery check box. This will allow the scanner to just scan without attempting to
ping the host first.
5. Return back to the Scan tab and press the blue arrow on the bottom of the application to
start the scan. Wait until the scan completes.
6. Go to the MARS and click on the Incidents tab. In the Matched Rule field, make sure
that All Rules is selected.
7. You should see new Incidents being generated. One of them is indicating an Inactive CS-
MARS Reporting Device and the most recent should be an Incident generated describing
a packet being dropped due to a security policy.
8. Notice the Time column indicates a range of time of when the incidents occurred.
9. The incident ID as indicated in our lab I:1111971 is a system assigned number that is
created at the time the incident was created. The numbers displayed in your lab will differ
from our examples.
10. In the Matched Rule section, click the rule called System Rule: Network Errors
Likely Routing Related. This will show us the configured rule that triggered our
incident.
The Count column under the rule indicates a count of 10, which means that this rule will
only fire when there are at least ten occurrences of this event. Notice that some of the
fields are grayed out and cannot be modified. If you scroll down you will see a different
System Rule with more parameters including variables such as $TARGET01 which
indicates the same source in the source packet or destination packet of multiple sessions.
11. Click the Incidents tab to return back to the main Incidents page.
12. Select the radio button next to the incident that fired as a result of our port scan and click
the View button.
13. Scrolling down on this page will show the attack details. As shown below.
14. Lets walk through the various fields so you are comfortable with the output.
Session/Incident ID- Shows the session number associated with the packet.
This could be source/destination ip and ports related.
Event Type- The Events column shows types of the firing events.
Multiple firing events of the same types are shown once
per session.
Source IP/Port- Source ip address of the attack and source port.
Destination IP/Port- Destination ip address of the attack and port.
Protocol- Protocol used in the attack.
Time- Single time or time range of the offending packet.
Reporting Device- This is the device that is reporting the raw message to
MARS.
Path/Mitigate- Various icons to display the attack and all devices in
between as well as mitigation steps.
Tune- This is where you can tune the message to be a false
positive. It will allow us to not fire the incident again for
the same messages in the future.
There are also a few icons to take note of on the page. Ill list them here with a brief description.
-This green icon shows a medium alert severity and cannot be clicked for more details.
- As mentioned before, this icon allows us to query the database for details of the
description next to where this icon is found.
- If you look close enough, this icon shows a few zeros and ones and represents raw
messages. Clicking this icon shows you the messages as it was received in MARS.
- This is a newer icon and a pretty cool one. When a user clicks here, it will query Cisco
Security Manager for the ACL/Policy that the packet matched allowing us a direct
correlation between incidents and configuration of the security devices.
- This icon to the right of the screen is used to view an attack vector graph. It will show
the source of the attack and the destination and all known devices between.
- This icon once clicked, will display the mitigation steps needed to thwart the attacker.
- Shows vector information which includes arrows indicating traffic flow on a graph,
similar to the attack diagram on the Summary page.
15. One of the most useful icons listed above is the raw messages icon . Click the icon in
your incident relating to the raw messages to show you the details of the messages as it
was received on MARS. When you are done viewing the message click Close.
Incident Mitigation
16. Click the icon in the incident we have been investigating so far. A page should be
displayed showing the entire attack path through the network.
17. In the drop down box that currently reads Layer 2 Path, select Full Topology to see your
entire network and attack flow as indicated below.
18. In the popup window on the left of the page is a section indicating the suggested
enforcement point. In our case, its suggested that we stop the attacker on the MARS-
Perim-RTR router. But as you can see the attack is already being stopped at the ASA.
Remember this is just a suggestion the MARS is recommending.
Note Cisco tries to mitigate as close to the source of the attack as possible. Also
remember from discussion in class that there is no such thing as auto
mitigation. MARS will NOT automatically log into the recommended chokepoint
to restrict access. Instead, you will have to manually edit the configuration on a
layer 3 device like a router or layer 3 switch or push a mitigation command from
MARS to a layer 2 switch.
19. Scroll down on the page and notice the mitigation step suggested for this incident. Since
mitigation will happen on a layer 3 device like a router, an ACL will be used. If you look
at the detail of the ACL, you will see that the first suggestion is really not realistic in a
production environment. The second suggestion is more plausible as it simply blocks all
communication coming from the attacker. In our case, the packets that created the
incident were already stopped on the ASA so we do not need to take any further steps.
Once we can go through all the incidents and feel comfortable that the packets have been
mitigated either by MARS or by a different device, we can then tune the incident to be a
false positive where we wont have to be notified again when the event occurs. Also
notice the PUSH button is grayed out on Layer 3 mitigation but will be available for
Layer 2 mitigation.
LAB COMPLETE
L9
Lab 9: Tuning the MARS
Lab 9 Tuning the MARS
Lab Overview
Up to this point we have explored several incidents that we created by generating attacks
from the outside to the firewall. The rest of the incidents created are actually normal
network traffic in our environment. Its time to show you now where most of your time
will be spent in production, tuning the false positives. In this section we will show you
how to tune your networking devices so they dont generate messages you consider a
false positive (Device Side Tuning). It will become apparent how tedious this task can be.
We will then perform false positive tuning on the MARS itself (Appliance Side Tuning).
The result of false positive tuning is that a drop rule will automatically be created to
eliminate unwanted incidents in the future.
15 minutes
Lab Procedures
1. Tuning Network Devices (Device Side Tuning)
2. False Positive Tuning (Appliance Side Tuning)
Tuning Network Devices
When tuning devices care must be taken to insure that you do not break compliance
requirements. Another pitfall of device side tuning is that you need to tune each and every
device reporting to MARS so that messages are never sent. Also from a forensics approach, its
better to have the logs being created and filtered on MARS so at least we can go back and
review any historic events if we need to or if auditors request specific data. For these reasons,
Device Side Tuning is typically not a recommended solution but one that can be done if
necessary.
1. Go to the MARS GUI on the Admin-PC and click on the Incidents tab.
2. In the drop down box select Recent Incidents for last One Week.
3. Notice all the incidents listed. Locate the incident that was triggered by the System Rule:
Network Errors Likely routing Related. Select the incident and click the View button.
4. Read through the description for the firing rule that triggered the incident. This rule may
get annoying to most engineers. It indicates that every packet that is denied by the ACL
on the ASA Firewall generate a syslog message and therefore contribute to incident
generation (as long as the event occurs 10 times within the Time Range indicated).
5. Determine the Reporting Device which is generating the messages. We will go into this
reporting device to turn off the messages from being sent to the MARS in the first place,
preventing these incidents from occurring. To do this, return to the incidents tab and
click the link for the incident itself. In the window that appears locate the reporting
device.
6. Click on the Raw Events icon to see the message being generated from the network
device.
7. A popup should now appear with the raw message displayed. In the message will be a
message ID that we will filter on the reporting device and should be in the form of
%ASA-4-106023. The 4 indicates the severity on the ASA of this alert, this one being a
level 4. The message ID is 106023. Cycle through a few of these raw messages to see that
they all are using the same message ID. After viewing the message, Close it.
9. Log into the remotelabs.com web page and select the ASA.
10. Click the Hyperterminal link to gain console access to the ASA.
11. If prompted for credentials, use your password provided by your instructor on the first
day of class and press Enter twice.
12. Log into global configuration mode and issue the no logging message 106023 command.
Note It is not recommended to disable this message ID in a production
environment. If you do, you will no longer see denies to ACLs in syslogs
messages..
13. Go to the Outside-PC and launch your port scan again on the www.gkl.com host as you
did in the previous lab. Allow the scan to finish.
14. Go back to the MARS GUI and click on the Incidents tab. Wait approximately 1 to 2
minutes. You should not see an incident created related to System Rule: Network Errors
Likely routing Related. You should see however, an incident generated indicating a new
command was issued on the ASA from step 12. The 106023 messages are now tuned,
however if an auditor requests to see the related attack logs, you would not be able to
produce them which is why the next section is the preferred method of tuning.
Note By tuning the messages on the Device you also are cutting down on the
EPS (Events Per Second) the MARS is processing, conserving resources.
False Positive Tuning
The realistic way of handling most unwanted incidents is to tune them on the MARS. That way
we can always return back to the MARS and pull the data for forensics and remain in
compliance. This is where your initial time will be spent on the MARS. Getting this device up
and running really takes a minimal amount of time. Tuning it to meet your needs takes much
more time and is an ongoing task. Keep this in the back of your mind, you will need to spend
time on the appliance every day to see the incidents generated and determine mitigation steps.
This type of device is exactly why organizations that can spare the man power can create whats
known as a Security Operations Center (SOC) where they can monitor incidents from these
types of devices and IPS alerts.
15. Lets go to the MARS (from the Admin-PC) and click on the Incidents tab.
16. In the Recent Incidents for Last select 1 Day.
17. In the list of incidents you should see an incident with an Event Type of Inactive CS-
MARS reporting device. Actually, you should see a lot of these incidents. The nature of
this incident may not be apparent by the rule name System Rule: Inactive CS-MARS
Reporting Device. Drill into one of the incident names to see the rule details by clicking
on System Rule: Inactive CS-MARS Reporting Device.
18. The Inspection Rules page should now appear. At the top of the page are the rule details
we are looking for with a description of the inspection rule.
19. In our network we are choosing to consider these incidents as a false positive. We really
do not need to see messages indicating that a device has not sent log data within the past
hour. You can see that on routers and firewalls, data will be sent all the time depending
on the logging level. But on layer 2 devices that is not the case. Log messages are
generated when major events occur such as interfaces coming up or. The problem is that
every hour in between you will have incidents created.for every switch.
20. Go back to the Incidents tab and choose to have incidents viewed that have occurred in
the past one day to be displayed.
21. Select the latest incident with the rule type System Rule: Inactive CS-MARS Reporting
Device and click View
22. Under the rule should be a table displayed with the details of the incident. To the right of
the screen is a column named Tune. Choose the entry with destination IP of 10.10.2.1
and click on the False Positive Tuning link.
23. A window should popup with a listing of the Event Type which should list the name you
saw on the previous page of Inactive CS-MARS reporting device. There should be a
section listing the Source and Destination ip addresses The list is derived from the
source/destination IPs listed on the previous page (based on the session). Drag the popup
window over to the right to see the page underneath and the IPs listed. Notice that there
are several sessions that make up the incident. Two things are going on here. First, you
are doing false positive tuning based on a specific session of the incident. When you are
done you will see that this session and any other sessions related to it will be marked as
False Positives in MARS. Second, you are simultaneously creating a drop rule which
will affect all future events. The IP address information you are setting here will apply to
the drop rule, not the false positive tuning. Back in the popup window select the ANY as
a Source and 10.10.2.1 as the Destination. Note that the 0.0.0.0 does not represent ANY.
Since the MARS itself is generating these incidents there is really no source of the traffic.
The destination defines the network device itself for this incident. You can always edit
this IP information later in the wizard. Select the checkbox for the Event Type listed and
click the Tune button.
24. The next step in the wizard is to decide whether to drop these Events completely or to log
them to the database but do not create incidents. The advantage to logging to the database
is the forensics in future audits. The disadvantage to logging the events is the resources
being used, specifically the drive space and EPS consumed. Choose to Drop the Events
Completely and click the Next button.
25. The last screen in the wizard displays the Drop rule you have created. Take a look at the
fields to make sure you have a clear understanding of what this rule is doing.
26. Notice that any of the fields can be modified on this screen. Go ahead and click the
Destination IP of 10.10.2.1
27. In the box on the left, select the IP address of 10.10.2.1 and click the button
in the section between the two selection boxes.
28. In the box on the right select the check box next to Any and press the button to
add the variable to the left selection box.
29. Press the Apply button on the bottom of the page.
30. Notice the name of the drop rule contains the date and time the rule was created. Its a
good idea to come up with a policy in your environment on naming conventions. You
may want to include the users name that created the drop rule in the description. Click
the Confirm button once you are satisfied with the description of each field.
31. You should be returned back to the incident details page. Look at the session you
determined was a false positive. Notice that there is now an icon next to the Event Type.
This is indicating a user confirmed False Positive.
32. Click the Activate button on the top right of the screen.
Note What you did is determine that one of the sessions in the incident is a false
positive. That is indicated by the icon now listed next to the Event
Type. If you compare the other sessions in the incident, they are not user
confirmed False Positives even though we chose the keyword ANY in the
source and destination IP fields. Yes that does mean you need to do these
sessions by hand as well. You did however create a drop rule when you
determined this particular session as a false positive. That means future
events matching the drop rule will not create an incident. Since the drop
rule uses the keyword ANY for the destination, you should no longer see
any new incidents created from this event type.
33. There are several other icons you should be made aware of:
Icon Description
Low, medium, and high severity false positives that require confirmation.
Low, medium, and high severity user determined false positives.
Low, medium, and high severity system determined false positives.
34. Click on the Incidents tab and then the False Positives tab.
35. In the Select False Positive: drop down box, select User confirmed false positive type.
The false positive we created now appears. Notice that the destination address is
10.10.2.1. This is due to the session we chose to do false positive tuning on. The drop
rule (which was a result of the tuning) will show a destination of ANY (remember, the
false positive wizard tuned an existing incident and related sessions and also created a
drop rule).
36. Click the Show link under the Related Sessions column. A popup box will appear.
37. Under the Time column there will be a total number of sessions that we covered with our
single tuning. Click the plus sign in the column to expand the details.
Note If an error mesage appears, please just close the popup box. This is a
known bug with Cisco.
38. You should notice that the tuning we did covered the same source destination pair and
event type for multiple incidents as indicated.
39. Close the popup window.
40. Click on the Rules tab and Drop Rules sub tab.
41. You will see two rules in the window. One that we created manually in lab 5, and one
that was created automatically from the user confirmed false positive wizard. Notice that
the automatically created rule has a destination address of ANY per our selection in the
false positive wizard.
Note These rules pertain to any new messages being received on the MARS, not
to any incidents already present in the database.
If youve been around the MARS appliance for a while youll notice a new feature present
which wasnt in prior releases to version 6.0. That is the Delete button in the image above.
You can now delete Drop or Inspection Rules. In prior releases this was not possible.
LAB COMPLETE
L10
Lab 10: Creating a Custom
Parser
Lab 10 Creating a Custom Parser
Lab Overview
At some point you may come across newer devices that are not yet supported in the
MARS appliance yet you want to still have messages from these devices parsed by
MARS. Cisco has integrated a tool called the Custom Parser into the MARS appliance. It
allows us to map certain fields in a syslog message and have them parsed correctly in
MARS. In this lab we will be showing you a tool that you can use in your deployments of
MARS to artificially create syslog messages from a PC to test the MARS parsing. You
could use the same tool to create ASA, IOS, NAC Appliance syslog messages without
actually having to penetrate or fail a device (as in failover on firewalls).
30 minutes
Lab Procedures
1. Generate an Unsupported Message
2. Define the Custom Parser on MARS
Generate an Unsupported Message
In this section, we will generate unsupported message types to be sent to the MARS. In a
production environment it will be likely you will run into to a similar circumstance. A
few common applications not supported on the MARS are apps such as a Barracuda
appliance and an AS400 mainframe which are common in the healthcare field. This lab
will take a generic syslog message from a Barracuda appliance and process it correctly on
the MARS. Since we do not have an actual Barracuda in the lab topology, we will
generate artificial log messages using a handy application called Kiwi Logger (KLOG).
This application is free from http://www.kiwisyslog.com.
1. Go to the MARS GUI on the Admin-PC and click on the Management tab.
2. Beginning in version 6.0 of software code there is a new sub-tab available named Device
Type Management. Clicking on this tab will show you all the devices that are now
supported under MARS. This is a great improvement over older software versions,
allowing us to look up our devices to see if they are supported in MARS or not. Note that
this list is inclusive of Software and Hardware devices as well as versions of code. One
device in particular to note is that the NAC Appliance is now supported making a lot of
Cisco customers very happy. You can see the version of NAC appliance supported by
searching for the term NAC in the search bar under the new tab. Note that there are
currently 2006 devices supported in version 6.0 of MARS. If your device is not listed you
will need to create Custom Parsers as we are doing in this lab.
3. On the Admin-PC, open the Admin-PC link on the desktop which looks like My
Computer.
4. Open the D: drive named MARSv3.0.
5. Scroll down until you find the file named Kiwi_Logger.exe and launch the application to
install.
6. Choose all the default settings to proceed through the installation.
7. The KLOG program is a command line driven utility. Go to the command prompt on the
Admin-PC and change directory to c:\program files\klog\klog command-line
tools\klog.
8. Lets generate our message. Type the following all on one line:
To save you time, we created a text file called Barracuda-Log.txt in the
MARS folder on the desktop of the Access-PC. Feel free to just copy the
contents to the command prompt of the Admin-PC to save time.
klog.exe -h 10.10.2.100 -m "Sep 19 17:07:07 Barracuda httpscan[3365]: 1158710827 1
10.1.1.8 172.27.72.27 text/html 10.1.1.8 http://www.itunes.com/ 2704
3767734cc16059e52447ee498d31f822 ALLOWED CLEAN 2 1 0 1 3 - 1 Spyware 0 - 0
itunes.com Non-Business,Media ANON"
Note As mentioned at the beginning of this lab, this will be very tedious work
and you will need to do this for every syslog message being sent from
your monitored device. Luckily, in our lab we will only be doing this for
one syslog message.
9. The following lists the breakdown for each of the fields and is provided as an example.
The following table describes each element of a syslog message.
Field Name Example Description
Epoch Time 1158710827 Seconds since 1970, unix timestamp.
Src IP 10.1.1.8 IP address of the client.
Dest IP 172.27.72.27 IP address for the page that was blocked by the
Barracuda Web Filter.
Content Type text/html HTTP header designated content type.
Src IP 10.1.1.8 IP address of the client.
Destination
URL
http://www.itunes.com The URL the client tried to visit.
Data Size 2704 The size of the content.
MD5 anchor 3722 The anchor used for parsing. This information is not
usually important.
Action ALLOWED Action performed by the transparent proxy. The type
of actions include:
ALLOWED: Traffic was processed by the
transparent proxy and no virus or spyware was
detected.
BLOCKED: Traffic was blocked by the
transparent proxy most likely because the proxy
detected virus or spyware.
DETECTED: Another process detected
outbound spyware activity.
Reason CLEAN Reason for the action:
CLEAN: Traffic does not contain any virus or
spyware.
VIRUS: Traffic was blocked because it contains a
virus.
SPYWARE: Traffic was blocked because it
contained spyware.
Details
(only for
blocked traffic)
Stream=>Eicar-Test-
Signature FOUND
The name of the virus or spyware that was detected
in the blocked traffic.
10. Press the Enter key to launch the message.
11. Log into the MARS and go to Query/Reports.
12. Click the Edit button in the Query Type Section.
13. For the Result Format, select All Matching Event Raw Messages
14. In the Filter By Time section choose Last 10 Mins.
16. Click the Any word in the Device column.
17. Remove the word Any from the selection box on the left of the screen.
18. Select the Unknown Reporting Device in the list of devices and click .
21. You should now see data appearing resembling the following output.
22. The Raw Message field should resemble the data that you just sent from the command
line of the Admin-PC. Once you see this message then its time to map these fields to
something useful that the MARS can use.
Define the Custom Parser on MARS
23. So we now know that MARS is receiving the raw message. MARS also believes the
message is coming from the Admin-PCs IP address and doesnt know if the PC is an
actual hardware or software device. On the MARS, go to Admin > Custom Setup.
24. Click the User Defined Log Parser Templates link. This takes us to our new Device
Type Management sub-tab.
25. Click the Add button.
26. For the Type option, select Appliance.
27. In the Vendor field, type Barracuda.
28. In the Model field, type WebFilter.
29. In the Version field, type 1.0
30. Click the Submit button. You should now see your device selected at the top of the
Device Event Type page.
Note While the raw message for an event does include the header information,
MARS removes the header prior to sending the payload to the custom parser.
When writing a parser log template, do not include the header fields.
32. In the Device Event ID field, enter Barracuda Blocked Website.
Note The Device Event ID field provides an opportunity to map this message
number or another moniker used by the device to the custom event type
that you are developing. You can use this value to clarify the device
messages for which you have developed custom event types.
33. In the Description field, type Message type indicates the requested URL is being
filtered.
34. We must now associate an Event Type with this syslog message. There are predefined
Event Types in the MARS or we can create our own. For our labs, lets choose one thats
already present in MARS. In the Map to Event Type select All and All Severity as the
following indicates and Access denied in the search field and click the Search button.
35. Select Access denied for a specific URL or FTP site.
36. Click the double arrow to have the selection move to the selection list on the left.
38. Click the Patterns link (towards the top of page) to define a Pattern for the created
Definition..
40. Currently MARS supports the following parsed value fields in its events:
Source address
Destination address
Source port
Destination Port
Protocol
NAT Source address
NAT Destination address
NAT Source port
NAT Destination Port
NAT Protocol
Device Time stamp
Session Duration
Received Time stamp
Exchanged Bytes
Reported User
41. Fill in the following fields with the values that follow:
Position:1
Key Pattern: This field should be left blank (see output below)
Parsed Field: Received Time
Value Type: Time
Pattern Name: in the new name field, enter Barracuda-Time
Value Format: %b%d%H:%M:%s
Value Pattern: \w{1,3}\s\d{1,2}\s\d{1,3}:\d{1,2}:\d{1,2}
42. Click the Submit button. We are going to be entering in five values. At the end of each,
we are going to test the parser. Take the original message you created in Step 6 (or
copied) of this lab and paste it into the Log Message field. The message should be:
Sep 19 17:07:07 Barracuda httpscan[3365]: 1158710827 1 10.1.1.8 172.27.72.27 text/html
10.1.1.8 http://www.itunes.com/ 2704 3767734cc16059e52447ee498d31f822 ALLOWED
CLEAN 2 1 0 1 3 - 1 Spyware 0 - 0 itunes.com Non-Business,Media ANON
43. Click the Test button.
44. Enter the message from Step 41 into the field and click the submit button.
45. The results of the test should be similar to the following. The Matched String field should
show Sep 19 17:07:07 indicating that the first parse worked correctly. If an error is
returned back the revisit the pattern entered for position 1.
46. Click the Close button.
Position: 2
Parsed Field: Workstation Name
Value Type: String
Pattern Name: in the new name field, enter Barracuda-Name
Value Pattern:
Note Remember to test the parser after each entry.
Position: 3
Parsed Field: None
Value Type: None
Pattern Name: in the new name field, enter Barracuda-Non-Parsed
Value Pattern: \S{1,15}:\s\d{1,20}\s\d{1,5}
Position: 4
Parsed Field: Source Address
Value Type: IPV4 (Dotted Quad)
Pattern Name: IPV4_DOTQUAD
Value Pattern: This field will auto-fill
Position: 5
Parsed Field: Destination Address
Value Type: IPV4 (Dotted Quad)
Pattern Name: IPV4_DOTQUAD
Value Pattern: This field will auto-fill
59. Now we must add the Admin-PC as the new reporting device since it is ending the syslog
messages. On the MARS go to Admin > System Setup > Security and Monitor
Devices.
61. Select the Barracuda WebFilter 1.0 (Local) from the drop down device type.
62. In the Device Name field, enter Barracuda-WebFilter.
63. In the Reporting IP field, enter 10.10.10.10.
64. For the Reporting Method, select SYSLOG.
65. Click on the Submit then Activate buttons. Close the activation popup window once
complete.
66. Re-send the syslog message from a command prompt on the Admin-PC by changing
directory to c:\program files\klog\klog command-line tools\klog.
67. Type the following all on one line or paste in from notepad: (You may be able to just
use the arrow up key to repeat the line if you havent closed out of command line
window)
klog.exe -h 10.10.2.100 -m "Sep 19 17:07:07 Barracuda httpscan[3365]: 1158710827 1
10.1.1.8 172.27.72.27 text/html 10.1.1.8 http://www.itunes.com/ 2704
3767734cc16059e52447ee498d31f822 ALLOWED CLEAN 2 1 0 1 3 - 1 Malware 0 - 0
itunes.com Non-Business,Media ANON"
Press the Enter key to send the message.
68. Go to Query/Reports.
71. In the Filter By Time section choose Last 10 Mins.
74. In the drop down box for the device type, select Barracuda WebFilter 1.0 (Local).
75. Select the Barracuda-WebFilter in the list of devices and click .
77. Click the Submit Inline button. You should see the following information displayed.
78. Click the Event ID for the data displayed.
79. Notice the data for the Event is mapped using our custom parser. It is now processing the
source and destination ip fields correctly and show the correct event type we selected for
this syslog message.
New Feature in 6.x
At the end of this lab you should feel that entering all these values and determining the correct parser
strings might be cumbersome. Hopefully you will not have to do this too much in production. Cisco
made a nice enhancement in version 6.0 to help create custom parsers. They now have a direct link from
MARS to a forum on Cisco.com where users can share their custom parsers and where you can
download them to MARS. To see the location of the link in MARS go to ADMIN > Custom Setup >
Device Support Packages. Press the Import button. Clicking the hyperlink on this page will take you
to the forum in a production environment. In our lab environment, the devices do not have internet
access so clicking the link will fail.
LAB Complete
L11
Lab 11: IPS and MARS
Integration
Lab 11 IPS and MARS Integration
Lab Overview
This lab covers the integration between the MARS appliance and a Cisco IPS device,
including the 42xx product line, AIP-SSM modules and IDSM2s. We will walk through
the steps of IPS configuration and SNMP settings. This lab is unique in that we use IPS
version 6.x software (the latest software) and provide you some command line
troubleshooting on the IPS when reporting to MARS. Usually this section is one that
draws quite a bit of interest from students. Rather than simply discussing the setup in
lecture, we have developed a detailed lab that you will find useful in your production
environment. Another value-add to this lab is that since we are using the latest version of
code on the MARS, you will have the opportunity to configure IPS Signature Dynamic
Updates. Beginning in 4.3.1 and 5.3.1, MARS can discover new Cisco IPS signatures and
correctly process and categorize received events that match those signatures. This feature
allows MARS to keep up with any updates your IPS may undergo.
30 minutes
Lab Procedures
1. Allowing Access to the IPS
2. Troubleshooting the MARS subscription to the IPS
Allowing Access to the IPS
This section covers the configuration of adding an IPS to the MARS appliance. Notice that the
IPS resides in the DMZ between the DMZ-Srv and the ASA. The base configuration for the IPS
is currently loaded from lab 4. We will enhance the configuration by pointing the IPS to MARS
and completing the configuration of the IPS.
1. Go to the Security-Srv and open Kiwi Cattools. You can double click the icon on
the desktop to open the program. You may need to login to the Security-Srv to get access
to the desktop. Use the username administrator and the password cisco.
2. Once the Manager window opens, click on the Show button and select the Cattools
window that opens in the background.
3. Click on the Activities tab and click the Stop Timer button at the bottom of the screen.
This stops the Cattools from logging into the MARS-Supplement-Sw and flapping the
switch interface. This flapping was generating alerts for our investigations in prior labs
but now we need the interface to be stable since its the IPS Command & Control (C&C)
interface.
4. On the Admin-PC open Firefox from the desktop and browse to https://10.10.2.110
which is the C&C (command and control) interface of the IPS.
5. Choose Accept this certificate permanently and click OK.
6. Click the Run IDM button under the splash page that appears. IDM stands for IPS
Device Manager and is the main GUI for configuring the IPS. If any popup appears, click
the OK button to load the Java applet.
7. Click Yes then Run to the Security Popups that appear.
8. Click No when prompted to create a desktop icon.
9. In the login box to the IPS use the username cisco and the password ccspattack and click
OK. You should now be at the IDM interface.
10. Click on the Monitoring button at the top of the screen. We are going to first review any
alerts the IPS is seeing to confirm that its processing correctly.
11. Click on the Events link on the left of the page.
12. On the right of the screen uncheck all the boxes in the Show Error Events section.
These are errors relative to the IPS and not related to user traffic. We will try to cut down
on the clutter displayed.
13. In the Show Past Events field, type 5 and select minutes from the drop down box.
14. Click the View button at the bottom of the page.
15. There may be no events displayed in the events window. At the beginning of the course
we loaded a base configuration into the IPS that had signature ID 2004 configured to
generate alerts. That signature alerts on ICMP messages. Lets generate some alerts by
going to the command prompt of the DMZ-Srv and pinging www.sru.com. This ping
should be successful.
16. On the Admin-PC click the Refresh button on the events display page of the IPS and
choose Yes if a popup window appears. You should now see some alerts being generated.
17. Select the latest alert and click the Details button.
18. Notice the Alert is for signature ID 2004. We have customized this well known signature
to fire when an echo request is received through the IPS. You should see the DMZ-Srv IP
address (172.16.1.15) as the attacker and the www.sru.com IP address (50.50.50.50) as
the destination.
19. Once you are finished viewing the Alert, you can exit the window by clicking the close
button. Close the event viewer window by clicking close again.
20. Now that we have verified some alerts and that the topology is working correctly, lets
send these alerts to MARS. Usually for monitoring events on an IPS we would use
Ciscos free software called the IPS Event Viewer (IEV). This software works by
subscribing to a live feed from the IPS so show real time alerts. It uses SDEE which is an
open standard format for alerts wrapped in a ssl/tls session to secure the connection.
MARS will behave just like the IEV software and open a subscription to the IPS to pull
live alerts. The first thing we must do is allow the MARS to communicate with the IPS.
21. On the IDM click the configuration button at the top of the screen.
22. Under Sensor Setup, click the Allowed Hosts link.
23. Click the Add button on the right screen to add the MARS access into the IPS to pull
alerts.
24. Enter the ip address 10.10.2.100 and a /32 subnet mask. Click the OK button.
25. Click Apply at the bottom of the screen.
26. Note that the following SNMP settings are not needed to allow alerts to be sent to
MARS. They are however needed if you would like MARS to monitor the resource usage
of the IPS. Click Sensor Setup > SNMP > General Configuration.
27. Check the box to enable SNMP Gets/Sets.
28. Under the Read-Only community string field, type MARS4reading.
29. Under the Write community string field, type MARS4writing. Although MARS will not
write to the IPS, its required in the IPS to enter this value.
30. Under the Sensor Contact field, enter PODX (replace the X with your Pod number
assigned)
31. Under the Sensor Location field, type GK Labs
.
32. Click Apply at the bottom of the screen.
33. Click Sensor Setup > SNMP > Traps Configuration.
34. Click the check box to enable SNMP traps.
35. Click the check box to enable Warnings for IPS error events that occur.
36. Click the check box to enable detailed alerts for traps.
37. In the Default community string field, type MARS4reading.
38. Click the Add button to add a trap destination.
39. In the IP Address field, enter 10.10.2.100
40. In the Trap Community String field, leave the field blank since we already defined a
default string.
41. Click the OK button.
43. In a production environment it would be a good idea (or required) to create a separate
user in the IPS for event monitoring. In the IDM click Sensor Setup > Users. Click the
Add button to add in a new user.
44. For the username choose mars. Note that the current version of software on the IPS does
not support external authentication to a RADIUS/TACACS server.
45. For the password choose iattacku2
46. For the Role select Viewer.
47. Press the OK button at the bottom of the screen.
48. Click the Apply button at the bottom of the screen.
Adding an IPS to MARS
49. On the MARS, go to Admin > Security and Monitor Devices.
51. Select Cisco IPS 6.x in the device type drop down.
52. In the Device Name field, type DMZ-IPS.
53. In the Reporting IP field, enter 10.10.2.110.
54. In the Login field, type mars.
55. In the Password field, type iattacku2.
56. Select Yes to monitoring Resource Usage.
57. Select Yes to Pull IP Logs. This option allows you to view any captured packets from the
IPS.
58. Press the Test Connectivity Button at the bottom of the page. Press the OK button in the
popup message box that appears.
59. New fields will be made available now on the page. Click the Discover button. This will
allow MARS to query the IPS to learn about the currently configured Virtual Sensors.
60. Select DMZ-IPS/vs0 and press the Edit button.
61. We will use the next option to identify the protected networks for detailed reporting
capabilities. This option allows for attack path calculation. In the Monitored Networks
box, choose the Select a Network radio button and then choose the
172.16.1.0/255.255.255.0(n-172.16.1.0/24) network from the drop down on the right of
the screen and click the Add button.
62. Click the Submit button at the bottom of the screen. Click the Submit button once again.
63. Click the Activate button at the top of the screen, then click close on the window that
pops up.
64. Go to the Access-PC and expand the IPS-Sensor link at the left of the remotelabs.com
webpage.
65. Click on the Hyperterminal link under the IPS-Sensor.
66. Login using the POD password provided by your instructor on the first day of class and
press Enter twice.
67. When prompted for the credentials of the IPS, enter cisco as the username and
ccspattack as the password.
68. We want to show the current subscriptions to the IPS eventstore to verify MARS is
pulling alerts. We can do that by entering the show statistics sdee-server command. You
will see a single current subscription to the eventstore created.
sensor# sh statistics sdee
General
Open Subscriptions = 1
Blocked Subscriptions = 0
Maximum Available Subscriptions = 5
Maximum Events Per Retrieval = 500
Subscriptions
sub-1-26aad996
State = Open
69. Go to the Outside-PC and enter the following URL using Firefox
http://www.gkl.com/etc/root.exe . This URL will trigger an alert on the IPS.
70. Verify the alerts are being generated by going to the Admin-PC and visiting the IDM
again and clicking the Monitoring button and viewing alerts that have occurred in the
past 5 minutes. You should see an event pertaining to root.exe access. When done
viewing the events click close.
71. Now its time to visit the MARS to see the incidents it is generating from the IPS alerts.
Go to the Incidents tab on MARS.
72. You should now see a new Incident being generated from the IPS with the name System
Rule: Server Attack: Web Attempt in the Matched Rule column. Select the latest Incident
with that rule name and click the View button.
73. Scroll down to the bottom of the next window to confirm the IPS is the reporting device
for this Incident.
74. Again, by clicking the Raw Message icon you can view details of reported
information. In version 6.x software the incident information now being reported is
similar to what you see in the IPS as indicated below. When you are done viewing the
raw message, click close.
New Feature in 4.3.x/5.3.x
Starting in version 4.3.1 and 5.3.1 of the MARS, we can load signatures into MARS
directly from Cisco.com. There is an initial set of IPS signatures residing on the MARS
in the database when the initial install is completed. After that, we must load each
signature file individually. This newer feature supports dynamic signature updates.
Beginning in 4.3.1 and 5.3.1(for Gen2), MARS can download the new signatures and
correctly process and categorize received events that match those signatures. If this
feature is not configured, the events appear as an unknown event type in queries and
reports, and MARS does not include these events in any inspection rules. These updates
provide event normalization and event group mapping, and they enable your MARS
Appliance to parse Day Zero signatures (as long as the signatures are up to date) from the
IPS devices. This is where purchasing a Cisco IPS differs from other IPS/IDS on the
market including SNORT. For non-Cisco products, MARS will receive new signature
updates when you manually update the MARS software, yet you can have up to date
signatures and therefore parsing by using a Cisco IPS.
Note You must download these signatures from CCO in the MARS section of
the download site and not the IPS section. This feature provides nothing
other than the ability to correctly parse and categorize new IPS alerts
correctly. Because these updates are downloaded from Cisco, they apply
only to known threats. As such, support for custom updates is not
included here. To support custom updates, MARS has an IPS Custom
Signature Update page which can be configured separately.
75. Go to the Security-Srv. Open the Security-Srv icon on the desktop that resembles My
Computer. Browse over to the D: drive named MARSv3.0.
76. Locate the file named IPS-Sigs-Generic.zip. Copy the file to the
C:\INETPUB\WWWROOT directory on the Security-Srv. We have renamed our file to
easily update our labs without having to rewrite our manuals. When you download the
latest signatures from Cisco, the name will contain the Signatures file version.
77. On the MARS, go to Admin > System Setup > IPS Signature Dynamic Update
Settings.
78. In the URL field notice the default location of the file is https://www.cisco.com/cgi-
bin/ida/locator/locator.pl. Note that this has to be an SSL connection, not http. Since our
remotelabs.com lab environment is completely cut off from the internet, we will not be
able to download these updates directly from Cisco.com. However, we have already
copied an update file and placed it in the WWWRoot directory to be downloaded by the
MARS. In the URL field, please enter https://security-srv/IPS-Sigs-Generic.zip
79. In the Signature Pulling Interval, select Every 1 hour.
80. Click the Test Connectivity button at the bottom of the screen. A popup alert should be
displayed indicating a successful connection. Click OK to the popup. Notice that even
though the connectivity test succeeded you have not yet downloaded the IPS update. The
status should still indicate that the last update attempt failed.
81. Click the Update Now button to start the download process. A popup box will be
displayed informing you that the process has started. Click OK on the popup.
82. Notice the status indicator back at the IPS Update Settings page. It should display that
the signatures were successfully updated or that there are no new updates to download.
83. Click the Submit button at the bottom of the page, and then click OK to the popup
window.
84. MARS can now parse and correctly categorize any alerts received from the IPS that is
has a signature for.
LAB Complete
L12
Lab 12: CSM Interaction
Lab 12 CSM Interaction
Lab Overview
In this lab we will show the integration of MARS and the CSM product. MARS has been
developed in close relation to Cisco Security Manager (CSM). CSM is a Security
Management Product that allows an organization one central location to provide
configurations for their Cisco Security products, including Routers, Switches, IPS/IDS,
PIX/ASA and various other products. This is now Ciscos flagship Security Management
product. The interaction with MARS allows us to view incidents on MARS and easily
review the associated policy in the network device by querying CSM for that portion of
the Network Device configuration responsible for the event. You will see two
demonstrations of this Cross-Launch capability in the lab. In the first demonstration
MARS will query CSM for an ASA configuration. In the second, MARS will query
CSM for an IPS configuration.
45 minutes
Lab Procedures
1. Verify the VMs
2. CSM Bootstrapping
3. MARS Configuration for CSM
4. Test the Cross-Launch
It is imperative for this lab to not have too many Virtual Machines (VMs) running at once. In
Labs 1 through 11 you used the same set of VMs while taking care not to turn on either the
CSM-Srv or the AV-Srv. This lab will require the use of the CSM-Srv, however, you will need
to turn off two VMs before starting the CSM-Srv. The two VMs to shut down are the Site1-
PC and the Security-Srv. It is important to shut these down one at a time and to wait for the first
to shut down before attempting to shut down the second.
At this time, please shut down the Site1-PC by clicking start > shut down in the virtual
machine. Verify that you want the VM to shut down and click OK.
Wait until you see that the Site1-PC VM is Powered off before proceeding
Next, shut down the Security-Srv. Click start > shutdown in the VM. Verify that you want the
VM to Shut down, choose Option Application: Maintenance (Planned) and click OK.
As with the previous VM, verify that this VM shuts down completely before proceeding.
Once both VMs are powered off, you may power on the CSM-Srv by right clicking it in the
inventory frame and choosing Power On.
Once the CSM-Srv is Powered On, you must logon using the Administrator account with a
password of cisco. Please make sure to logon to the GKL domain. If the server seems to be
hanging after 5 to 7 minutes, please press the stop button in the VMWARE console to shutdown
the server. Proceed to start the server again and continue the lab.
The table below lists all of the VMs that should now be running for this lab. Please verify this
and if you find any other VMs running, please shut them down by clicking Start > shutdown.
Access-PC Data-Srv Admin-PC Services-R-Us DMZ-Srv Outside-PC CSM-Srv
CSM Bootstrapping
1. Login to the Admin-PC using the username administrator and password cisco make
sure you log into the gkl.local domain.
2. The CSM logon box should appear upon entering the Admin-PC, if it doesnt simply
double click the icon on the desktop named Cisco Security Manager Client.
3. Enter the username admin and the password csm$Pwd for the password and press the
Login button (note that the credentials are also displayed on the desktop). The GUI
interface will take approximately 10 seconds to load the java window. If you get an error
when logging in to the CSM Client, you can close the login screen and re-launch the
application shortcut from the desktop.
4. The CSM will pull the last polled configurations from the CSM Servers database. If this
is your first experience with CSM take a few minutes to click around the interface. We
have already populated the CSM database with three of the network devices in our
topology. Lets show you how to add a device to CSM. Right click the HQ group and
select the New Device option.
5. Select the first option to add the device from the network and click the Next button.
6. In the next window, enter the following parameters:
IP Type: Static
Host Name: DMZ-IPS
Domain Name: Leave Blank
IP Address: 10.10.2.110
Display Name*: Automatically Filled In
OS Type: IPS
8. On the next page enter the following parameters and leave all other settings on the page
at their default values:
Username: cisco
Password: ccspattack
Confirm: ccspattack
9. Click the Finish button. You will see a window indicating the device is being discovered.
10. Click the Close button after the IPS is successfully discovered. You should now see the
IPS on the left of screen as a device in CSM.
11. Click the Tools menu at the top of the CSM client window. Select Security Manager
Administration.
12. Select CS-MARS from the menu on the left of the page and press the plus sign on the
right of the screen to add our MARS into CSM. Enter the following information in the
popup window:
Hostname/IP: 10.10.2.100
Username: pnadmin
Password: pnadmin
13. Click the Retrieve from Device button and accept any certificate popup boxes that
appear.
14. Click the OK then Save buttons.
15. Close the CSM client. The IPS has been successfully added and ready for cross-
launching from our MARS. Choose Yes to the warning about saving your changes.
MARS Configuration for CSM
16. Go to the MARS and click on Admin > System Setup > Security and Monitor Devices.
17. Click the Add button to add the CSM-Srv into MARS as a reporting device.
18. Click the drop down box to Add SW security apps on new host.
19. Enter the following parameters in the appropriate fields:
Device Name: CSM-Srv
Access IP: 10.10.2.11
Reporting IP: 10.10.2.11
Operating System: Windows
NetBIOS Name: CSM-Srv
20. In the IP address field for Eth0 at the bottom of the screen, enter the IP address
10.10.2.11 with a mask of 255.255.255.0.
21. Click the Next button at the bottom of the page. A message box will appear indicating
that log pulling is not enabled. Press the OK button to continue.
22. On the following page select the Cisco Security Manager ANY application and click the
Add button.
23. On the popup box that appears, enter the following information into their respective
fields.
Username: admin
Password: csm$Pwd
Access Type: HTTPS
Access Port: 443
We will use the Cross-Launch Authentication Settings which allows for Prompting Users the
first time they choose to attempt a Cross-Launch. The other option to use MARS credentials is
currently part of an open issue with Cisco and should be avoided at this time (as indicated by
bug CSCso16735).
24. Press the Test Connectivity button at the bottom of the page. Click OK to the popup
indicating the connection was successful.
25. Click the Submit button at the bottom of the page.
26. Click the Done then Activate then close buttons on the next screens.
27. The CSM-Srv should now be seen on the main devices page.
Test the Cross-Launch
Cisco is currently working through several issues pertaining to the query feature between MARS
and CSM, for ASAs. We will demonstrate this capability. However, due to open issues, we
will only be able to demonstrate limited functionality at this time. There are currently no known
issues with the query between MARS and CSM, for IPS. As a result we will be able to
demonstrate more functionality in the second example.
28. First we will test the ASA reporting capability of MARS and the CSM Server. Go to the
Query/Reports tab and run a query on live events entering MARS. Click the Edit button
in the Query Type Section.
30. Select Real Time Raw Events so we can see the events as they are processed by MARS.
31. Click the Apply button
32. Click the Submit button to start the process request.
33. Wait about 30 seconds to 1 minute and you should see some output coming in from the
ASA resembling the following output:
34. After a few more messages appear, look for a message that contains the phrase
TIME.NIST.GOV/123 to inside:200.200.1.2/123 in the RAW Message section. Press
the Pause button at the bottom of the page when the message appears. Due to the non-
chatty nature of NTP this event can take several minutes to generate. You must wait for
this specific message as it is one of the messages that can successfully be queried on for
the ASA. Feel free to query on other messages, but realize that you may get nothing but
a server Error as a result of those queries.
35. Notice the new icon in the message indicating the CSM Server can be queried to view the
Policy Matching Rule.
36. Click the new icon to query CSM and reveal the Policy that produced our event
37. A popup window should appear requesting credentials to the CSM Server. Please enter
the username admin and the password csm$Pwd. Also select the option to save the
password for future requests to the CSM Server. Click the Submit button once
complete.
38. If asked, click Yes to messages about displaying both secure and non-secure content.
After approximately 15 seconds the following output should be displayed. The Error is
indicating that CSM does not control this policy. In fact, any management traffic going to
and from our network devices will not trigger a query to the CSM Server. Since this
traffic is NTP related to the ASA and not through the ASA, a lookup will not be
performed. Click Close when done viewing. Note that your message may differ from
ours displayed.
39. Now we will test the IPS reporting and interaction between MARS and our CSM server
by launching an attack from the Outside-PC against our DMZ. The IPS will see this
traffic and match a signature that will be displayed in MARS. On the Outside-PC, open
the Internet shortcut on the desktop and type in the URL http://www.gkl.com/root.exe
40. After a few seconds, the event should be displayed in MARS as indicated by the
following output.
41. Click on the CSM icon in the Reporting Device column next to DMZ-IPS to cross-launch
a CSM session. Click Yes on the Security popup window.
42. The following popup should appear, showing you the details of the signature that caused
the event to fire. Notice the signature cannot be edited here but you can click the Edit
Signature to launch a web session to the CSM Server to edit the signature there.
43. You have successfully cross-launched from MARS to Cisco Security Manager, close the
popup window once you have examined the policy.
LAB Complete
L13
Lab 13: Adding a Software
Reporting Device
Lab 13 Adding a Software Reporting Device
Lab Overview
This lab will cover software reporting devices. We will show the integration between
event logs in your windows servers and the monitoring of applications such as an IIS
Web Server as well as an Active Directory Domain Controller. We will install the latest
version of SNARE to report the Windows log data to MARS and show you the various
SNARE programs available for free. Since most of you are also using some sort of Virus
Scan Software, we have incorporated the Symantec Anti-Virus Server into this lab. We
will walk you through setting up the Alert Server so that MARS can report on any virus
activity. In doing this, we will activate a virus and demonstrate the capability of MARS
to work with Symantec in generating anti virus incidents.
60 minutes
Lab Procedures
1. SNARE for IIS Installation
2. MARS Side Configuration
3. Adding a Windows Host to be Monitored
4. Adding an AntiVirus Server to be Monitored
It is imperative for this lab to not have too many Virtual Machines (VMs) running at once This
lab will require you to power off the CSM-Srv and then power on the AV-Srv and the Site1-PC.
It is important to shut down the CSM-Srv completely before turning on either of the other
two VMs. When turning on the VMs please wait until you logon to the AV-Srv before
attempting to start the Site1-PC.
At this time, please shut down the CSM-Srv by clicking start > shut down in the virtual
machine. Verify that you want the VM to Shut down, choose the Option Application:
Maintenance (Planned) and click OK.
Please wait until the CSM-Srv is completely powered off. Once the CSM-Srv is powered off,
power on the AV-Srv by right clicking it in the inventory panel and choosing Power On. Once
the AV-Srv powers up logon with username: administrator, password: cisco.
After you logon to the AV-Srv you may power on the Site1-PC by right clicking it in the
inventory panel and choosing Power On. When it boots up logon to the Site1-PC with
username: administrator, password: cisco.
Access-PC Data-Srv Admin-PC Services-R-Us DMZ-Srv Outside-PC Site1-PC AV-Srv
SNARE for IIS Installation
To configure IIS to publish logs to MARS, you must install and configure a log agent.
This agent is free from the InterSect Alliance. This software is known for taking the
windows/IIS event logs and forwarding them to MARS. You will more than likely have
this application installed on most of your servers in your own network environment. You
can download the Snare Agent for IIS Servers from the following URL:
http://www.intersectalliance.com/projects/SnareIIS/index.html#Download
1. On the DMZ-Srv open My Computer on the desktop.
2. Open the D: drive named MARSv3.0.
3. You will see a file towards the bottom of the list named SnareSetup-2.6.7-
MultiArch.exe. Double click the program to begin the installation process.
4. Click the Next button on the Welcome Screen.
5. Click the Next button on the default file location.
6. Click the Next button to choose the Normal Installation.
7. Click the Next button for the default shortcut menu names.
8. Choose Yes to have SNARE take control of our windows event logs. Click Next.
9. Choose Yes to allow Remote Control of SNARE and choose the 3
rd
option that indicates
Yes with no password, local access only to be used. SNARE can be managed by your
IT staff and can provide a remote web interface for configurations, in a production
environment you will want to password protect this interface. Click Next.
10. Click the Install button at the last configuration page.
11. Click the Next button on the information page.
12. Click the Finish button.
13. Close any remaining windows after the installation is successful.
14. Click the Start button > Programs > Intersect Alliance > Snare for Windows. A
webpage should popup indicating that the SNARE program is installed and running.
15. Now that SNARE is installed for the Windows operating system, we must also install IIS
Snare to take the web logs and forward them to MARS. Open My Computer on the
desktop of the DMZ-Srv and expand the D: drive named MARS.
Note The latest version that we are installing also now allows Microsoft Exchange
Integration which allow us to pull Exchange logs and report to MARS.
16. Find the file named SnareIISSetup-1.2.exe and run the program.
17. Click the Next button to proceed through the Welcome screen.
20. Click the Install button at the final page of the installation.
21. The following windows will appear to finalize the configuration.
22. In the Target Host field, type 10.10.2.100 which is the MARS appliance.
23. Leave the Log Directory at its default value.
24. For the Destination click the Syslog option.
25. Click the Ok button to accept these changes.
26. Click next and then Finish. Close any other windows that appear.
27. On the DMZ-Srv click on Start > Programs > Administrative Tools > Internet
Services Manager.
28. In the Tree tab on the left, right-click Default Web Site and select Properties.
29. In the Web Site tab:
a. Make sure Enable Logging is checked
b. From the Active log format list, select W3C Extended Log Format
c. Click Properties
30. Make sure the New Log Time Period chosen is Daily.
31. Make sure the Log File Directory location matches the log directory we chose during
our installation of the IIS SNARE program.(%WinDir%\System32\LogFiles)
32. Click on the Extended tab and select all available options to log.
33. Select OK on all screens to return back to IIS Manager.
MARS Side Configuration
34. On the Admin-PC go to MARS click Admin > Security and Monitor Devices > Add
35. From the Device Type list, select Add SW Security apps on a new host.
36. In the Device Name field, type DMZ-SRV.
37. For the Access IP address field, enter 172.16.1.15
38. For the Reporting IP address field, enter 172.16.1.15
39. Select the Windows from Operation System list
40. In the NETBIOS name field, enter DMZ-SRV
41. Choose No to Monitor Resource Usage. (This feature is currently not supported on
Windows Software Devices). The following list identifies the devices supported for
resource monitoring:
Cisco IOS routers running 12.2
Cisco IOS switches running 12.2
Cisco PIX 6.0, 6.1, 6.2, 6.3, 7.0
Cisco ASA 7.x
Cisco FWSM 2.x and 3.x
Check Point devices (Opsec NG FP3)
42. Click the Logging Info button.
43. Choose Microsoft Windows 2000 for the operating system.
44. You must check Receive for the logging mechanism. Since we are using SNARE, we will not
need to enter any credentials information since this mechanism is a Push from the server.
46. In the Interface Information box at the bottom of the screen enter 172.16.1.15 for the eth0
ip address and 255.255.255.0 for the network mask.
47. Click the Next button at the bottom of the screen. Press the OK button to the popup that
appears.
48. Click the OK button to the popup window.
49. From the Select Application list, select Generic Web Server Generic and click the Add
button.
50. When you see the popup window appear, select WC3_Extended_Log format in the Web
log format drop down and click the Submit button.
51. Click the Done button.
52. Click the Activate button at the top right of the screen and close the window that pops
up.
53. Go to Query/Reports tab and run a query on the DMZ-Srv reporting device to see all
traffic being received from that device. Click the Query/Reports tab.
56. In the Filter By Time section choose Last 1 Hrs.
60. In the drop down box that lists All Variables by default, select All Reporting Devices.
61. Select the DMZ-Srv in the list of devices and click the button to add the selection.
64. If you do not see any messages being received in the database you can browse to the
DMZ-Srv from the Outside-PC by browsing to http://www.gkl.com You can also
generate errors by browsing to http://www.gkl.com/_private which is an invalid
directory. Refresh the query as needed to view the results.
Adding a Windows Host to be Monitored
Now that we have seen how MARS interacts with Web Logs from IIS, lets continue by
installing SNARE on our Domain Controller to pull any Windows Event Logs into MARS.
Most installations will use the following steps to get their log data into the MARS to consolidate
log viewing across the enterprise.
65. On the Data-Srv, open the Data-Srv icon on the desktop to bring up Windows Explorer.
66. On drive D: named MARS, you will see a file towards the bottom of the list named
SnareSetup-2.6.7-MultiArch.exe. Double click the program to begin the installation
process.
67. Click the Next button on the Welcome Screen.
69. Click the Next button to choose the Normal Installation.
71. Choose Yes to have SNARE take control of our windows event logs. Click Next.
72. Choose Yes to allow Remote Control of SNARE and choose the 3
rd
option that indicates
Yes with no password, local access only to be used. Click Next.
73. Click the Install button at the last configuration page.
74. Click the Next button on the information page.
75. Click the Finish button.
76. Close any remaining windows after the installation is successful.
77. Click the Start button > All Programs > Intersect Alliance > Snare for Windows. A
webpage should popup indicating that the SNARE program is installed and running.
78. Click the Network Configuration section on the left of the webpage.
79. In the Destination Snare Server address field, type 10.10.2.100
80. In the Destination Port field, type 514 to send to the standard syslog port on the MARS.
81. Click the Change Configuration button and click continue in the popup window that
appears.
82. On the left of the webpage click the Apply the Latest Audit Configuration link to make
the configurations active.
Thats all thats needed for the SNARE setup on the Windows server.
83. If asked to enable Auto Complete click Yes.
84. On the Admin-PC go to MARS click Admin > Security and Monitor Devices > Add
86. In the Device Name field, type DATA-SRV.
90. In the NETBIOS name field, enter DATA-SRV
91. Choose No to Monitor Resource Usage.
94. You must check Receive for the logging mechanism since we chose to run SNARE on
the Windows Server. We could choose not to run SNARE and have the MARS device log
into the server to pull logs.
97. Click the Apply button at the bottom of the screen.
98. Click the Done button at the bottom of the page. Click Ok to any popups that appear.
99. Click the Activate button at the top of the page. Close the activation done window that
opens.
100. Go to Query/Reports tab and run a query on the DMZ-Srv reporting device to see all
108. Select the Data-Srv in the list of devices and click the button to add the server to
our selection list.
111. Go back to the Data-Srv and logoff the server. Our remotelabs script will automatically log
you back in which is fine. Go back to your MARS and review the live events as they come in.
Note If no messages appear after a few minutes, reboot the Data-Srv. Sometimes
multiple services need to restart before messages are processed. In production
restarting the service on the SNARE server usually starts the processing.
Adding an Anti-Virus Server to be Monitored
112. Go to the AV-Srv that is running Symantec AV. Ignore any Symantec license
expiration notices that may appear.
113. Go to Control Panel and run Add/Remove Programs.
114. Click the button to Add/Remove Windows Components on the left of the screen.
115. Scroll down and highlight Management and Monitoring tools (DO NOT CLICK
THE CHECKBOX) and click the Details button.
116. Make sure the Simple Network Management Protocol is the only option you select
and click the OK button (leave the remaining defaults).
117. Click the Next button on the following screen. Press the OK button when prompted
with the following popup.
118. The system will prompt you twice for the file location of the Windows 2003 CD 1. If
you are prompted for CD2 then please go back and correct the previous steps so that
SNMP was the only item selected. Browse to the C:\I386 folder and click OK.
119. Click the Finish button at the end of the installation process. Close the Add or Remove
Programs Window.
120. Basically what we are doing is turning on the SNMP Traps service in the server.
Symantec Anti-Virus servers need this enabled in order to send alerts to MARS. To
identify the MARS as a valid SNMP trap destination, double click Start > Control
Panel > Administrative Tools > Services > SNMP Service
121. Select the Traps tab.
122. Enter the Community String MARS4reading in the field provided and click the Add to
List button.
124. Enter the IP address of 10.10.2.100 in the Trap Destination page, and click the Add
button.
126. Now we must do a quick repair of the AMS Alert software which is specific to
Symantec in order to allow it to read the SNMP settings just added. Please double click
the icon on the desktop of the AV-Srv named AV-AMS . Click Next, choose the
Repair option and click Next then Install when prompted. When the repair is done
click Finish and choose yes to reboot the server. The AMS software requires it be
installed after the SNMP service is added to the system which is why we are
reinstalling.
127. When the AV-Srv comes back up, logon and double click the icon on the desktop to
launch Symantec System Control Center.
128. In the Symantec System Center window, expand Symantec System Center Console.
129. In the Symantec System Center window, expand System Hierarchy.
130. Under System Hierarchy, right-click the Symantec AntiVirus 1 server group name and
unlock the server group. The username is administrator and the password is cisco123.
Click the OK button. Unlocking the server allows you to configure it.
131. Configure Symantec server (AMS-Alert Management System) to send SNMP traps to
MARS. Right Click the Server Group Name > All Tasks > AMS > Configure.
132. Expand the Symantec Antivirus Corporate Edition in the popup window.
133. Select Virus Found and click the Configure button.
134. In the popup window select the Send SNMP Trap option and click Next.
135. Select the AV-Server.gkl.local in the window and click the Next button.
136. Click the Finish button on the Action Screen. The action is now set when a virus is
detected.
137. Close any windows that are related to Symantec AntiVirus. Choose Yes if asked to
save.
138. On the Admin-PC go to MARS Admin > Security and Monitor Devices and click
Add
140. In the Device Name field, type AV-Srv.
144. In the NETBIOS name field, enter AV-Srv
148. For the domain enter gkl.local
149. For the username enter, administrator
150. For the password enter, cisco
151. Select the Pull mechanism to have MARS pull the Windows logs from this server since
we have chosen not to install SNARE. MARS will log into the server every 5minutes to
pull the logs using the credentials defined.
153. In the Interface Information box at the bottom of the screen enter 10.10.1.11 for the
eth0 ip address and 255.255.255.0 for the network mask.
155. Click OK to any popup messages that might be displayed.
157. For the Reporting Application, select Symantec Anti Virus 10.x and click the Add
button.
158. A window will popup asking you to enter information regarding the AV clients running
in your network. MARS needs to know all the hosts that have the agents running. You
can either enter them in manually or use a CSV file as we did in a previous lab to
populate the device information. In our lab we will just add the agent. Click the Close
button without selecting any options.
159. Click the Done button. You should now be at the Reporting Applications page. If you
are not, simply click on the Reporting Applications tab at the top of the page.
160. Now that the AV-Srv is in the MARS we can go back in and edit the server to add it as
an agent installed host. Select Symantec Anti Virus 10.x and click the Edit button.
161. Click the Add button when the popup window is displayed.
162. Click the Add New button to create a new agent.
163. In the Device Name, enter AV-Srv-Agent.
164. In the Reporting IP field, type 10.10.1.11.
165. In the interface section for Eth0 enter the IP address, 10.10.1.11 with a mask of
255.255.255.0.
168. Click the Done then Activate buttons.
Back at the main Devices page you should now notice that the AV-Srv is listed as a
Windows 2003 host with a Symantec Anti Virus 10.x agent running.
169. Go to Query/Reports tab and run a query on the AV-Srv reporting device to see all
172. Select Real Time Raw Events so we can see the events as they are processed by
MARS.
177. Select the AV-Srv and AV-Srv-Agent in the list of devices and click the button
to add the server to our selection list.
180. Lets test our agent. We have already installed the Symantec AV client on the Site1-PC
from the AV-Srv. We also have a test virus we will use to test the alert setup. Go to the
desktop of the Data-Srv. Open the MARS folder. There are two files in the directory.
We have mapped a drive from the Data-Srv to the Site1-PC to deliver the virus. Simply
drag the eircar.com file to the Desktop on Site1-PC shortcut where the file will be
copied.
181. The second you drag the file over the virus will be detected. Verify this by clicking on
the Site1-PC. The following message should appear:
:
182. Go back to the MARS and verify the alert was received by viewing your Query running
in Real-Time. The following output should be displayed
183. Click the incidents tab and verify that MARS has generated a medium severity incident
based on the raw input received.
LAB Complete
L14
Lab 14: Adding a AAA
Reporting Device
Lab 14 Adding a AAA Reporting Device
Lab Overview
This lab will demonstrate how to integrate a AAA reporting device into MARS. In our lab, we
will be using the Cisco ACS 4.1 software build as the AAA reporting device. In a previous lab,
you installed SNARE on a windows server. Understand that SNARE for the OS only pulls
events out of the windows event viewer. Cisco Secure ACS does not send its log data to
windows event viewer, therefore it requires its own software to report log data to MARS. In this
lab you will install and configure the PNLOGAGENT on the ACS Server. The purpose of this
software is to take the ACS log files (failed attempts, passed authentications, and RADIUS
accounting) and send them to MARS using the syslog protocol. Note that even though ACS 4.1
has syslog capability built in, Cisco still requires the PNLOGAGENT for integration with MARS
After this lab, you will no longer need to sift through a CSV file on your ACS server to pull audit
reports since a simple query on the MARS will provide a better and enhanced report.
30 minutes
Lab Procedures
1. ACS Configuration
It is imperative for this lab to not have too many Virtual Machines (VMs) running at once This
lab will require you to power off the AV-Srv and then power on the Security-Srv. It is
important to shut down the AV-Srv completely before turning on the Security-Srv.
At this time, please shut down the AV-Srv by clicking start > shut down in the virtual
machine. Verify that you want the VM to Shut down, choose the Option Application:
Maintenance (Planned) and click OK.
Please wait until the AV-Srv is completely powered off. Once the AV-Srv is powered off,
power on the Security-Srv by right clicking it in the inventory panel and choosing Power On.
Once the Security-Srv powers up logon with username: administrator, password: cisco.
Note If an error is seen as you try to log onto the Security-Srv related to the time
being off, simply login locally to the server using the same credentials as
indicated above and change the time to reflect the current time in the
classroom. Log off the system and log into the GKL domain using the same
credentials to continue the lab.
Access-PC Data-Srv Admin-PC Services-R-Us DMZ-Srv Outside-PC Site1-PC Security-Srv
ACS Configuration
To configure the ACS to publish logs to MARS, you must first install and configure a log
agent. This agent is free from Cisco and can be found in the same location you download
the MARS upgrade packages. This program only needs to be installed on the servers in
your network that contains the Cisco Secure ACS software.
1. On the Security-Srv, open the link on the desktop named ACS Admin. Click OK/Run
to any certificate popups that appear. If prompted to run the java application, press Yes.
2. Click on System Configuration > Logging. Notice that there are three columns for the
stored reports, CSV, ODBC and Syslog.
3. Under the CSV column, notice that the Passed Authentication is not enabled. This is the
default settings. To properly show an auditor all authentications, good or bad, you will
want to turn this option on.
4. Click the Configure link next to Passed Authentication in the CSV column.
5. Click the check box at the top of the screen to enable this log.
6. At the bottom of the screen, choose to Generate a new log file Every Month. This is not
a required setting, but one you should be made aware of for your audits. You can also see
you can choose to keep a certain number of revisions.
8. Click CSV Passed Authentications, and verify that the following attributes appear in the
Logged Attributes list. If any of the following are missing, add them in at this time. If
you dont add the attributes at this time the PNLOGAGENT will let you know during its
configuration.
AAA Server (Not present by default)
User-Name
Caller-ID
NAS-Port
NAS-IP-Address
System-Posture-Token
EAP Type Name
9. Click Submit.
10. Click CSV Failed Attempts, and verify that the same attributes appear in the Logged
Attributes list:
User-Name
Caller-ID
NAS-Port
NAS-IP-Address
AAA-Server (Not present by default)
Authen-Failure-Code
Message-Type
11. Click Submit.
12. Now we have to add a few AAA clients.
13. Click on the Network Configuration button.
14. Under AAA Clients, click the Add Entry button.
15. In the AAA Client Hostname field, type Cisco-Equipment.
16. In the AAA Client IP Address, type 10.20.*.*
17. In the Shared Secret field, type sharedsecret.
18. In the Authenticate Using drop down box, select TACACS+ (Cisco IOS)
19. Click the Submit + Apply button at the bottom of the page. Notice that you can use *s
in the IP address octets for wildcards.
20. Now that the ACS is configured, we must install another application called
PNLOGAGENT. This application will retrieve the ACS log data and forward it onto the
MARS. On the Security-Srv, open the Security-Srv link on the desktop that resembles
My Computer.
21. Open the D: drive thats named MARS3.0.
22. Open the archived file named pnLogAgent_1-1.zip. Click OK to any popup windows
that may appear.
23. Run the PnLogAgentInstall.exe file from inside the archive.
24. Click the Next button in the Welcome screen and accept any license agreements
displayed and click the Next button again.
25. Click the Next button when it asks you for the installation directory.
26. Click the Install button on the following screen.
27. At the end of the install process click the Finish button.
28. In the new program window click Edit > PN-MARS Config.
29. In the MARS IP address field, enter 10.10.2.100 and click the OK button.
30. Click Edit > Log File Config > Add
31. In the Application Name drop down box, select Cisco ACS Failed Attempts.
32. In the Log File location field, enter C:\Program Files\CiscoSecure ACS
v4.1\Logs\Failed Attempts\Failed Attempts active.csv
34. Click Edit > Log File Config > Add
35. In the Application Name drop down box, select Cisco ACS Passed Authentications.
36. In the Log File location field, enter C:\Program Files\CiscoSecure ACS v4.1\Logs\Passed
Authentications\Passed Authentications active.csv
38. You should now have the two logs being forward to MARS. Thats it for the
configuration on ACS. You can choose other logs to forward to MARS but these are the
two basics.
39. Close the PNLOGAGENT program clicking Yes when asked to save.
40. On the MARS click Admin > Security and Monitor Devices > Add
42. In the Device Name field, type Security-Srv.
46. In the NETBIOS name field, enter Security-Srv
49. Click the Next button at the bottom of the screen. If a message box appears, press the OK
button.
50. In the Reporting Application drop down box, select Cisco Secure ACS 4.x and click the
Add button.
51. Click the Submit button in the popup window that appears.
Note that version 4.x of ACS can send syslogs natively without the PNLOGAGENT.
53. Click the Activate button at the top of the page.
54. On the main device page you will see the Security-Srv added with the ACS 4.x software
installed.
55. Test the PNLOGAGENT by entering the following commands on the Mars-Site1-Rtr.
Go to the Access-PC and log into the command line of the Mars-Site1-Rtr.
MARS-Site1-RTR# config t
MARS-Site1-RTR(config)# aaa new-model
MARS-Site1-RTR(config)#aaa authentication login default group tacacs+ none
56. In MARS, Go to Query/Reports tab and run a Query on the Security-Srv reporting device
to see all traffic being received from that device. Click the Query/Reports tab.
58. For the Result Format, select All Matching Event Raw
Messages
64. Select the Security-Srv the list of devices and click the button to add the server to our
selection list.
67. Go to the command prompt on the Data-Srv. Try to telnet to the MARS-Site1-RTR
(10.20.0.2). Enter a username of acs and password test. The authentication should fail.
68. Go back to the Query tab on the MARS and notice the failure, it should resemble the
following:
69. Go to the Security-Srv and launch the ACS-Admin link from the desktop. We are going
to enter a username in the ACS to test the passed authentication from the
PNLOGAGENT. Click on the User Setup button on the left of the webpage.
70. In the user field enter, acs and then click the Add/Edit button.
71. Scroll down in the user settings and enter the password test as indicated below:
73. Go to the command prompt on the Data-Srv. Try to telnet to the MARS-Site1-RTR
(10.20.0.2). Enter a username of acs and password test. The authentication should
succeed.
74. Go back to the Query tab on the MARS. You will now see the passed authentication that
was sent from the PNLOGAGENT on the Security-Srv.
LAB Complete
L15
Lab 15: Maintaining the MARS
Lab 15 Maintaining the MARS
Lab Overview
In this lab we will show you how to retrieve raw messages from the database for a
particular time range. This will be beneficial for auditors in your environment requiring
data output as well as aiding the auditors to confirm how long you retain your logs. We
will download the raw messages from the database to a server in the lab environment and
allow you to view the contents as the auditors would. MARS has a finite amount of
storage on which to hold the Oracle Database. Once local drive space runs out, MARS
simply starts overwriting the oldest portions of the database as new events are received.
In production it will be beneficial to configure MARS to perform Data Archiving. This
feature allows MARS to store a copy of the information in the Database on NFS. Since
NFS is a requirement in MARS for data archiving and most organizations in production
have Windows Servers, we will have you install Microsoft Services for Unix to allow
you to share windows folders as an NFS share that MARS can archive to. We will
demonstrate a security feature of NFS which allows for locking down which ip addresses
have access to the share. We will also be visiting some newer commands (available as of
4.3.1 code) to allow you to manually backup configuration and database data separately.
The remainder of the lab is dedicated to configuring an option which allows you to use a
RADIUS server (Microsoft IAS or ACS) to authenticate to the MARS appliance. We will
walk you through that configuration as well as the lockout feature for security.
60 minutes
Lab Procedures
1. Viewing Log Files
2. Data Archiving
3. Command Line Options
4. RADIUS Integration
Viewing Log Files
1. On the Admin-PC, web to the MARS appliance and login.
2. Click on the Admin tab and then the System Maintenance sub tab.
3. Click the View Log Files link. You should notice some entries for the past 10 minutes
related to the MARS backend log. These backend logs pertain to the MARS operational
status and not the reporting traffic/alerts that create incidents. Knowing the location of
these logs will be useful for troubleshooting.
4. To view messages related to incidents/rules, click the Admin tab and then the System
Maintenance subtab.
5. Click the Retrieve Raw Messages link.
6. Understand the settings
Archived Files
Archiving must be configured
Allows retrieval of messages from NFS archives based on
time ranges
Data
Source
From Database
Limited to retrieval of messages from time ranges that
still exist in the Database on MARS.
Allows retrieval of messages not yet in the Archive.
Time Range
Select range of interest
Filter
Select Reporting
Device
Filter results to either All or Individual Devices
Cache
Settings
Local Cache
Stores query results locally on MARS
Results available for download in gz format
Force Generation: Choose if the time range is not
currently locally cached on MARS. (Adds another file to
the local cache)
View Local Cache: See what time ranges have been
locally cached
Maximum Number: Define size of local cache
Remote NFS
Server
Archiving must have been previously configured
Stores query results on NFS server
Results available for download in gz format
7. Click View Local Cache. Notice that prior to submitting a query, there are no results
cached here for download. Click the back button
8. Leave all settings on the page at their default values except for the Filter selection.
Choose a time range that begins 1 day prior to the current date.
9. Click the Submit button at the bottom of the page. You will be brought to a status page
indicating the completion percentage for the messages to be retrieved. This page will
automatically refresh until the data is gathered.
10. At the end of the retrieval process, the MARS will provide the option to download the
retrieved messages. Notice the file format is a .GZ file so you will need the appropriate
program to expand the compressed file.
11. Click the Click Here to Download link. Save the file to the desktop on the Admin-PC
by clicking Save twice.
12. Once the file is saved, click open on the download complete window. The Winrar
program should open the file. Double-click the text file in the archive to view the
contents. You will notice a long list of entries in the file.
13. When done viewing the file close it and close the Winrar window as well.
14. Click Get More Files and the click on View Local Cache.
15. Notice that the query has now been cached locally. Also note that the file name includes
the time range of the query. You can also download the file from here by right clicking it
and choosing Save Target As. Feel free to experiment with this as well as other time
range queries for retrieving raw data at this time.
Note Any data seen in the archived file cannot be re-imported into the MARS without
overwriting the current database on the appliance. Ciscos recommendation is if
you ever need to perform forensic analysis on archived data, that is Queries or
Reporting on the archived data, you will need to purchase an additional MARS
appliance to import the archived data into.-
Data Archiving
You can archive data from a MARS Appliance and use that data to restore the operating system
(OS), system configuration settings, dynamic data (event data), or the complete system. The
appliance archives and restores data to and from an external network-attached storage (NAS)
system using the network file system (NFS) protocol. While you cannot schedule when the data
backup occurs, the MARS Appliance performs a configuration backup every morning at 2:00
a.m. and events are archived every hour. The configuration backup can take several hours to
complete.
When archiving is enabled, dynamic data is written twice: once to the local database and once to
the NFS archive. As such, the dynamic data that is archived includes only the data that is
received or generated after you enable the data archive setting. Therefore, we recommend that
you enable archiving before configuring your appliance to receive audit events from reporting
devices.
You will also need to review your storage space on the server. We have personally seen NFS
shares consuming an entire drives worth of space within weeks. The following table lists the
various archived folders stored on the NFS share stored based on date. Also remember that since
the MARS continuously writes to the NFS share, you will not be able to move the archive folder
on the server side, it will be locked because it is in use.
Archive Folder and
Data Type Description Archive Interval
Max. Interval
(in minutes) Schedule
AL: Audit log information Every 60 minutes. n/a
CF: Configuration
information
Once per day at 2:00 a.m. n/a Daily at
2 a.m.
ES: Events, sessions,
and raw messages
Every 10 minutes or when 3 MB (compressed) file
size is reached, whichever threshold is met first.
10 minutes n/a
IN: Incidents Immediately 1 minute
1
n/a
RR: Report results Once per day at 2:00 a.m. n/a
ST: Statistical
data/counters information
Hourly. n/a
Note There is a new command to help with archives added in version 4.3.1 named
pnexp. We briefly visited the command at the beginning of the week and now we
can use it to help estimate the archive time for the current database.
16. On the MARS, click the Admin tab and then the System Maintenance subtab.
17. Click the Data Archiving link.
18. Notice the available options in the archiving protocol are NFS and SFTP. The SFTP
option was recently made available in version 6.0 code. Since a lot of your environments
are already supporting Windows Servers, we will show you how to get NFS working on
these servers so we can start archiving our MARS data.
19. Go to the Security-Srv. Open Windows Explorer and browse to the MARS3.0 CD on the
D: drive. You will find a program called SFU35SEL_EN.exe (again, .exe may not be shown)
which will need to be installed to support the NFS services. Run the program.
Note This is a free program from Microsoft that is supported on Windows 2000 and
Windows 2003 servers. Even though Microsoft allows a Unix Service to be
installed from Add/Remove Windows Components in Windows 2003 to support
NFS, we have found the following install method to be the most stable.
20. Enter the folder name C:\Documents and Settings\All Users\Desktop\NFS where the
program files should be extracted in the Unzip to folder field, and click Unzip.
21. Click OK when the files are done unzipping, and then close the winzip window.
22. Open the folder where you extracted the files, and double-click SfuSetup.msi
23. Click Next to continue.
24. The Customer Information panel appears. Leave the default values for the User name and
Organization fields, and click Next.
25. The License and Support Information panel appears. Select the I accept the agreement
option, and click Next.
26. Select the Custom Installation option, and click Next.
27. Make no modification to the Component list and click the Next button when the options
of installed components appear.
28. The Security Settings panel appears. Verify that the Change the default behavior to case
sensitive check box is not selected, and then click Next
29. The User Name Mapping panel appears. Verify that the Local User Name Mapping
Server and Network Information Service (NIS) options are selected, and then click
Next.
30. A second User Name Mapping panel appears. Pull down and select GKL in the Windows
Domain Name and click the Next button. This is the location where the user database is
stored for authentication to NFS.
31. Click the Next button for the default installation location of C:\SFU.
32. At the end of the installation process, click the Finish button.
33. Reboot and log back into the Security-Srv. The credentials used are administrator with
the password cisco.
34. Open Windows Explorer. We want to create a new folder on the C:\ drive called
MARS_Archive. Right click on the C: drive to create the new folder.
35. Right click the newly created folder and choose properties, then click on the NFS
Sharing tab.
36. Select the Share this Folder option, and leave the share name at the default
MARS_Archive.
37. Select the Allow Anonymous Access checkbox.
Note This option is required since the Windows Server cannot directly authenticate
the MARS box and a warning to you. This means the only restriction we can
place on this critical data folder is the source IP of the device accessing the
folder since we cannot handle the authentication at the user level (which is a
MARS restriction).
38. Click the permissions button. Select ALL MACHINES under Name, and then select No
Access from the Type of Access list.
40. In the bottom ip address field provided enter, 10.10.2.100 (the MARS appliance) and
click the OK button. This allows only the MARS to write to this NFS share.
41. Select the IP address of the MARS Appliance, then select Read-Write from the Type of
Access list. Ensure that ANSI is selected from the Encoding list.
42. Click OK to save your changes and close the NFS Share Permissions dialog box.
44. Click the Security tab. Add the Anonymous user to the list by clicking the add button.
45. In the object names section, enter Anonymous Logon and click the OK button.
46. With the Anonymous Logon user selected in the top section, click the Full Control rights
in the bottom section of the form and click the OK button.
47. Return to MARS on the Admin-PC.
48. Under the Data Archiving page of the MARS enter the following parameters:
Remote Host IP: 10.10.2.10
Remote Path: /MARS_Archive
Archiving Protocol: NFS
Remote Storage Capacity (days of storage: 7 years): 2555 days
49. Click the Start button. You can review the status of the backup by clicking the More
Info link.
50. Click the Activate button that is now Red. Remember that the data being archived starts
the second you pressed the start button moving forward. Older dynamic data say from 5
minutes ago will not be stored which is crucial reason for getting the archiving setup as
part of the deployment process.
51. Go to the Security-Srv and view the contents of the C:\MARS_Archive folder. You will
notice folders being created as the system begins the write process. Open one of the
folders and review the files currently stored. You will notice a file beginning with the
name CF. The following is a breakdown of the directories listed in the archive (it will
take some time for other directories to appear based on the data being archived, see the
table at the beginning of this section):
04/30/2008 04:49p <DIR> .
04/30/2008 04:49p <DIR> ..
04/30/2008 04:49p <DIR> CF <-- Configuration Data
04/30/2008 05:00p <DIR> IN <-- Incident Data
04/30/2008 05:16p <DIR> AL <-- Audit Logs
04/30/2008 05:16p <DIR> ST <-- Statistics Data
04/30/2008 05:16p <DIR> RR <-- Report Results
04/30/2008 05:49p <DIR> ES <-- Raw Event Data
0 File(s) 0 bytes
Command Line Options
52. Lets explore some maintenance commands on the MARS. Go to the Access-PC and log
into the console of the MARS. (Remember that the login is pnadmin with a password of
pnadmin)
53. Type the new command pnexp. You should now be in a new mode with the following
prompt.
pnexp>
54. Since we are nearing the end of the course, lets view a summary of rules and reporting
devices. Enter the config command and press the enter key. The output should be similar
to the output below.
55. Lets see some general statistics on the database. Enter the data command and press the
enter key.
56. The list displayed shows the total number of events coming into MARS. These are the
raw syslog messages coming from your network devices. The incident however is
significantly less, indicating the Data Consolidation feature boasted by developers.
57. Type the exit command to exit the PNEXP mode.
58. Enter the diskusage command. This command displays our current activity on the MARS
hard drive.
For all MARS Appliance models, the Oracle database has three partitions:
/u01: Stores the Oracle binary files.
/u02: Stores the data files.
/u03: Stores the replay log files, which are cached, in-memory working files not yet
committed to the data store.
The size of the data partition (/u02) varies based on the model:
MARS 20: 74 GB
MARS 50: 148 GB
MARS 100: 565 GB
MARS 110: 1.5 TB
MARS 200: 795 GB
MARS 210: 2.0 TB
59. Also notice the 10.10.2.10:/MARS_Archive mount. Its really nice to have the
information displayed indicating the actual hard drive space on the Security-Srv
available.
60. Lets view the current database usage. Enter the pndbusage command from command
line. You should see that there is plenty of available space currently on your system and
that there are current partitions that are empty. Remember from earlier discussions that
partitions will overwrite once they start reaching 75% capacity which is the reason why
archiving is so important. When we reach the 75% which we are estimating to be in 2011,
we will overwrite the partition before writing to it, erasing any dynamic data stored.
61. There is another command that has recently been introduced. If you issue the ?
command to get command line help you will notice the passwd command. CS-MARS
versions 4.1.3 and later provide the command passwd expert, which allows users to
modify a portion of the root password providing additional security. The selected user
password is combined with a Cisco controlled component to form a new root password.
After performing this step, neither Cisco personnel nor the user can access the root
account without knowledge of both components used to create the root password. When
authorized Cisco development engineers need access to the root account for advanced
debugging, both Cisco and the user will need to enter their portion of the configured root
password to enable access. It is important in your environment to execute the passwd
expert command to change the default value. Keep in mind, changing the password will
not allow you to access the root account, you would still need the other half of the
password that TAC possesses. Change the password of the expert account by executing
the passwd expert command. Enter cisco123 as the new password.
62. Another useful command is the show inventory command, similar to the routers and
switches. This command will display the serial number of the appliance in certain
situations you do not have physical access to read the label off the box.
63. Lets run a manual backup of the MARS appliance. Type the pnexp command again.
Enter the following command to force a manual backup of configuration data and
reported traffic/incidents/events.
export all 10.10.2.10:/MARS_Archive
Type carefully here, pnexp is not forgiving of backspaces.
enter yes to the two confirmations
64. Enter the log recent command to review any status/error messages displayed. This
command displays a live backend log for troubleshooting. After a few minutes you will
see an indication in the status window that the archive has finished as indicated below.
65. Once the data export is complete, type Ctrl+C to exit log view
66. Type exit to leave pnexp mode and then issue the pnstatus command. You will notice
that all the services are stopped. When you perform a manual archive the processes are
stopped to snapshot the database, unfortunately they are not restarted. Please issue the
reboot command at the MARS console. This is necessary because the output in step 57
indicates the MARS services have stopped.
RADIUS Integration
Another newer feature was added in 4.3.1. We can now use RADIUS to authenticate our users
to the MARS appliance. The Cisco ACS Server can be used as the authenticating server or we
can choose to use Microsofts IAS software that ships for free on one of our Windows Server. In
this section we will configure the ACS to authenticate user access. Cisco does not yet support
Tacacs+ for authentication, just RADIUS. Also, MARS currently uses AAA for Authentication,
but not Authorization. You will see that all users who access MARS still need to be in the
MARS local database in order to authorize their access as Admin, Security Analyst or Operator.
67. On the MARS appliance, go to the Admin tab and click the System Setup subtab.
68. Click the Authentication Configuration link.
69. In the AAA Server Configuration section in the middle of the screen, click the Add
button.
70. In the Device Type section select Add AAA Server on new host.
71. Enter the following information in the fields provided:
Device Name: Radius-Srv
Access IP: 10.10.2.10
Reporting IP: 10.10.2.10
OS: Windows
NetBios Name: Radius-Srv
72. For the Eth0 IP address at the bottom of the screen enter 10.10.2.10 with a mask of
255.255.255.0.
73. Click the Next button. Click OK to any popups that appear.
74. The next screen is the Report Application section for the host. Click the Add button to
add a Generic AAA Server.
75. In the AAA Server Configuration window, enter the following parameters and click the
Submit button once completed:
Name: Radius-Srv
Shared Secret: cisco123
Re-Enter Shared Secret: cisco123
Authentication Port: 1645
Accounting Port: 1646
76. Go to the Security-Srv and launch the ACS-Admin link from the desktop.
77. Click on the Network Configuration button on the left of the page.
78. In the top section of the page click the Add Entry button to define MARS as a new
appliance requesting authentication.
79. For the AAA Client Hostname, enter MARS.
80. For the AAA Client IP Address, enter 10.10.2.100.
81. For the Shared Secret, enter cisco123.
82. Scroll down and in the Authenticate Using selection, choose RADIUS (IETF).
83. Choose Submit + Apply at the bottom of the page.
84. Go back to the MARS interface on the Admin-PC.
85. You should still be at the Authentication Page. Select AAA Server in the top section and
for the Primary server select the Radius-Srv.
Note Selecting the AAA option will clear any existing user passwords on the MARS
except for the PNADMIN account.
86. At the bottom of the screen, change the Maximum Lockout Policy from the default
value of 5 to be 3.
88. A warning message should appear. Click the submit button after reading.
89. Click the Activate button and close the window that pops up.
90. Lets test the lockout feature by logging out of MARS by clicking the logout button at
the top of the page.
91. Go to the Access-PC and make sure you are logged in to the MARS console using the
username pnadmin password pnadmin. Doing this will ensure that you dont lock
yourself out completely when completing the next step.
92. Log back into the MARS GUI with the PNADMIN account but an incorrect password.
Do this for 2 more attempts to hit the 3 attempt threshold we just set.
93. Now try logging into the MARS with the correct password for the PNADMIN account.
You should see that you are completely locked out now.
94. Go to the console of the MARS and enter the new unlock a command to unlock all
users.
95. Try to log back into the MARS GUI with the username pnadmin and the correct
password. You should now be allowed back into the system. Browse to the Summary
page. You should see an incident created indicating the pnadmin account was locked
out.
Note Recall from lab 14 we created a Cisco Secure ACS user called acs with a
password of test. Understand that you will NOT be able to log into the MARS
using this account yet. The engineers at Cisco decided that although
authentication would be done on the RADIUS server, authorization would be
performed locally on the MARS. That means you MUST create the user in the
MARS user database as well as in the RADIUS user database in order to allow
the user to log into the MARS. This was their method of dealing with not
allowing just any user in the RADIUS server (and in turn, Active Directory)
from logging into the MARS. Cisco will be refining this in future releases.
96. Go to the Management tab, and then the User Management subtab.
97. Click the Add button to create a new user.
98. In the Role drop down box, select the Admin role.
99. In the Login field, enter acs.
100. In the First Name field, enter MARS.
101. In the Last Name field, enter Test Account.
102. Click the Submit button at the bottom of the page. You should now have the following
two users listed in the MARS.
Note Did you notice that there was no password field present when creating a user?
The AAA configuration removed all local password access except for the
PNADMIN account.
103. You should now be able to logout of the MARS and log back in with the username acs
and password test.
104. One of the last features we will explore this week is the Automatic Activation
Interval. This is a feature not enabled by default that allows the MARS to
automatically activate the configuration without you having to remember to press the
Activation button. On the MARS, go to Admin > System Parameters > Activation
Settings. Set the interval to 15 minutes and press Submit.
LAB Complete

MARSv3 - L5731C 002 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MARSv3 - L5731C 002 1

Transféré par

Droits d'auteur :

Formats disponibles

Cisco Security

Vous aimerez peut-être aussi