search

elastic / integrations

Elastic Integrations
https://www.elastic.co/integrations
Other
42 stars 451 forks source link

"Fortinet FortiGate Firewall Logs" v1.24.0 - Inbound Connections parsing reversed #9394

Open eriroley opened 8 months ago

eriroley commented 8 months ago

I note that this is very obvious when looking at incoming VPN connections to the Fortigate (fortinet.firewall.subtype:vpn)

The original log messages include 'remip' and 'locip' (remote and local IP, respectively) and these are parsed in reverse with "remip" being used to populate 'destination.ip' and 'locip' used to populate 'source.ip' even though these are incoming connections

eg: event.original: <129>date=2024-03-20 time=09:11:38 devname="snowfort-1" devid="[SNIP SERIALNUMBER]" eventtime=1710940298376973197 tz="-0400" logid="0101039426" type="event" subtype="vpn" level="alert" vd="[SNIPVDOM]" logdesc="SSL VPN login fail" action="ssl-login-fail" tunneltype="ssl-web" tunnelid=0 remip=195.96.157.201 user="user" group="N/A" dst_host="N/A" reason="sslvpn_login_permission_denied" msg="SSL user failed to logged in" results in destination.ip: 195.96.157.201

elasticmachine commented 8 months ago

Pinging @elastic/sec-deployment-and-devices (Team:Security-Deployment and Devices)

gogochan commented 1 month ago

We need more information to make a reasonable decision about this one. I cannot simply flip source and destination ip based on vpn subtype.

If the information is misleading, I'm leaning toward eliminating destination.ip and source.ip property for vpn subtype.

Any thought @taylor-swanson

taylor-swanson commented 1 month ago

I know in other integrations we've added internal/external networks/zones configurations to help in the enriching of documents in situations like this. If we can't key off of any other fields in the log in a reliable way, then a user-provided configuration would be the only way to go (if that even makes sense in this case). Otherwise, I would also lean towards removing any mention of directionality as I would not the document to be misleading.

qcorporation commented 1 month ago

@gogochan @taylor-swanson, what information do we need and from whom to make a sound solution for this issue? cc. ing @andrewkroh

gogochan commented 1 month ago

After reviewing logs from these sources again,

I think it is reasonable to flip the source(the client) and the destination(the firewall) to note that the VPN session originated from the client.