Public IP addresses inside the infrastructure - Logstash mapping problem

[3isenHeiM]

My customer (who has a distributed Security onion architecture running), is using public IP address inside.
These IP are not routed outside, and comes from a legacy (prehistoric) network design. Please not react on this, it's the situation as is.

These have been well setup in the HOME_NET variable, and correclty end up in the network.cfg file of Zeek (thanks to #6854).

The problems now lies further in the information processing chain, as these IP are still understood by logstash and ElasticSearch as Public IPs, and correlates them with the real public IPs used out there.

How and where can I configure Logstash to treat them as local (internal IP addresses) ?

Thanks !

[andre-dessert]

Where are you noticing this correlation to the real IPs? What is the type of public IP specific information you get for the internal IP addresses you are using?

It is possible to edit the Logstash pipelines to evaluate for those IPs and give it a specific field value.

[3isenHeiM]

The infrastructure has some legacy part of the network (let's say in the 1.3.3.7/16 range), while the rest is in the 10.10.0.0/16 range.

Internal traffic between these ranges is captured by Security Onion. Executing a ps1 from 1.3.3.7 to 10.10.1.2 will trigger the suricata rule 2025705 (ET POLICY SMB2 NT Create AndX Request For a Powershell .ps1 File). This specific case is happening in my customer's infra.

If I drill down, I will see the source.ip being populated with the geo coordinates of 1.3.3.7 (located in Victoria, East India in the Seychelles).
Even with the subnet 1.3.3.7/16 being mentionned in the HOME_NET variable.

I've tried building a logstash pipeline to modify these IPs (#9498), but it does'nt seem to work althought testing is is alright.

1. Is there a mean to alter all the data in the ELK db ?
2. How can I say to logstash: don't treat this as a public IP address and dont' fetch geodata for these IPs ?

[andre-dessert]

One possibility you could look into is modifying the ingest pipelines in /opt/so/saltstack/default/salt/elasticsearch/files/ingest/. https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html

That should be were the geoIPs are populating too. You can use a set processor and a conditional to change how it handles those IPs.
https://www.elastic.co/guide/en/elasticsearch/reference/current/set-processor.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#conditionally-run-processor

Any changes that you want to keep around need to be in the /opt/so/saltstack/local/ directory, or they will get overwritten.