Thursday, May 31, 2007

NetPro Implementing CS - MARS Appliances

Look out for an upcoming Networking Professionals Connection, Ask the Expert on Cisco MARS.

This starts 4th June 2007, with Jazib Frahim

Quote from Cisco.com
"Mr. Frahim is currently working as a senior network security engineer in the Worldwide Security Services Practice of Cisco's Advanced Services for Network Security. He is responsible for guiding customers in the design and implementation of their networks with a focus in network security. Mr. Frahim holds two CCIEs, one in routing and switching and the other in security. He has written numerous Cisco online technical documents and has presented at Networkers on multiple occasions. He recently authored a book "Cisco ASA, all-in-one firewall, IPS and VPN appliance"

Wednesday, May 23, 2007

New Generation 2 MARS Appliances

Well you may of heard rumours of a range of new MARS appliances, and yep they are now orderable, and soon be available!


Gen2 Part Codes

CS-MARS-110R-K9
CS-MARS-110-K9
CS-MARS-210-K9
CS-MARS-GC2-K9
CSMARS-110-LIC-K9=

All the new MARS G2 appliances are 2U in form factor, have dual-PSU and have fewer disk drives, which offers an increase in overall reliability

The Cisco Security MARS Gen2 Appliances are available for the moment in 4 different models.

These are the 110R, the 110, 210 and a new Global Controller GC2.



These appliances are what is termed the next-generation appliances. See the specs below..


They will deliver upto 2x the storage and 1.5x the performance of the old generation 1 appliances.

These new appliances will run the v5 track of software, which offers many new enhancements.

New Gen2 Software Enhancements

A new Enhanced pnrestore options to restore data in time slices
New Support for raw messages greater than 500 bytes
A New keyword search process
Super New IP log enhancements for viewing IPS IP packets
A licensing upgrade will be available for customers on 110R to upgrade to the 110 platform.

More Info? Contact your local Cisco sales rep.

Tuesday, May 22, 2007

Priveon Labs Posts New Cisco Security MARS Series Document


My good friends over at Priveon have published yet another great MARS article, on how create a tripwire mechanism that can help identify and alert on malware and internal malicious network activity.


This is a great document, entitled Network Tripwire - 101, well worth checking out here.

The guys also have a new security blog which covers many securty related products in the Priveon portfolio.

Thursday, May 17, 2007

MARS Events and Incident Severity

I`ve been asked on many occasions, where does MARS decide on what Severity an Incident is?

Well this is down to many factors, i`ll explain more….


When an Incident is created, its classified by one of the three colours above. For the System Firing Rules this cannot be altered.

MARS matches every raw message it receives into an Event Type.

And as can be seen above, many different reporting devices will report this same device event type. So MARS effectively knows that for MARS Event X, different vendors will report IDS/IPS Signature Y, Alert Z and so forth.

Now MARS will also group different Events it understands into Groups, which makes creating Rules a lot easier.

Selecting Management/Event Management gives you the ability to view what Events MARS understands out the box, and what Groups those events belong to.


Now you will find, vendors usually provide an event severity within the syslog, and as can be seen below, for the Particular MARS event: NetBIOS OOB DoS (WinNuke), multiple devices can report this to MARS. But MARS categorizes this event as a High (Red) Severity, but ISS Real Secure categorizes this event as Medium.


Hence when MARS sees this event, irrespective of who reported it, its RED.

So we know how MARS categories the Events, but how do Incidents get their Severity?

Well this is down to the RULE.

Consider the following Incident…

The RULE that fired was the System Rule: Server Attack: Database – Attempt.

This Incident`s Severity is RED.

How was this decided? Well we need to inspect the RULE to discover this.

If we look closely we can see the RULE is built from 3 conditions. Condition 1 FOLLOWED-BY Condition 2, OR Condition 3.

Looking at the Incident data, we can see Offset 3 “fired”.

See a condensed version below…


So for Offset 3, the Event “Microsoft SQL Server Resolution Service Stack Overflow”, is part of the “Penetrate/BufferOverflow/DB” Event Type Group, from “ANY” device, and with a Severity of “ANY”.

Looking at the particular Event, that matched this RULE…


We see that this is a High Severity Event. (RED).

Therefore the Incident Created is RED.

Similarly, as a basic example the custom parser for the XP firewall that I created for the User Group. The Built/Teardown connections were set as severity “Green”.

When the System Rule: Client Exploit: Sysbug Trojan rule was fired, when client traffic on TCP Port 5555 was fired, you can see again, it was Offset 3 that matched the traffic, and the corresponding Event was a Green Event, and therefore the Incident Severity was set as “Green”. Hopefully your IPS sensor would have picked up this trojan, well before then!

So that’s an important factor to take into consideration when configuring Custom Parsers for your Events.


Now not all RULES are configured to match on ANY Severity. Some rules are more tightly configured, as to what Events to fire on.

Consider the RULE below…


This particular rule for Resource Issue: Network Device, only looks for RED or YELLOW severity Events reported by Devices.

Now what happens when a rule has multiple conditions, like the one below Password Attack: SNMP – Success Likely?


There are basically 4 Offsets, with a match on 1 FOLLOWED-BY 2, OR 3 FOLLOWED-BY 4.

Now what if the Event Severity of Offset 1 is Green, and the Event Severity of Offset 2 is Yellow?

MARS will basically create the Incident as “YELLOW”, as this is the “Highest” Event Severity.

Also important to note that if the reporting device attached no severity to the Event, then MARS will classify that as “GREEN”.

Similarly, if an Incident has correlated multiple reporting devices, with multiple Event types matched, then again the most “Severe” is selected for the Incident Severity.

As a further note, you can select the Severity when working with CASES.

I hope this gives you a better understanding of the severity of Incidents.

Wednesday, May 16, 2007

Windows Event Auditing

Just a quick post to mention a spreadsheet i`ve put together, for some up coming articles on Windows Event Auditing with MARS.



In this spreadsheet which i hope to release to the user group first, and then Blog, i`ve expanded the knowledge of what MARS knows about certain Windows events, and correlated this with example Alerts and Microsoft explanations/NTLM error codes and Logon Types.

Tuesday, May 15, 2007

Network Response Blog

Just a quick note regarding a new Blog i`ve set up called Network Response



I simply dont have the time to do separate blogs for all the Cisco products i work with, so i`ve decided to create this blog, to covers all the other Cisco Security Technologies, and how they can work together.

As always if you have an ideas or want to write a guest article get in touch.

Friday, May 11, 2007

Troubleshooting Checkpoint Reporting Devices

I`ve configured Checkpoint with MARS lots of times and never encountered a problem.

But on an install a few weeks ago, it just wouldn`t play ball.

I`m not going to go into detail on how to configure Checkpoint with MARS, as thats all in the documentation. In this article i`m going to give you a few hints and tips on what to look for if things dont go to plan!

Check Point components uses Secure Internal Communications (SIC) to securely communicate with each other and with third-party OPSEC applications. SIC is the process by which MARS Appliance authenticates to the SmartCenter Server and other Check Point components.

SIC uses a shared secret as the seed for negotiating session keys. This shared secret is referred to as an activation key. The authentication and communication setup works as follows:

1. Using a username and password pair, MARS authenticates to the SmartCenter Server and other Check Point components, such as remote log servers. (TCP port 18210 is used for pulling certificate from the Certificate Authority for OPSEC Secured communication)

2. If authenticated, the peers swap the activation key and each other’s SIC (TCP port 18190 /OPSEC-CPMI is used for discovery)

3. If each peer validates the authenticity of the other, the Check Point component establishes an encrypted session over TCP port 18184 with the MARS Appliance. It is over this channel that the Check Point components to sends encrypted log data to MARS. (TCP port 18184 / OPSEC-LEA is used for pulling logs)

Unless these are altered MARS requires access to these ports to the appropriate network device.

Errors associated with initially pulling the Certificate.......


If we enter a Wrong Activation Key, this will produce the following error...

If the Client SIC Name is typed incorrectly (or wrong IP address), will result in the following error....


Errors associated with Discovery.............


Incorrect Access Credentials, or incorrect Client or Server SIC will result in...


Things to Check....


Never try to type in the Client and Server SIC name to the MARS UI. Its very error prone. Use copy/paste from the CheckPoint Management UI if possible.

Always use the CS-MARS CLI’s telnet command to test the connectivity between the CS-MARS and CheckPoint Management/Log Server for all three ports.


Discovery using CPMI
telnet management_server_ip 18190

Pulling the Certificate
telnet management_server_ip 18210

If the management server is also the log server
telnet management_server_ip 18184

To pull logs via LEA
telnet logserver_ip 18184


Use PNLOG
To set the logging level or to view log information at the console, use the pnlog command. This command specifies the logging level of the MARS services, as well as the CheckPoint CPMI and LEA logs received by the MARS Appliance.

The pnlog setlevel cpdebug command sets the output level of the CheckPoint discovery process. You must specify one of three levels: 0, 3, or 9, where 0 disables Check Point debug logging, 3 enables all OPSEC debug logs, and 9 enables all CPMI debug logs.

This command is used together with pnlog show cpdebug command to study the raw output of CheckPoint Discovery (CPMI) and CheckPoint Log (LEA) sessions. Cisco recommends the use of 9 for debugging and 0 when not actively debugging.

ie, To debug OPSEC and pulling the certificate use

[pnadmin]$ pnlog setlevel cpdebug 3

[pnadmin]$ pnlog show cpdebug
[ 14839]@pnmars ckpSSL_InputPending 1 pending bytes
[ 14839]@pnmars ckpSSL_do_read: read 12 bytes

ie, To debug CPMI Checkpoint Discovery use

[pnadmin]$ pnlog setlevel cpdebug 9
[ 15590]@pnmars openssl_lock:ssl_ctx :3076:ssl_sess.c:636

ie, To switch off cpdebug logging

[pnadmin]$ pnlog setlevel cpdebug 0


Other CLI Tools to check for incoming traffic - NETSTAT

The netstat command should display two connections per log server.


[pnadmin]$ netstat -an
tcp 0 0 192.168.8.2:33312 192.168.8.110:18184 ESTABLISHED
tcp 0 0 192.168.8.2:33315 192.168.8.110:18184 ESTABLISHED

Other CLI Tools to check for incoming traffic - TCPDUMP

For Discovery troubleshooting.... (success shown)

[pnadmin]$ tcpdump port 18190
tcpdump: listening on eth0
16:09:03.125529 pnmars.33358 > 192.168.8.110.18190: S 2762771428:2762771428(0) win 5840 (DF)
16:09:03.126988 192.168.8.110.18190 > pnmars.33358: S 679413508:679413508(0) ack 2762771429 win 16384

For troubleshooting Logs being received.... (success shown)

[pnadmin]$ tcpdump port 18184
tcpdump: listening on eth0
16:05:50.650056 192.168.8.110.18184 > pnmars.33312: P 2051260988:2051261993(1005) ack 2397731114 win 16384
16:05:50.650197 pnmars.33312 > 192.168.8.110.18184: . ack 1005 win 32520 (DF)


If all else fails!, make a call with Cisco TAC. :-)

Saturday, May 05, 2007

New Cisco NAC Appliance Blog

There is a new Cisco NAC Appliance Blog over a cisconac.blogspot.com

This is run by Jamie R. Sanbower, CCIE #13637 R&S/Security, who has lots of experience i with large Cisco NAC Appliance Projects, working for a Cisco Gold Partner.

Good luck with the Blog Jamie, i`m sure it will be an interesting read.

Wednesday, May 02, 2007

CS-MARS 4.2.6 Released

MARS 4.2.6 was released yesterday.

Release notes are here



This release is a big update to 3rd-party vulnerability assessment signature sets.

This release also includes many new vendor signatures, updating the 3rd-party signature support.

Further Note on Reporting

Further to yesterdays Real Time Query restrictions, i thought i`d better set the record straight on the other reporting options.

The Scheduled reports functions (every hour, day etc, etc) have no such limitatations, and are very efficient.

Reports that are run on demand, (ie Now, and Batch Queries) are limited to 2 running at the same time, no matter what model of MARS is in use.