Feature Request - Daisy-chain SmartConnectors using SmartMessage

Currently, if an administrator wants to connect a series of SmartConnectors together, eg:

Device --> Local Office SmartConnector  --> Data Centre Aggregating SmartConnector --> ESM

They must use one of:

- CEF TCP (for reliable transport)

- CEF UDP (for simplicity/load balancing)

- CEF UDP Encrypted (encrypted, but not reliable)

- SyslogNG TLS  (encrypted, reliable, but not compressed)

It would be very useful for the upstream SmartConnector to support receiving SmartMessage as a protocol, as sent by the downstream connector. This would then provide a connector-to-connector protocol which is:

- Reliable (failure detection supported)

- Encrypted

- Compressed

- Authenticated

There are lots of reasons for daisy-chaining connectors, such as:

- Aggregating very large numbers of connectors (eg. branch office or agent connectors) down to a number that ESM can handle being directly connected to it

- Aggregating connectors to a point before/after a load balancing architecture, where it is much easier to aggregate the feeds first

- Relaying through aggregators that are needed to simplify firewall rules at different zone boundaries

This request is to add "SmartMessage" as a device type that can be received by a Connector, to the SmartConnector framework

- This would simply be a type of connector selected on installation or configuration, in the same way as "Syslog Daemon" or "ArcSight CEF Syslog"

- It would allow the receiver name (configured on the downstream connector) to be defined, or to accept any receiver name

- It would provide support a means for downstream connector authentication/registration, similar to when registering a connector to ESM, to protect against rogue connectors being associated in order to send spoofed events

Absent Member.

Hi Damian, thank you for bringing this up, this is actual very usefull for two projects I'm working. If required I can specify details to product management for the business case.

Absent Member.

I guess feel free to add them here, Rudi, if you can publish/generalise them

Absent Member.

Need exactly this feature! Any word on if/when it will be made available?

Outstanding Contributor..

I wrote a JIRA for this a while back, I called it a 'relay connector'.

I don't actually see anything unique/special about 'smartmessage', I think that it is all covered by CEF with every intermediate Connector except for the originalAgent being Syslog-ng.

To me smartmessage means Logger Destination, during connector configuration ESM is always referenced as some other ESM encrypted, and in the is distinguished https .vs. smartmessage. But both are TCP/SSL aren't they?

I think just moving CEF around on the intermediate (relays) is the way to go and then chose your transport UDP/TCP and if necessary encryption, noting that it seems finally some (CEF?) TCP TLS issues have been addressed in the last 3-6 months. When you get to the 'end' and the Destination is a 'consumer' then you drop out with the appropriate destination formatting.

I probably have missed something in the 'need' that isn't handled above.