Change Your Thoughts And You Change Your World !

Configuring SSH login mail alert on checkpoint secureplatform..

http://firewalltips.blogspot.com/2010/05/configuring-ssh-login-mail-alert-on.html

How add / change interface IP on Nokia IP useing clish / CLI??

Below shows you the commands required to change the IP address of an interface within clish on a IPSO Nokia gateway,

1.add interface eth1c0 address IP [NEW IP]/[NETMASK]

2.delete interface eth1c0 address [OLD IP]

3.set interface eth1 speed 100M duplex full active on

4.set interface eth1c0 enable

Below gives you an example :

1.nokia-firewall[admin]# clish

2.NokiaIP390:102>add interface eth1c0 address IP 192.168.1.1/24

3.NokiaIP390:102>delete interface eth1c0 address 172.16.1.1

4.NokiaIP390:102>set interface eth1 speed 100M duplex full active on

5.NokiaIP390:102>set interface eth1c0 enable

F5 LTM VE – Node Monitors

A node is the actual physical server. So in this case, a node would be WebHost1, 2, or 3. Members are a specific service on a node. As we saw when we added pool resources we specified an IP address (the node) and the port (node + port = member (in most cases)). That being said, we never actually defined any nodes. Let’s take a look at what it did for us. Click on ‘Nodes’ under the ‘Local Traffic’ menu on the left. You should see something like…

So the LTM created nodes for us. These could be left as is, but I’m going to open each one and change the name so its more descriptive. You’ll notice that while you are in the node settings changing the name that there is an option for a health monitor. The default should be set to ‘Node Default’ as shown below…

Back on the main ‘Node’ screen you’ll see at the top an option for ‘Default Monitor’. You should have also noticed that the nodes are showing availability as ‘unknown’. This is because we are telling the node to check its availability using the ‘Node Default’ but we haven’t defined that yet. My host are available via ICMP, so I’ll configure that as my node default monitor.

Click ‘update’ and then click ‘Node List’ to go back to the main ‘Node’ window. It should now look like this…

Note the updated names as well as that they all show as green indicating that they are available. So now we have health checking enabled on both the member as well as the node itself. If a node goes offline, all of its members will fail the health check and be removed from the pool. We’ll wrap up this section with a quick test of that. I’m going to reboot WebHost1 and we are going to verify that traffic headed for the VIP doesn’t balance to the down server.

The instant the server stops responding to pings I can see that the pool member shows as down.

Additionally we can see that the node itself is marked as down…

A quick check of the VIP shows a pattern of…

This showing of course that WebHost1 is no longer in the pool. The instant it comes back online both monitors will show as green and it will be back as part of the pool.

In the next few posts I’m going to jump into some more of the more interesting pieces of the LTM config including load balancing methods, persistence, and hopefully I can get to iRules soon.

F5 LTM VE – Setting up basic load balancing

In this post we are going to go through setting up basic load balancing. On the LTMs this is a relatively easy task so I’m going to rip right through it. The nice thing about the configuration is that instead of starting from the bottom up, you can actually start from the top down. So rather than creating all of your nodes, then creating the members, and then the pool, we can just start with the virtual server and add the other objects. Best shown by example, so here we go..

Log in to your VE LTM and blow up ‘Local Traffic’ on the left menu bar. Select the ‘’Pool’ option and on the far right select the ‘Create’ button.

On the next screen, give the pool a name, select ‘http’ for the health monitor, and then move down to the resources area. Enter the information for each of your web hosts into the ‘New Members’ area. Enter 1’s info, then hit add, etc. until all of them are listed in the text box as shown below…

Then click ‘Finished’ to create the pool. You should now see your pool created and it should have a pretty green circle next to the name indicating that the monitors are succeeding in querying the device on port 80.

Now that the pool is created, we need to create a virtual server to associate it with. Select ‘Virtual Servers’ from the ‘Local Traffic’ menu on the left hand side of the screen. Then click the ‘Create’ button on the far right of the window.

There are lots of options on the next screen but just concern yourself with the ‘General Properties’ window. The ‘Destination’ field is the IP of the VIP that clients will connect to in order to be load balanced. Fill in your relevant information as shown below…

Then scroll to the bottom and click ‘Finished’ to create the virtual server. Once the server is created, it will take you back to the main virtual server window. Click the ‘Edit’ link on the far right of the virtual server description under resources…

Under ‘Default Pool’ select your newly created pool and then click ‘Update’

At this point we are ready to test. Open up a web browser and point it to the VIP. http://10.20.20.21 and see what you get. Hopefully, you’ll get nothing. Why do you ask? Because the web servers are returning traffic to our default gateways, not the LTM. Open up the virtual server settings and change the ‘SNAT Pool’ setting from ‘None’ to ‘Automap’. Automap tells the LTM to change the source to one of its self IPs in that subnet. In this case, it would source the packets from the 192.168.1.40 address.

Once the SNAT pool is specified, try hitting the VIP again and see what happens. With any luck you should get one of the web servers. Three refreshes and you should see all of the web servers get hit as shown below…

So that is all it takes to setup a very simple load balancing configuration. Not hard right? In the next post, we’ll go back through and talk a little bit more about what we just set up as well as look at monitors.

F5 LTM VE – Configuring Persistence

One of the main problems with load balancing is persistence. Some web applications require that the external user return to the same web server each time, or at least each time within a given window of time. That being said, there needs to be a mechanism in which we can determine if the external user has connected before, and if so, to what server he was balanced to.

Persistence is a configuration option of the virtual server. There are two settings for persistence. The first being the default persistence profile. Default persistence is the main persistence mode used for the virtual server. The second option, fallback persistence, is used when the first method of persistence fails. For example, if the default persistence is set to ‘cookie’ but the client isn’t accepting cookies, you could fallback to source persistence. There are 8 different persistence profiles, let’s walk through them one at a time with some examples along the way.

Source Address Persistence
This is a pretty common type of persistence. The LTM tracks the source of the incoming packet and redirects any connections coming from that IP to the same pool member. When this is configured on our test virtual server we see a return like this…

Destination address Persistence
Persistence based on the destination address is much like source address persistence. Except that the F5 examines the destination of the packet rather than the source. Now, you might ask yourself, when would this actually be useful? Think of a setup where an LTM is load balancing a set of proxy servers that are doing caching. Clients would be forced through the proxies to the external site (read destination) and the proxy would cache that site. Going forward, it would make sense to balance clients going to the same destination to the same proxy since that particular proxy already has the website cached.

Cookie Persistence
Cookie persistence is another common load balancing type. Cookie persistence requires that a HTTP profile be associated with the virtual server. We’ll talk more about profiles in another blog entry. When using cookies the F5 will examine the incoming request and determine if the appropriate cookie is part of the request. If it is, the F5 will balance the client to the same member based on the cookie. There are 4 different methods of cookie persistence. These can be set under the cookie persistence profile…

The default method is ‘Cookie Insert’. In this mode the F5 writes a cookie called ‘BIGIPServer’ into the response from the web server as it passes through the F5 on its return path to the client. This method require no additional configuration on the web servers.

In ‘Cookie Passive’ mode the web servers must control the insert and updates of the BIGIPServer cookie. The F5 only looks at the Cookie to determine which server the request should go to.

In ‘Cookie Rewrite’ mode the web server must send a cookie formatted in a particular order to the F5. The F5 will then rewrites the cookie to the BIGIPServer cookie, updates it with the member information, and sends it back to the client.

In the last mode ‘Cookie Hash’ the LTM examines the cookie inserted by the web server on a previous connection and makes a load balancing decsion based on the hash in the cookie. While the LTM is still making the load balancing decision, its making it based off of the cookie set by the web server. This effectively moves the brains of the load balancing decision to the web server(s) that calculate the hash to insert into the original cookie.

To see the cookie on the client, you’ll need to change the cookie persistence profile from ‘Session Cookie’ to an set expiration cookie. Session cookies are only good for that particular session and are stored in memory so they are never written to disk. The expiration date of the cookie is updated each time the client hits the F5 so its sort of a rolling expiration. At any rate, set it for at least an hour, and then hit the VIP with your browser. I used a app called ‘IECookiesView’ to read the cookie…

Hard to see there, but the cookie is on the system at this point.

Hash Persistence
By now you should be seeing that things including the hash function on the F5 are the more advanced custom like features. I’ve never used this but I imagine you could use an iRule to examine the hash and make decision based on that.

Microsoft Remote Desktop (msrdp)
Tracks sessions between the RDP server and client

SIP (sip_info)
Persistence based on servers that receive and process SIP traffic

SSL
Keeps track of the sessions using the SSL Session ID

Universal
Allows for persistence based on custom expressions that you can write yourself.

Well that covers all of the different types. You can probably tell that I went into greater detail on some of the more common ones. The last few I at least haven’t dealt much with, so I don’t have a ton of info on yet. If and when I get more info, I’ll update the post.

F5 LTM VE – Configuring iRules

iRules are perhaps one of the coolest features of the F5 devices. They allow you to write rules that can manipulate the load load balancing decision. The rules can evaluate variables that the F5 can detect. In this entry, we are going to examine the user-agent string which is part of the HTTP header. Based on the use-agent field, we can determine what type of browser the client is connecting with. Looking at this information can also help us determine what kind of device the client is connection from.

First off, I wanted to add another pool to my LTM. Rather than spin up new VMs for this purposes I told apache on each WebHost instance to listen on port 81 and direct requests incoming on that port to a different folder. So I added this to my httpd.conf on each WebHost…

Listen 81

ServerName localhost
DocumentRoot /var/www/html/81

Then I put a modified copy of my index.html file in the 81 folder on each WebHost. Then I created a new pool that looked like…

Now that that’s done we can write our iRule. iRules are pretty easy to understand just by looking at them but on the other hand, rather picky about syntax, spacing, etc. So lets take a look at the iRule we are going to use in this test. I wanted to create a iRule that would send requests coming from a iPhone to the new HTTP_MOBILE_POOL (the port 81 group we just created) and send the rest to the default HTTP_POOL. So I came up with…

So as I said earlier, this is pretty easy to read. If I detect “iPhone” in the user-agent filed, I’ll send the request to the mobile pool. If I don’t, send it to the regular HTTP pool.

Now that we wrote the rule we have to apply it to the virtual server. Open your virtual server and click on the ‘Resources’ tab. Since this iRule is setting the pool for us and we have a ‘else’ statement, I’m going to set the default pool to none. Then set the iRule accordingly…

That’s it, give it a test! From out desktop we see the normal page…

And from the iPhone we see…

Not very inventive of me but you get the point.

So as you can see iRules are very powerful. I hope to write some more soon and post them up as templates and examples but for now I just wanted to let you see how powerful they can be.

iRules Editor – much easier…

So I’m quickly falling in love with F5 and iRules, but writing them was sort of a pain. I wasn’t good at catching typos and syntax errors on the fly and pasting the code into the LTM, saving it, and it kicking back some cryptic error message about your typos was a little maddening. So I thought I’d do some googling and check out what I found…

The F5 iRule Editor! (Click here for site)

How awesome is this! Once installed the app connects to your LTM in one easy step…

After connecting to the LTM it loads all your current iRules for editing and allows you to create new ones through it editor and upload them to the LTM. I literally just installed the app, but my favorite part at this moment is the fact that the editor is what I call ‘command context aware’. Check this out..

All I Did was type ‘HTTP::’ and the context menu came up with all of the options I can use on the HTTP object. Awesome!

Well I’m sure there will be more to come on this as I explore but I thought I’d share right away. More to come soon!

F5 LTM VE–Setting up basic load balancing (CLI!)

So since I’m such a huge CLI guy I thought that I’d go back through my previous F5 LTM VE posts and do it all through the CLI. To be honest, Im brushing up on the topic so that I can someday sit the F5 exams. Not sure when that will be but I’m hoping soon. So, I deployed the OVA template into VMWare again and I’m going to do the full setup again. Not as much explanation this time but I’ll walk through it.

Management IP
Boot the VM up, log in with default credentials, launch the config wizard, setup your management IP.

License
Fire up a SSH connection to the management IP you configured. At the command prompt enter the following command…

get_dossier –b

This will kick out the dossier file. Copy the dossier, browse over to activate.f5.com, select the activation method you are looking for, and enter your dossier. After accepting the terms you should get a license file kicked back to you that looks something like this…

Copy the entire text contents of the text box and head back to your SSH session. Edit the contents of /config/bigip.license with vi…

vi /config/bigip.license

Its a new file so go into insert mode and past the contents. Write the file and then issue the following command to restart the BigIp processes

bigstart restart

You should notice that your prompt changed from ‘NO LICENSE’ to ‘INOPERATIVE’ after the restart. That’s a good sign.

Hostname
tmsh modify sys global-settings hostname LTM2.interubernet.local

Create VLANs
tmsh create net vlan external interfaces add {1.2}
tmsh create net vlan internal interfaces add {1.1}

Create Self IPS
tmsh create net self 10.20.20.40/24 vlan external
tmsh create net self 192.168.1.40/24 vlan internal

Create HTTP_POOL Pool
tmsh create ltm pool HTTP_POOL load-balancing-mode round-robin members add {192.168.1.41:80 192.168.1.42:80 192.168.1.43:80}

Create HTTP_TEST Virtual Server
tmsh create ltm virtual HTTP_TEST destination 10.20.20.40:80 profiles add {tcp http} pool HTTP_POOL snat automap

Save the config
tmsh save sys config

And that’s it! You should be able to hit 10.20.20.40 and see round robin traffic between the three web servers.

F5 LTM VE – Load balancing methods

So now that we are getting comfortable with the LTM, we should discuss the various types of load balancing methods. The LTM provides for lots of different types as shown below…

F5 breaks them into two groups, static and dynamic. Let’s go through them one at a time and discuss each.

Round Robin (Static)
Its the default load balancing type. Everything we’ve seen up to this point has been round robin. It provides an even distribution between all available pool members.

Ratio (Static)
Ratio mode allows you to define a ratio for each server. This is a good mode to use when servers have varying degrees of processing power. A ratio of…
WebHost1 – 3
WebHost2 – 1
WebHost3 – 1
Would result in the host being directed to WebHost1, WebHost1, WebHost1, Webhost2, WebHost3, Webhost1, Webhost1, Webhost1, Webhost2, etc.

Least Connections (Dynamic)
This mode distributes connections between web servers based on the current connection count between the F5 and the web server. Its not possible for the F5 to know of any other connections coming from other hosts so it only uses its own connection table to determine where to send the next request. So let’s test this one out to see what happens. I’m going to open a http request to one of the web servers. To do this, I’m actually going to download a large file from both of them to keep the sessions open long enough to test. With the file being downloaded we can see that we have a open connection to Webhost1…

Any future requests will take this into account. Browsing to that VIP will point us to the remaining two web servers. Try hitting the VIP and see what happens…

As you can see, we aren’t getting any requests going to Webhost1 at this point.

Fastest
Fastest distributes connections based on the server response time. This would be useful in a situation where previous requests may put varying degrees of a load on a server, hence slowing down future requests.

Least Sessions
Much like least connections but based on the session (F5 calls a persistence record that’s valid a session) count. The member with the least amount of sessions will get the next connection.

Weighted Least Connections
In order to use this method each member must have a defined (not 0) connection limit. The LTM then calculates the member capacity by as a ratio of current connections to the connection limit. The server with the smallest percentage of used capacity gets the next session.

Observed
This is sort of an odd one. The system assigns ratios to the members dynamically. The LTM checks the connection count on each member every second. The average is calculated and members with less than average connection counts get assigned a ratio of 3 and the those with a greater than average connection count get assigned a ratio of 2.

Predictive
Same as observed but uses 4 rather than 3 for less then average and 1 rather then 2 for greater than average.

Dynamic Ratio
A much more complex method of load balancing where particular brands of servers can be configured with special monitors and the load balancing method is based on various calculations of these metrics.

So that’s all of them. I tried to show examples of some but couldn’t show all of them in a lab setup. Next up is persistence. I might talk about profiles before that, not sure yet.

ClusterXL shows Active Attention / Interface Active Check Error

http://www.fir3net.com/Firewalls/Checkpoint/clusterxl-shows-active-attention-interface-active-check.html

Checkpoint FW SPLAT Cluster XL Troubleshooting (NGX Versions)

In this blog, let us see a Step by Step approach that you would take to troubleshoot a Cluster XL problem in Checkpoint.

Normally, this problem comes of after a reboot or an Upgrade or as a result on some change in the underlying network. When troubleshooting the CPHA, the following commands are very helpful

• cphaprob state
• cphaprob list
• cphaprob –a if

The status of the CPHA is shown by the first command. First thing that you need to do is verify basic connectivity between the firewall interfaces. Allow the cluster members to ping each other (if not already allowed by the policy) and ping away, you should be able to verify the basic connectivity in this way.

If the connectivity exists, then find out which firewall has the problem, it will normally be the down firewall

Number Unique Address Assigned Load State
1 (local) 10.0.0.1 100% Active
2 10.0.0.2 0% Down

Here as you can see the second firewall is down, you need to first go ahead and just execute ‘cpstop’ and ‘cpstart’ commands on the box. The CPHA should be back up.

Also execute the command ‘cphaprob –a if’ that should give you the interface status and Cluster Xl status.

If this doesn't work, try pushing the policy from the CMA/SC server and then execute cpstop / cpstart commands. If this doesn’t clear out the problem, reboot the box. 90% of the CPHA problems will be resolved in the above given steps, but if still its not resolved then read on.

The above steps were given with the assumption that the CPHA was working and it stopped working suddenly. If this is the first time you are trying to make it happen or some major policy/network changes broke it, then here is what you need to keep in mind.

• CPHA uses multicast, so make sure the switches you have in the path don’t drop multicast traffic, if you are using Cisco gear, then you might want to configure igmp snoop.
• It also uses the port ‘8116’ in UDP, so make sure that the port is open between the devices. (This is crucial if you have played around with the global properties and implied rules.
• RIB uses port 2010 so make sure that is also open between the firewalls.

After checking that your switches, execute the command, ‘cphaprob list’ and make sure both the sides have the same registration and the states of all of them are OK. If the state shows problem, then you should work in the direction of resolving that problem.

Device Name: FIB
Registration number: 4
Timeout: none
Current state: problem
Time since last report: 9.3 sec

Then you can do the snoop using the ‘fw monitor’ command and make sure the communication between the firewalls is happening.

Use the following command

fw monitor –e ‘accept dport=8116;’

1. You will see the source 0.0.0.0 and the destination as the network ID of the network over port 8116.
2. On port 2010 (change the dport to 2010 in above capture), you should see FIB communicating between the firewalls.

You should also check the /var/log/messages for error messages that can help you troubleshoot this further.

And yes, I forgot to mention, in this case, i was seeing that the FIB on one firewall had switched itself off after the upgrade, so went ahead and switched on advanced routing using ‘cpconfig’ command and all went well.

http://3-4-5-6.blogspot.com/2010/04/checkpoint-fw-splat-cluster-xl.html

Backup DataBase

The best practice to take the backup of the existing Eventlog Analyzer (including data, configurations, settings etc.,) is by copying the following folders, after shutting down the EventLog Analyzer.

\mysql
\server\default\indexes
\archive

In case of any crash of EventLog Analyzer which requires fresh installation, you can restore the above folders to the same location and access the data. Ensure that you stop the application while taking this backup.

if MySQL password is set in the old server, you need the following files from the old server to new server during migration or a fresh install due to crash.

1. startDB.bat and configureODBC.vbs located under \bin directory.

2. myodbc3.dll and myodbc3s.dll located under \lib directory.

3. mysql-ds.xml located under \server\default\deploy directory.

Further, we have created the batch files to start/stop EventLog Analyzer Service (Windows Service) during your automatic backup process.

Kindly download the attachment "Automate.zip" and extract and rename them as "stopELAservice.bat" and "startELAservice.bat" respectively under the "\bin" folder.

By using Windows 'Scheduled Tasks', you can schedule 'stopELAservice.bat' to run at the time when your backup application starts and schedule the 'startELAservice.bat' to run when your backup application stops. By this, you can automate the process.

Note: This batch file applies only when the EventLog Analyzer is running as a Windows service (named " ManageEngine EventLog Analyzer ").

Note: We do have options to export the Report Profiles and Alert Profiles from the UI and kindly make sure that you export those profiles as soon as you add any new report profiles or alert profiles, as another alternative.

Monitoring Authentication Attempts on Cisco Routers with Syslog

One of great things about the syslog logging standard is the capability to collect system notifications from a variety of network hosts and direct them to a central store for analysis. In this demo I will configure a Cisco router to log system messages using syslog to a central Linux server. Specifically I am interested in logging authentication attempts to the router.

My preferred syslog daemon that I will be running on my Linux syslog server is rsyslog. There are also many syslog servers available for Windows if you choose to go that route. Kiwi is one with a nice interface but the full featured version is payware. Your choice of a syslog server to collect your messages should be immaterial to this discussion as the configuration steps should be the same on a Cisco router.

Configure Syslog Server to Accept Messages

To start, we’ll make sure that the syslog server is configured to accept messages from the IP address of your router. This should be the IP of the interface on the router that is closest to the syslog server. For example, suppose the router has an external and an internal interface. Our syslog server is on the same LAN that the internal interface is connected to. The syslog server should be configured to accept messages from the IP address of the internal interface. We also have the option to manually configure the interface the syslog messages are sourced from.

The syslog standard sends log messages identified with a certain facility and severity. Generally the facility is used to identify the message as coming from a particular program or service. This has more use when the source of the syslog messages is a full blown computer server. In the case of Cisco routers by default syslog messages are sent marked as coming from the “local7″ facility, so we need to make sure that the syslog server accepts messages from this facility. The source facility can be changed if you so desire.

In addition, syslog messages have a severity attached which gives information on the priority or urgency of the message. If you are familiar with syslog you know that higher numbers represent lower severity levels. Here is a list of the minimum severity levels that a Cisco router can be configured with which to send messages to the syslog server.

Router(config)#logging trap ?
<0-7>          Logging severity level
alerts         Immediate action needed           (severity=1)
critical       Critical conditions               (severity=2)
debugging      Debugging messages                (severity=7)
emergencies    System is unusable                (severity=0)
errors         Error conditions                  (severity=3)
informational  Informational messages            (severity=6)
notifications  Normal but significant conditions (severity=5)
warnings       Warning conditions                (severity=4)

Configure Cisco Router with Secret Passwords

First let’s enter global config mode.

Router#conf t

Now we need to make sure that we have a secret password set to enter enable mode. I’ll use the “enable secret” command to encrypt the password using the type 5 MD5 hash algorithm which is much more secure than the older type 7 encryption.

Router(config)#enable secret EnablePassword

Now we’ll set up username authentication. This needs to be turned on or our authentication attempts will not be logged. Logging of authentication does not appear to work if you only use passwords set directly on the virtual telnet/ssh terminal lines.

Router(config)#username aaron secret MyPassword

We need to configure our telnet/ssh terminal lines to use local username authentication.

Router(config)#line vty 0 4
Router(config-line)#login local
Router(config-line)#exit

Configure Logging Options

Now we’ll set the router to direct messages to be logged to the IP address or hostname of our syslog server host.

Router(config)#logging 192.168.10.51

We can set the minimum severity level that log messages need to be if they are logged to the syslog server. The minimum level for logging failed authentication attempts is warning (4) and for successful authentications is notifications (5). To capture both I will configure the minimum level to be notifications. Dial this back to warnings and above if there are too many messages being forwarded to your server, but remember that the successful logins will no longer be logged.

Router(config)#logging trap notifications

I’ll choose to activate login checking for both successful and failed login attempts. Specifying “log” will generate the syslog messages. Optionally we can have the router generate a log after a certain number of attempts, but in this case I’ll log them all.

Router(config)#login on-success log
Router(config)#login on-failure log

We also need to set up a quiet mode time period. Logging of failed logins will not work without this. The “login block-for” command will create an ACL for a certain period of time that will as the name suggests block logins after a certain number of failed attempts. In this case logins will be disabled for 120 seconds if there are 3 failed attempts within a 60 second time span. This will also work well for deterring a brute force attack on the router.

Router(config)#login block-for 120 attempts 3 within 60

Optional Logging Parameters

As I mentioned at the beginning by default the syslog messages sent by the router will appear as coming from the interface closest to the syslog server. If you want to change this behavior you can manually specify the interface the messages appear to come from.

Router(config)#logging source-interface FastEthernet0/0

We can also activate a delay which will slow login attempts. In this case there will be a 5 second delay between when a bad username/password combo is entered and when the next login prompt is presented.

Router(config)#login delay 5

That should do it. You can now test a successful or failed login attempt and the messages should show up on the syslog server!

Monitoring Windows 2008 R2 Event Logs with Snare and Syslog

So now that you’ve deployed some brand spankin’ new Windows 2008 R2 servers you probably want to start gathering some information on their condition and monitor their security. Syslog is a very good way to gather the logs from a large number of servers and direct them to a central site for analysis. In this post we’ll make use of the Snare EventLog Agent to collect events from the Windows Event Log service and forward them to a centralized syslog server. Since the events that are logged to the Event Log do not generally conform to the syslog standard some manipulation of the messages may be necessary on your syslog server.

In this example I will be installing the Snare EventLog Agent on an Active Directory domain controller so that I can monitor logon/logoff failure events that occur with my domain user accounts. My central syslog server will be running on a CentOS Linux host using the syslog daemon rsyslog. There are also many syslog servers available for Windows if you choose to go that route. Kiwi is one with a nice interface but the full featured version is payware. Your choice of a syslog server to collect your messages should be immaterial to this discussion as the configuration steps should be the same with the Snare Agent.

First let’s start by installing the Snare Agent software. You’ll want to download the version for Windows Vista and above here. Logon as administrator on your 2008 R2 server and run the install file.

Proceed with the installation and accept the defaults until you get to the “Snare Auditing” screen.

The Snare Auditing screen allows you to give Snare the access necessary to edit the auditing settings on your server to conform to the objectives that you configure with the agent. I’m generally paranoid about anything too automatic (especially on a domain controller) so I’ll select No. This means that I’ll need to manually specify the auditing settings needed so that events are created in the Event Log. Click Next.

If you want to configure higher security you can select one of the “Yes – with password” options for the Snare web configuration interface. By default the user/password combo is snare/snare. I’ll keep the default, no password is okay for me because the only access to the web interface is permitted on the local machine. Click Next.

Run through the rest of the install keeping the default settings.

Go to Start > All Programs > InterSect Alliance > Snare for Windows. Enter your password if you chose that option.

On the left click Network Configuration.

For the Destination Snare Server enter the hostname or IP address of your syslog server. For Destination Port enter 514 which is the port the syslog server will listen for messages. Choose a SYSLOG Facility and Priority from the drop down lists, remember that your syslog server will need to be configured appropriately for the messages to be received. I will choose the SYSLOG Priority Dynamic, which as I understand it should attempt to translate the event severity in the Event Log to a comparable syslog severity/priority. I’ve noticed some flakeyness with this setting so you may need to specify a single static Priority.

Optionally you can enter a name to override the DNS Name, I chose to override because the DNS Name includes the fully qualified domain name and I’d like to use the shorter hostname. Finally I will check Enable SYSLOG Header, this will fix a few (but not all) of the message formatting issues I mentioned earlier.

Click Change Configuration. Then on the left click Apply the Latest Audit Configuration. Get used to doing this second step, since changes that you make to in the web interface will not be effected until you select this option.

One thing to note is that I experienced problems with the Snare Agent whenever I clicked the Domain Users or Domain Group Members links on the left side. The Snare process would suddenly terminate and I had to restart it manually. This may be simply an effect that I installed Snare on a domain controller, since clicking on the Local entries actually returns results for Domain user/group accounts. Anyway, as long as you avoid clicking these links, the Snare Agent appears to function normally.

On the left click Objectives Configuration.

By default Snare is configured with several rules (objectives) by which it will identify events in the Event Log and forward them as messages to the syslog server. I find that a great volume of log messages are forwarded and I prefer to keep things a little bit simpler and less “noisy”. So I will delete the rules that Snare has by default and will setup my own. Unfortunately I have not found a way to simply disable the objectives, I have found that deleting them is the best way to disable them. You may prefer to make a note of what rules are set up in the event you would later like to include the additional syslog messages.

To delete each objective, click Delete under the Action Required heading in the left column of the yellow table.

Now click Objectives Configuration on the left side and repeat for each objective until they are all deleted.

In the center of the screen click the Add button.

I will keep most of the defaults and leave Logon or Logoff as the event to identify. I’ll change the event type to be captured to Failure Audit to track things such as logon failures with domain accounts to computers and shared folders. If you keep the Success Audit expect the syslog message volume to be larger. Of course the configuration I’m using is pretty basic, but it’s just a starting point. For Select Alert Level I’ll choose Information, this is the event level given to audit events and they won’t be forwarded if you select a higher level. Click the Change Configuration button at the bottom, then click Apply the Latest Audit Configuration on the left.

Configure Group Policy for Audit Failure Events

Since I’m configuring Snare on a domain controller in Active Directory I need to edit a Group Policy to enable logging of audit failures. I’ll edit the Default Domain Controllers Policy GPO since it’s settings take precedence for domain controllers. If you are configuring Snare on a non-domain server or a member server you would edit this setting in the local security policy, the Default Domain Policy GPO, or create a new GPO.

Go to Start > Administrative Tools > Group Policy Management.

In the left pane AD tree open up Forest > Domains > your domain > Group Policy Objects, right click the Default Domain Controllers Policy and click edit.

In the group policy editor on the left open Default Domain Controllers > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies and highlight Audit Policy. Then double click the “Audit account logon events” policy in the right pane.

Add a check mark to Failure, then click OK.

Now refresh the group policy for the domain controllers. Open a command prompt and type:

c:\> gpupdate /force

Close the command prompt once the policies have refreshed.

Now go over to a computer that is a member of the domain and attempt to logon with a domain user account but make sure it is not successful by typing the wrong password.

Back on the domain controller open up the event viewer and open Windows Logs > Security. Assuming this is not a busy server (hopefully this is a test box!) you should see an Audit Failure a few lines down.

Check the event details and scroll down to verify the user and computer that failed pre-authentication matches your details.

Now let’s switch over to our syslog server and verify that the audit failure message was forwarded correctly.

As you’ll notice the message is quite verbose, unfortunately (or fortunately depending on your viewpoint!) beginning with Windows Vista the messages have gotten very detailed. One feature of the rsyslog syslog daemon is that message parsers can be configured to modify these messages and present us with less information.

On my rsyslog server I am running a web console called phpLogCon (now renamed LogAnalyzer) that provides a nice interface through which I can search and view messages on the syslog server. As you can see the newest message received is the audit failure from my invalid logon attempt. I’m not exactly sure why the severity comes up as emergency, this may be a side effect from configuring Snare with the “Dynamic” severity setting.

Well, there you go. Catching those bad guys before they break into your computer systems, ain’t it great! In a future posting I’ll provide details on setting up a syslog server running rsyslog and I’ll walk through configuring the new version of the LogAnalyzer console.