Mike_Kintaru gave kudos to MartinK in ESMC Syslog
If I recall correctly, only login&logout audit messages are actually exported, i.e. there is probably no way how to export other audit messages.
There has been issue in one of previous releases (probably 7.1) where wrong delimiter was used in LEEF format, which caused issues when parsing messages - this is probably why they were not visible in QRadar as they were supposed to be.
Mike_Kintaru gave kudos to karlisi in ESMC Syslog
No, it's server's syslog messages, like this:
INFO: [karlisi] User sends gql request: qroups (192.168.0.111 #id=TASKS:id=CLIENT_TASK_DETAIL;u=48eef0ae-96d2-4bed-ad2b-b5094a07cfe2;p=2:id=TARGETS_TRIGGERS_TASK_WIZARD;tru=be984c29-a03d-4cfa-9e16-d1d713f437a9;tsu=48eef0ae-96d2-4bed-ad2b-b5094a07cfe2)
This message is one of many which corresponds to this ESMC audit log entry:
Modifying client trigger of type 'Scheduled Trigger' with description 'ASAP; Outdated, Not protected' for task 'AV update to latest'.
Mike_Kintaru gave kudos to M.K. in Eset Mail Security
also please note that ESET Mail Security for Exchange can also be used to scan Exchange Online mailboxes with on-demand scan in case of hybrid deployments (on-premise + cloud). Mail transport in hybrid deployments is scanned only if emails are routed first to on-premise server and then to cloud.
Mike_Kintaru gave kudos to Petr-K in EFS for Linux issue - eset_rtp(ertp_wait_for_reply)
I installed Eset file security 7.1 for my Samba server with CentOS 7. The server still freezes after a few hours of running EFS. When it happens, I tried connect via SSH, but I got a timeout. Only what can I do is hard reboot of the machine. When I look at the log, I find similar lines before crash.
May 14 09:43:02 server169 kernel: eset_rtp(ertp_wait_for_reply): wait for scanner reply timeout, path: /var/lib/samba/lock/msg.lock/5339, size: 21, event: CLOSE, command: smbd, pid: 5339
May 14 09:43:03 server169 kernel: eset_rtp(ertp_wait_for_reply): wait for scanner reply timeout, path: /var/opt/eset/RemoteAdministrator/Agent/data.db, size: 331776, event: CLOSE, command: ERAAgent, pid: 1059
May 14 09:43:03 server169 kernel: eset_rtp(ertp_wait_for_reply): wait for scanner reply timeout, path: /var/lib/samba/gencache.tdb, size: 667648, event: CLOSE, command: smbd, pid: 5118
May 14 09:43:04 server169 kernel: eset_rtp(ertp_wait_for_reply): wait for scanner reply timeout, path: /var/lib/samba/lock/locking.tdb, size: 581632, event: CLOSE, command: smbd, pid: 5340
Did anyone have the same problem?
Thanks for any advice.
Mike_Kintaru gave kudos to Marcos in Update Error?
With EDTD, any file potentially carrying malware is submitted for analysis in the cloud where the file will be run. Based on the behavior analysis and evaluation by 3 different machine learning models, the file is then evaluated either as malicious, highly suspicious, suspicious and probably clean. EDTD can be configured to block access to files downloaded by browsers or email clients until a result of EDTD analysis is received.
Let's assume a spammed VBA office document with a malicious macro that is not covered by a detection.
Without EDTD: A user receives the email and opens the attachment. Since there's no detection for it yet, it will be run. Depending on what it does, further operations may be detected by some of the protection modules (e.g. if it downloads payload from a blocked url, web access protection will block the download). If it dropped payload and ran it, the payload could be detected by Advanced memory scanner, Deep Behavioral Inspection, etc. upon execution. It could also happen that it wouldn't do anything that could be detected by other protection modules. The user would need to wait until the next module (engine) update to get the malicious document detected.
With EDTD: The user receives the email. The attachment is sent to EDTD. The user attempts to open the attachment but EDTD blocks the operation (results from analysis have not been received yet). During the analysis the document is evaluated as malicious (e.g. the detection has been added in the meantime, the behavior of the document was suspicious, etc.). Once the analysis has completed, all machines in the organization are informed that the file is malicious and Endpoint on machines acts accordingly, ie. blocks access to the malicious document.
Mike_Kintaru gave kudos to kurco in Install Eset File Server (error)
ESET File Security for Linux supports only UTF-8 & ANSI X3.4-1968 codeset. Probably codeset configuration of your machine is different. Changing locale settings to UTF-8 should resolve your issue. For example ,if you are using US english, this is an working locale "en_US.UTF-8" and this a non-working locale "en_US.iso88591".