FortiSIEM: Load balancing with only one public IP

[Secusaurus]

Dear community,

At the moment, we only have one public IPv4 address left to put the FortiSIEM cluster behind.

This has some implications:

- We cannot differentiate user traffic from collector traffic (which I would like to use to limit the source IPs or even allow users through VPN only)

- As I cannot define different IPs for supervisor or worker cluster, load balancing the collector traffic seems to be impossible - so I will have issues scaling some time in near future (if I don't get more IP addresses)

I do see that there is a property for the port on the collector setting (phoenix config), but I am not sure if this works correctly. My idea would be to hand over different IP-ports for user, collector to supervisor and collector to worker.

Then, I could create VIPs on the firewall that match (and for the workers, load-balance) the ports to the internal IPs.

Because, as far as I can see, the HTTP Host header is not present in the http-request itself, which would be the only method I could distinguish the requests otherwise.

Has anyone else wrapped the head around this? Or do you simply have multiple IPs?

Thanks for your inputs and thought!

Christian

[FSM_FTNT]

Typically we use two IP/DNS names, one routed to the Super(s) and the other routed to the Workers.

The Collectors connect to both the Super (for policy) and Workers (event upload).

[Secusaurus]

Thanks for the answer!

When you say "typically we use [more than one] IP" , do you mean "typically" or "always"?

As mentioned before, I only have one IP at the moment. So the interesting thing for me is how to differentiate worker from supervisor by other factors than the IP.

[sioannou]

Hi Chris1, 

We utilise a single IP. But we front the platform with a proxy. We utilise various DNS A entries to differentiate and load balance across the backend.

For the workers we utilise the inbuild FortiSIEM load balancing, but we are considering of moving that to the proxy at the front and present a single worker DNS A record. 

What we found is that FortiSIEM doesn't operate correctly most of the times if you alter expected ports etc. 

Also the reference Architecture doc has very good information https://www.fortinet.com/content/dam/maindam/PUBLIC/02_MARKETING/02_Collateral/DeploymentGuide/dg-fo... 

Hope that helps. 

S

[Secusaurus]

Hi sioannou,

Thanks for your answer and pointing to the reference architecture doc!

I don't quite understand how your proxy works, though.

When using a single IP-address but with different DNS A records, the final package will not contain the FQDN, unless it's a correctly crafted HTTP(s) request and has the Host or Origin header. I did not see these headers in the requests from FSM collectors yet, so how would your proxy differentiate between the different FQDNs?

Best,

Christian

[sioannou · Accepted solution]

Hi Christian, 

We utilise SNI routing on the Proxy to achieve this. Please note FortiSIEM provides the option to setup the Worker and Super FQDN when doing this. Please refer to link https://help.fortinet.com/fsiem/7-0-2/Online-Help/HTML5_Help/System_Settings.htm#Cluster

So there are a few other tricks you can perform. In latest versions of FortiSIEM there is the support for multiple interfaces. https://help.fortinet.com/fsiem/7-0-2/Online-Help/HTML5_Help/appendix-adding-network-interfaces.htm 

What you can do with SNI routing is to setup a second interface on FortiSIEM for users and then assign a dedicated DNS A record for that. For example user.siem.dns.com, then you setup the internal mechanisms for the cluster control for the Workers, Collectors and Agents with a second DNS A record, for example infra.siem.dns.com.

FortiSIEM internally as far as I could tell utilises local URIs for the redirect of users to the various internal pages, so you can now limit from your proxy access to your users, while the Second DNS A record you can lock down to deployed collectors. If you have the appropriate logging enabled you should be able to get detailed statistics. 

Another option would be to track down the URI extensions for update of the Agents, Collectors and Workers (workers in reality should not be a problem since they will address Supervisor within the same subnet). For example a user will never utilise URI /phoenix/rest/ (unless you allow API access), or a user will never utilise URI /evnthandler* on a worker. Unfortunately I have not tracked all of the URI extensions to be able to provide a list. 

To me the first option is a more viable one since it allows for any future URI extensions. I have tested this deployment in a lab in the past as a showcase for white labelling. Let me know if you have more questions on it.

Regards,

S