fw1-loggrabber and MDM/P1

Update: My guys are telling me that loggrabber is faulting because there are new fields in the log records that loggrabber does not know about. I think it was the ‘user’ field or something to do with application control. They debugged it and recoded it to get it working.

================================

Do you need to grab logs from SmartTracker so you can do analysis? fw1-loggrabber to the rescue! An oldtime tool that really works well.

In my career I have setup fw1-loggrabber about about 3x, and everytime I forget what goes where and what DN’s to use. Especially in a P1/MDM environment it gets somewhat confusing because the DMS and the DLS are on two different platforms. Also the documentation is old and confusing because  here are SOOOOO  many damn versions and SIC protocols. Ugh.

Here is the magic ju-ju so I never forget again! On R75.46 anyways (Oh yeah, don’t forget to never upgrade to R76 or R77, you will die a slow death)

You have to setup SIC with the DMS, and pull logs from the DLS. Seems simple, but the DN’s get a little tricky.

First on your DMS, setup an OPSEC client that is the middle man between the Unix fw1-loggrabber and the DMS/DLS:

It should look something like this ( I had to remove proprietary info).

Save the SIC password. Push databases to the DMS and the DLS.

Then go to the DMS and get a list of all the valid SIC certs and write them all down. Specifically the loggrabber, DLS and the DMS ones

1. mdsenv DMS1
2. cpca_client lscert -kind SIC -stat Valid

Then go to your fw1-lograbber Unix client and establish SIC and get the public cert of the DMS1 IP address 10.2.1.101 and the OPSEC LEA agent name. Both of these queries go to the DMS. Turn on the debug.

1. ./opsec_putkey -debug -p vpn123   10.2.1.101
2. ./opsec_pull_cert -p vpn123 -h 10.2.1.101 -n LEA-Loggrabber    -d

This file should be put into your local directory: opsec.p12

From the above diagram, create your LEA config, lea.conf . I showed you what CN’s to use here. I also use full path names. I use sslca and it works by default so you can ignore all those other protocols.

You should be ready to execute the fw1-loggrabber on your Unix machine, pull from the DLS. I use the debug switch to make sure things are working OK.

fw1-loggrabber --debug-level 3

So be a little careful on a MLM. If you have your logs going there and you have Tufin extracting logs and you have SEIM like (god help you) RSA Envision sucking logs and you decide to put this on your MLM, then your log servers are going to be REALLY BUSY!!! LEA sucks a lot of disk and CPU. So make sure your log server has lots of CPU.

And Dreez Says to His People: Go Forth and Grab Logs!

over and out,

dreez

Don’t put IA on the log servers – most the time

OK, I feel stupid.

I read the documentation and blindly did what it told me to do. Well I guess that will work out in a mom and pop shop, but bad things will happen when you do it at the enterprise level

Don’t do IA on log servers

If you ever put IA on a log server, it will go collect log events from ALL DC’s registered in the LDAP AUs for the whole domain/DMS/CMA!!!! So if you have 1000 DCs registered, it will accept from all of them.

Doaaah.

On top of this….you don’t need it. The gateways will collect the IA information and send it along with the logs….assuming you are running IA on the gateways.

So if you ever think that the pipe going to your log servers is jammed with Windows events, you might want to re-architect how you collect IA logs.

Old dogs learn slowly. NEVER read the documentation!

Accept any any any

dreez

dreez

Problems with routing

Misc notes from my wars with clustering and routing. Most of these are being worked at CP.

1) Two sets of commands for clustering and routing

1. drouter start/stop
2. cphapstop/clusterXL_admin

Clusterxl_admin down does NOT stop routing. So its possible for 1 member to route and 1 member to firewall. BAD. routing should follow clustering.

2) GAIA and Kernel have two different views of what is in routing table. GAIA is the right one

3) cphastop and clusterXL_admin down have two different impacts on routing

cphastop stops the HA daemon so even if routed is running it is NOT exchanging routes with the active member. OSPF will only see directly connected interfaces

clusterXL down leaves the HA daemon up, so even if member is pnote down, it is still exchanging routes with the active member AND with the BR and BDR.  Bad one member should do both clustering and routing at same time.

4) If interface is part of OSPF and enabled but no link, it is still advertised. BAD. Should not advertise.

5) If you pull the sync cable and reboot the cluster cannot find the right interface. It will even use a VLAN that is NOT the first or last. This is because it thinks the interface is a NEW interface and is not registered. Leads to Master-Master fights.

CP Gossip – Releases, routing, IA, bugs

OK so assume this is Dear Abby or a gossip column. So verify everything I say.

1) R75.20 and up has been a bug ridden disaster. Too many features jammed into too little time with too little QA. Make sure the Abra stick works with the DLP on 64bit GAIA on the new appliances with the new VSX Firewall architecture integrated with SmartWorkflow and the GRC blade with AntiSpam and AntiBot but don’t forget that technical gem licensing system which barely functions and blah blah blah, etc. The code is turning into feature based spaghetti. god bless those support people.

In January 2014 CP will go back to QA based releases vs marketing/feature releases. Hopefully old reliable steady solid product days are ahead of us.

2) Routing is working better but still broken in cluster environments. Make sure you ask for the latest patches. Basically if you don’t care if it takes a while to re-populate routes on failover or upgrades, then no problem. But if you have a 24×7 HA requirements, then you should wait. I hear rumors that the clustering people are finally having lunch with the routing people and talking.

My opinion is clustering and routing should use 1 set of commands and be seamless between them. cphastop should do a drouter stop and vice versa. And you shouldn’t have to manually load routing tables to do a full connectivity upgrade.  It should all be baked into cphastop…period.enough said.

3) Identity Awareness: In large environments….issues with talking to large number DCs. I will write something up next. Stay tuned. Lots of patches here also.

4) I’ve got several customers reporting that their R75.40 -> R76 clusters are randomly seizing and failing over but statefuly. Long term state protocols like FTP are failing. I have also seen this. Seems to be on high use connection systems, but even when the box is 90% idle but has lots of connections. Not good. Not sure if this is getting visibility in CP.

4) GAIA Radius into /bin/bash: Hey they finally! allow non-local users to go into a /bin/bash shell! They fixed it.

So the good news is its getting better its just going to take some time.

cpstop,

dreez