Forum Discussion

JD1's avatar
JD1
Icon for Altostratus rankAltostratus
Feb 04, 2015

High Speed Logging - Not working quite as expected (Specific to ArcSight)

Introduction

I'm wondering if anyone can offer any advice on how this should be working and whether I'm getting the wrong understanding of this.

 

To be clear, it is not the iRule HSL implementations but simply the built in /sys log-config filters/publishers/destinations.

 

My Requirements
  • I require logs to continue to be available on the Big-IP, as though we've not configured any differences to logging.
  • I also want to log everything (debug from all sources) out to our chosen SIEM product ArcSight.
Things to Know Configuration, so far
  • Configured a pool named SIEM-ArcSight-Logging which contains the ArcSight Server, port 514.
  • Configured a destination SIEM-Dest-HSL, type Remote High Speed Logging (unformatted), forwards to SIEM-ArcSight-Logging pool, type UDP
  • Configured a destination SIEM-Dest-ArcSight, type ArcSight (formatted), forwards to SIEM-Dest-HSL
  • Configured a publisher SIEM-Pub-Default, destinations:
    • SIEM-Dest-ArcSight
    • SIEM-Dest-HSL
    • alertd
  • Configured a filter SIEM-Filter, severity Debug, source all, Publisher SIEM-Pub-Default
Please note...

My gut feeling says I may have set the publisher up wrong, so I have tried each of their entries just on their own. alertd, SIEM-Dest-HSL seem to work fine (I see syslog traffic leaving for the HSL) but ArcSight does not. Documentation seems somewhat unclear as to what destinations are required, i.e. do I just need to add ArcSight and let it forward itself to HSL or do I need both. Also, should I be configuring multiple filters to cover debug/all or am I correct to have just the one 'catch all'.

 

**I have additionally seen a warning on one presentation I bumped into whilst Googling away which said "Warning, dangerous defaults 'debug/all'" but I couldn't find an explanation of why these are dangerous, so I proceeded with caution and tried upping the severity but it made no difference.

 

Any and all feedback/advice/other would be incredibly welcomed.

 

Many thanks,

 

JD.

 

4 Replies

  • Hi JD,

     

    First thing I want to point out is that you should not run your device with Debug logging turned on in production. Debug logging is very verbose and will affect performance. Debug logging is designed for support/development to troubleshoot issues not for normal log level.

     

    Not sure if you need HSL... I assume that ArcSight can be setup to listen on UDP 514 for syslog traffic? If so just point the F5 to remote log. Under "System > Logs > Configuration > Remote Logging" just add your IP address of the syslog server. The log entries will be sent in standard syslog format which ArcSight should be able to consume.

     

    If you do it this way then all the logs will be shipped off and you don't have to worry about setting up HSL.

     

    Regards,

     

    Seth

     

  • Hi JD,

     

    Were you able to succesfully forward the syslog in the required format to SIEM.

     

    I am also trying to achieve similar but in McAfee SIEM and am stuck with parsing issue at SIEM end. SIEM is unable to understand the format. I am more thinking about the delimiter but no where i could find any one succesfully integrating McAfee SIEM with F5 products.

     

  • Sorry to resurrect this thread, but I also have been having some interesting challenges with HSL. We also have ArcSight, and our people also requested CEF. However, when I configured HSL for this and pointed it to a POC syslog server, I was getting useless information... just a couple hex phrases, and they were all the same.

     

    So I dug a little deeper... we are running GTM, LTM and APM... none of those modules contribute anything meaningful to ArcSight. The ArcSight log format is meant for ASM and AFM. Since we are not using those, we are simply sending unformatted syslog and our SIEM folks are happy.

     

    On the other hand, the ins and outs of HSL are still a bit of a mystery. Some of our devices have mysteriously stopped behaving the way they are configured... however that is a different discussion for a different time.