Monday, March 9, 2009

Fortinet and Cisco MARS Integration - Part II

If you haven't already please read Part I of the Fortinet with Cisco MARS integration. This post talks about configuring additional custom parsers for MARS as well as using the Keyword field in MARS for freeform syslog text matching. In the following example I will describe how to detect administrative login failures for SSH and HTTPS access to a Fortigate unit.

In your MARS Global Controller or standalone Local Controller perform the following steps:

  • Click Admin -> Custom Setup (tab at the top) -> User Defined Log Parser Templates
  • Under Vendor select Fortinet and click Edit, then click Next
  • Add a new Device Event ID by clicking Add and Add again on the next screen
  • Fill out the following fields: Event ID=Event Log, Description=Event Log, Severity=Green
  • In the Event Type Group section select Info/Misc from the right hand side and click on the Add button with the double left arrow. Then click Submit.
  • On the next page in the Choose Event Type From section select the newly created Event Log's radio button and click the double arrow to the left. At the top of the page enter Event Log in the Device Event ID and Description fields. Then click Apply on the bottom right of the page.
  • The Patterns link at the top of the page now becomes available, click there and add the following patterns:

  1. Position= 1, Key pattern: date\=, Parsed Field=Device Time, Value Type=Time, Pattern Name=%Y-%m-%d time=%H:%M:%S, Value Format=%Y-%m-%d time=%H:%M:%S, Value Pattern=\d{4}-\d{1,2}-\d{1,2} time=\d{1,2}:\d{1,2}:\d{1,2}
  2. Position=2, Key pattern=.+user\=\", Parsed Field=Reported user, Value Type=String, Pattern Name=STRING_WORD_QUOTES, Value Pattern=\w+
  3. Position=3, Key pattern=.+ui\=, Parsed Field=Workstation Name, Value Type=String, Pattern Name=STRING_SERVICE_IP (enter this in the Or enter new field), Value Pattern=\S+ (notice that the S must be capitalized)
  • When you are done defining the three patterns click Submit on the Patterns for Device ID: Event Log page, the Done on the next page.
  • Now click on the Rules tab at the top of the page and click Add to add a new rule. Give the rule a descriptive name and description and click Next
  • Define applicable zones or leave blank to apply this rule to all zones. Click Next
  • Set Source IP, Destination IP, Service Name, Event, Device and Reported User to Any
  • Leave the IPS Risk and Threat rating at default and click Next
  • Set Keyword to action=login status=failed and click Next
  • Leave Severity at Any and for Counts enter the amount of failed logins the firewall must report before triggering the rule, for example 5.
  • Click Yes on the next page to finish defining the rule conditions
  • Select the appropriate action to perform when the rule is triggered
  • Set the time range to 10 minutes or another appropriate value. This will trigger the rule if any firewall reports 5 failed login attempts within a 10 minute period for example
  • On the Rule Summary page click Submit
  • Activate the changes

To enhance security you can add additional conditions to the rule, such as adding another statement looking for action=login status=failed in the keyword section. This rule would trigger on attempts to log into the firewall which fail followed by a successful login. This could indicate a successfull brute password attack.


2 comments:

Steve said...

above you indicate:

"To enhance security you can add additional conditions to the rule, such as adding another statement looking for action=login status=failed in the keyword section. This rule would trigger on attempts to log into the firewall which fail followed by a successful login. This could indicate a successfull brute password attack."

Wouldn't you put in status=succeded?

Sebastian said...

The rule should look for login=failed, followed by a login=succeeded from the same source IP over a certain period of time. That way you can alert on someone entering an incorrect password followed by a correct password which could indicate a brute force attack.

On another note you should obviously lock down SSH access to the firewall to begin with where possible/practical.