Fortigate syslog to Wazuh I can't visualize

[Sidclei Lima]

Dear one light please, I have a Wazuh Server in an ISP,  my agents seamlessly connect to the remote server manager,  however I enabled the fortigate 100F syslog and configured the ossec.conf  to receive the syslogs and it doesn't reach my "cd /var/ossec/logs/archives".......  I'm using Wazuh 4.2.6  In the ossec.conf file I gave my Public IP permission to receive the syslogs on a specific port and NAT to TCP 514,  The installation that the provider made available to me is in Docker.

if I telnet to the syslog port it connects normally

If anyone has a similar experience and can share it with me, I would be very grateful.

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>Public IP</allowed-ips>
  <allowed-ips>Public IP </allowed-ips>
  <allowed-ips>Public IP </allowed-ips>
</remote>

[Tech Master]

Try these command:

FGT # config log syslogd setting
set port 514
end


FGT (setting) # show full-configuration
config log syslogd setting
    set status enable
    set server "192.168.xx.yy"    --> wazuh server IP address
    set mode udp
    set port 514
    set facility local7
    set source-ip ''
    set format default
    set priority default
    set max-log-rate 0
    set interface-select-method auto
end

From wazuh server:
sudo tcpdump port 514 -i ens160

[Roman Luna]

Hi,

We need to check if the Manager is receiving the log entries and if it is converting them in Alerts. The manager works in this way:

1. The manager receives the log entry
2. The log entry is evaluated against the decoders in order to know if there is any decoder that can parse the log. If not, the log entry is dropped.
3. If any decoder is matched, then it is evaluated against the rule set, and if it matches with any rule, the log entry is converted into an Alert and grabbed in the alerts.json|log file.

That being said, we need to know first, if the logs are reaching the Wazuh Server, for this, a TCP dump is needed:

tcpdump -i any udp -nn port 514 -AA

This command must be run in the Wazuh Manager server. If you see packets incoming from the IP of the device sending the Syslog, we need to check if the logs are being processed by the Wazuh Manager.

To check this, we can enable the archives.json file, which will be populated with ALL the log entries received by the manager. To enable it, we need to modify the configurations of the ossec.conf file:vim /var/ossec/etc/ossec.conf

<ossec_config>
<global>
...
<logall_json>yes</logall_json>
...
</global>

Then we need to restart the Wazuh Manager service: systemctl restart wazuh-manager

After restarting the Wazuh Manager service, we should start seeing some log entries in the archives.json file:cat /var/ossec/logs/archives/archives.json | grep '"location":"<DEVICE-IP"'

{"timestamp":"2021-07-04T20:39:03.960+0000","rule":{"level":3,"description":"syslog: Physical root login.","id":"2505","firedtimes":1,"mail":false,"groups":["syslog","access_control"],"pci_dss":["10.2.2"],"gpg13":["7.8"],"gdpr":["IV_32.2"],"hipaa":["164.312.b"],"nist_800_53":["AU.14","AC.6"],"tsc":["CC6.8","CC7.2","CC7.3"]},"agent":{"id":"012","name":"kefbir","ip":"10.10.10.90"},"manager":{"name":"theshire"},"id":"1625431143.753095","full_log":"Jul 4 20:39:03 kefbir login[424406]: ROOT LOGIN on '/dev/tty1'","predecoder":{"program_name":"login","timestamp":"Jul 4 20:39:03","hostname":"kefbir"},"decoder":{},"location":"<DEVICE-IP>"}

The key here, is to look for the IP of the device is sending the Syslog, you can grep to the string '"location":"<DEVICE-IP>"'If it is there, you will see (as in our example) the rule and decoder matching it, in our example:

"rule":{"level":3,"description":"syslog: Physical root login." ... "decoder":{}

If no information about the decoder and/or rule, it means no decoder is matching it, and there is no rule to convert it to an alert. Creating Decoders and RulesIf the logs are arriving at archives and not the alerts file, you need to create a decoder (and a rule or set of rules) for matching the logs from your log file:

• Creating decoders and rules from scratch
• Custom rules and decoders
• Decoders Syntax
• Rules Syntax

Regards,
Roman from Wazuh!.

[Sidclei Lima]

I followed these steps as per the Fortinet documentation  as mentioned Tech Master....  I also performed these steps Roman,  the problem that by docker I can't run tcpdump even with root user, I don't have experience with docker, it was the vendor's option to upload an instance in Docker,  if I give a "cat" in the path you specified, nothing appears from the fortinet syslog, nor from the vmware that I also enabled.

Ff I give a netstat it shows that the ports are listening and external Telnet also knocks on the ports that were released and connects,  remembering that my Wazuh is in a cloud environment  with a specific port and directing to the internal TCP port 514, the provider blocks UDP..... in a test environment that I have I can perform without problems.

tnks 

[Tech Master]

I'm using Wazuh Docker. Before v4.2.6, now v4.3.5.

When I execute this command on Linux host VM (vm-xxx):

sudo tcpdump port 514 -i ens160

I see packets from FortiGate:

23:49:59.038178 IP _gateway.15007 >  server-xxx.syslog: SYSLOG local7.notice, length: 422
23:50:03.664353 IP _gateway.7981 >  server-xxx.syslog: SYSLOG local7.notice, length: 589
23:50:03.964339 IP _gateway.9606 >  server-xxx.syslog: SYSLOG local7.notice, length: 589
23:50:03.984303 IP _gateway.9606 >  server-xxx.syslog: SYSLOG local7.notice, length: 589
23:50:04.041467 IP _gateway.15007 >  server-xxx.syslog: SYSLOG local7.notice, length: 402
23:50:04.041532 IP _gateway.15007 > server-xxx.syslog: SYSLOG local7.notice, length: 423

[Sidclei Lima]

Cool, when I access the VM where Docker is and run a tcpdumpo I see the logs coming from fortigate,  

but if I access docker where is the wazuh manager 
and I run a tcpdump I don't see any fortigate log, as if it were blocking,  if i give a netstat the tcp port 514 is listening,  I enabled the :

<ossec_config>
<global>
...
<logall_json>yes</logall_json>
...
</global>

but nothing comes to him

[Tech Master]

Hi,

my ossec.conf

1)

<logall>yes</logall>

<logall_json>yes</logall_json>

 

 2)

After first <remote> section another one <remote>:

  <remote>

    <connection>syslog</connection>

    <port>514</port>

    <protocol>udp</protocol>

    <allowed-ips>192.168.xx.yy</allowed-ips>

  </remote>

And I didn't do anything else in particular.

[Roman Luna]

Hi,

You mentioned that: it was the vendor's option to upload an instance in Docker.

Docker usage for production environments are rarely recommended. If you are a Wazuh's customer, please use the JIRA portal ( Wazuh technical support - Jira Service Management (atlassian.net)) and create a ticket so we can tackle the issue in a most efficient/practical manner.

Nonetheless, if you are not, provide us the ossec.conf if possible. You should have the ports enabled as you mentioned and forward the logs to that container.

If you are using docker-compose, you can share it with me without sensitive information (as this is a public forum).

Here is information related to it:

Port mapping is used to access the services running inside a Docker container. We open a host port to give us access to a corresponding open port inside the Docker container. Then, all the requests that are made to the host port can be redirected into the Docker container.

Port mapping makes the processes inside the container available from the outside.

While running a new Docker container, we can assign the port mapping in the docker run command using the -p option:

$ docker run -d -p 81:80 --name httpd-container httpd

The above command launches an httpd container and maps the host’s port 81 to port 80 inside that container.

By default, the httpd server listens on port 80. So now, we can access the application using port 81 on the host machine:

$ curl http://localhost:81 <html><body><h1>It works!</h1></body></html>

It’s not mandatory to perform port mapping for all Docker containers. Often, we will avoid opening host ports in order to keep the services of the container private or only visible to sibling containers in the same Docker network.

Let me know of your comments or doubts,

Regards,

Roman Luna.