OPSEC LEA pull from a SIEM on R80.10 Smart-1 Log Server

[Lee_Cassey]

So we have access to a SMART-1 Log Server with R80.10 and it is configured only as a logging server, no management server or other blades.  Its receiving logs from several CP firewalls into a management server (which we don't have access to) and then these logs get forwarded to the above Smart-1 Logging server which we do have access to.

Trying to set up an OPSEC/LEA connection for our SIEM to pull down from the Logging Server.  We can create the connection and  SIC generated and activated.  Trouble is the SIEM is complaining that it cant connect on 18120 to get the cert.  We can access 18184 ok via the SIEM and telnet but we get no response from either on port 18120.  our CP support engineer told us that because it is only configured as a logging server with no management blade we wont be able to use OPSEC/LEA to pull logs from it and that syslog is the only option.  Syslog doesnt work especially well with our SIEM as needs some major parsing to account for the originating sources devices being different from the server our SIEM receives syslogs for (ie the logging server)

Does anyone know if OPSEC/LEA is possible in this setup?  Our SIEM providers say that this is the standard way most of their other clients retrieve logs form CP products.  Just wondered if there is a way to use OPSEC/LEA at all in this scenario or whether we have to live with the PITA syslog option thats not idea for us?

Ta

[Vladimir]

Please check if you can use the Log Exporter feature described here:

R80.20 Log Exporter Feature 

It is available as a stand-alone package for R80.10.

[Alejandro_Mont1]

It is most certainly possible to have an OPSEC LEA connection to a dedicated log server, I've done it many times- this is referenced in a few articles (sk103462 for one). Problems establishing trust to OPSEC is usually an issue with certificate strings, sk106615 details how to debug(best used when establishing trust). In order to configure properly you need the certificate strings of the root CA, the log server object, and the OPSEC object. Is there a firewall between the OPSEC device and the management/log server?

When initiating the certificate pull use the IP address of the management server, this is where trust needs to be established. Once that has been completed point the OPSEC device to the dedicated log server IP and you should be good.

[Lee_Cassey]

I think that is our problem,  the management server sits on a network that wont allow us to make inbound connections to.  So our SIEM LEA cant contact it to establish the trust when trying the connection.  

Does the connection need to be always available to the management server?  we 'may' be able to persuade them to allow us short term access via 18120 if a one time connection to establish the trust is all thats needed.

[PhoneBoy]

While we will continue to support LEA for the foreseeable future, Log Exporter is where we are focusing our development efforts for integrations with SIEMs.

What SIEM are you integrating with?

[Lee_Cassey]

Its Dell Secureworks, I know the future lies in Syslog with CP products,  its just the SIEM supported method of ingesting and correlating  CP data is only currently via OPSEC/LEA and integrates far better than the syslog option as it currently stands. 

Their syslog ingesting of CP data is still developmental.  Just trying to get the most rich granular useful data from the two products as possible at present with the option that is formally supported by both vendors.  Further down the line that'll almost certainly end up being syslog  but I'd rather if possible in our current situation have the most rich, usable   data  format thats formally supported by both of our security product vendors.

If an update/upgrade to  any of the CP products 'breaks' the sylog ingesting/parsing and we  have a potential loss in near real time security monitoring data as the CP syslog ingesting is still in development stage by both parties thats a potential risk I'd rather not take until both sides formally support the syslog option as the preferred way forward. 

If I can totally rule out OPSEC/LEA ever working in our current setup then there will be no choice but to use syslog,  just trying to weigh up what my options will be for the most stable solution for the forseeable future whilst we are doing testing/POC tasks.

So does the connection need to be always available between the OPSEC device and the management server for OPSEC/LEA to pull down the cert and establish trust or does it just need that initial connection to pull the cert and then it'll only need to pull from the log sever and not the management server anymore  (until the certificate expires for example?)

Many thanks for all your advice so far Dameon!

[PhoneBoy]

Perhaps short-term access via 18120 may get things going, but I think there are other ports involved as well (e.g. for CRL checking, etc) that could cause issues down the road.

[Lee_Cassey]

Yes  I sort of hoped there wouldn't be any CRL issues and that it would trust the Log Manager to 'proxy' those issues (as the Log manager obviously has a SIC connection to the Management Server for it to use SIC for comms to receive the logs in the first place.  Forlorn hope I guess lol.  Thanks anyway  guys,  really appreciate your advice!

[DeletedUser]

Hi,

Think you can pull the cert locally on the management server, then transfer the opsec.p12 file to the OPSEC client host and use it to establish trust with your log server. Pretty sure it doesn’t do any additional communications with the management server, only with the log server on port 18184 during the first part of the connection to verify trust. You will of course want to do a database install on the  log server after creating the OPSEC APP object.

Sorry, haven’t fully tested the below, but would start with this.

hth,

bob

[Expert@R80:0]# opsec_pull_cert

-bash: opsec_pull_cert: command not found

[Expert@R80:0]# find /  -name opsec_pull_cert

/opt/CPrt-R80/log_indexer/opsec_pull_cert

/opt/CPSmartLog-R80/opsec_pull_cert

[Expert@R80:0]# /opt/CPrt-R80/log_indexer/opsec_pull_cert

CheckPoint 2001. Getting an object's certificate. Works once per certificate.

Usage: opsec_pull_cert -h host -n object-name -p passwd [-o cert_file] [-od dn_file]

        -p is the one-time-password given in the Policy Editor when defining this entity.

        -o is for the output certificate file. default is "($OPSECDIR/)opsec.p12".

        -od is for the output sic name (one line text file).

        A relative path filename will be concatenated to OPSECDIR env variable (if exists).

[Expert@R80:0]# /opt/CPrt-R80/log_indexer/opsec_pull_cert -h localhost -n MyOPSECApp -p abc123

The full entity sic name is:

CN=MyOPSECApp,O=R80..9bpe76

Certificate was created successfully and written to "opsec.p12".

[Expert@R80:0]# ls -l

total 4

-rw-rw---- 1 admin users    0 Jul 24 11:48 CKP_mutex::__CkpReg_Mutex_

-rw-rw---- 1 admin users    0 Jul 24 11:48 CKP_mutex::checkpoint_rand_mutex

-rw-rw---- 1 admin users 3219 Jul 24 11:48 opsec.p12

-rw-rw---- 1 admin users    0 Jul  3 15:16 sessiond.elg

On the OPSEC client, the OPSEC environment would look something like this.

opsec_sic_name <the DN of the OPSEC Application Object>

The SIC name is the OPSEC Application’s full DN (distinguished name) as defined by the SmartCenter Server.  For example “CN=OPSEC_client,O=London..xyz”.

lea_server ip <Log Server IP address>

lea_server opsec_entity_sic_name <DN of the Log Server>

The OPSEC Client uses the Server entity’s SIC name as defined on the common SmartCenter Server.  For example “CN=Log_Server,O=London..xyz”.

[Lee_Cassey]

Thanks Bob, worth a try!

cheers! 

[Ants]

Might be a red herring.. 

Not sure what Dell Secureworks uses as their backend SIEM solution.. i do know for instance Arcsight doesn't support auth LEA on R80.10 due to it not supporting AES-256 encryption as yet (at the least the version i am aware off).. as such the workaround for this is to use clear authentication.. a matter of changing the lea ports in fwopsec.conf if i can remember correctly. Only advisable if this traffic is not being sent via public networks and somehow will get encrypted via IPSEC or similar towards Secureworks.

Cheers

[Alex77]

Hi Gents,

I am looking at getting OPSEC LEA set up for log migration to Logvault.  Is there a step by step guide at all ?

The traffic needs to be encrypted and the logvault machine needs all the details such as device name which it doesn't currently get with syslog.

Many thanks

Alex