0

I want to collect logs from a security device (McAfee Email Gateway) to our SIEM Syslog server. This security device can forward logs only via TCP syslog on any port (in our case it is 514). We are not getting logs from this security device and when I ran the wireshark to capture traffic from the security device to our syslog server, I got RST-ACK from the security device.

The complete wireshark is :

SYN --> from security device to syslog server

SYN-ACK --> from syslog server to security device

ACK --> from security device to syslog server

RST-ACK --> from security device to syslog server

What can be the issue? Is the three-way handshake complete? If not then why? If yes then why I am not able to see any log transfer.

Regards, Mitesh Agrawal

1
  • Unfortunately, questions about hosts/servers are off-topic here. You could try to ask this question on Super User.
    – Ron Maupin
    Commented Jan 30, 2020 at 13:31

1 Answer 1

1

Typically, a TCP responder (here: your SIEM Syslog Server) will send a TCP-RST as a response to a TCP-SYN that tried to reach a (destination) port that was not in LISTENING state.

In other words: "Port not open".

You may want to check if the intended receiving system is actually configured to accept syslog messages on TCP (most often, Syslog runs on UDP/514). How to verifiy and/or reconfigure that is a question of host/software configuration, which is off-topic for this site. SuperUser or ServerFault might be more appropriate.

Please also consider: there are firewall products (both "network/device" and "host based" firewalls) that can send a "fake" or "forged" TCP-RST back to the TCP initiator, if the given communication is not allowed, AND if the given product is configured to "REJECT" instead of "DROP" (terminology may vary by vendor).

When doing so, these products will use the (intended) TCP responder's address as source address for the TCP-RST packet (therefore this response might be considered "forged/faked"). If there is such a device in the network path, the TCP-RST coming back to the TCP initiator might not actually come from the (intended) responder, but from a firewall along the path.

Not the answer you're looking for? Browse other questions tagged or ask your own question.