Jump to content

pronto

Members
  • Posts

    92
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by pronto

  1. This is maybe the reason why I haven't found it... 🙄
  2. Servus Community, is it possible to configure a firewall in Windows File Security that only allows inbound and outbound ports from certain sources or destinations and prohibits everything else? For example RPD only from this host and also only RDP and nothing else? Or port 2222 (ESET Communication) only from and to this host? I can't follow the instructions I found in the File Security interface. The Windows Firewall would be one possibility but there are 1001 magic rules inside, of which probably half are only understood by Microsoft Nerds. I would like to avoid using them. Thx & Bye Tom
  3. Servus Community, we have received feedback from support. Removing macros from Office documents only works for Office documents that are newer versions or afair equal to version 2007. Under these versions, ESET cannot unzip the office document to remove the macro. The entire document is then moved to quarantine. This is a bit of a pity, because it would be a significant increase in security, but has a high error potential. Since this feature was introduced only a few weeks ago, there is still hope that it might be adjusted. Thx & Bye Tom
  4. Servus Marcos, I opened a support ticket. For everyone who is interested in and has access to the submitted data, the ticket number is: CASE_00092770 Thanks for your attention & Bye Tom
  5. Yes, this is what Matej announced a few posts before. Thx & Bye Tom
  6. Servus Matej, no, the rule does not work as expected. The entire attachment is still being moved to quarantine. The modules are all updated to current versions:
  7. Servus Matej, I could not follow your instruction step by step. I have underlined the parameters I consider necessary in your mail. However, I have not found the parameter 'Incoming email'. Here are the steps I have now set, could you please check if this is correct and if it meets our requirements? Create a new policy (Product: ESET Mail Security for Microsoft Exchange (V6+) Settings -> Server -> Rules Mail Transport Protection -> Edit -> Add Condition type -> Office Files -> Other Files -> Generic OLE2 Compound Document Action type: Quranatine attachment Apply policy in Mailserver related group (Not done yet, waiting for clearance) Thx in advance & Bye Tom
  8. Servus Matej, This are interesting news. Thank you for being so careful and giving feedback after such a long time. I don't know where I can look up in the Security Management Center what we actually use but according to the description of an article in your knowledge base I found it on my client and I would consider the German translation to be related to Archivunterstützungsmodul. It seems to be available in version 1302 and seems to be from 05.05 (Please note attached screenshot). The updates seem to come automatically. Such an unremarkable update unlocks such a fundamental function? Probably only the object type OLE is added, which addresses the macro as an embedded object. We will test it as soon as it is available and it would be something we have sadly missed so far. Thy a lot & Bye Tom
  9. Servus, the detections run on two Exchange Server 2016. These are brute force attacks that are applied to the virtual directories of Exchange IIS. I can't get out of this, if OWA and Active Sync should be accessible via the Internet. The problem is not unknown, and we used to use a reverse proxy to prevent it, but we don't have that anymore since Microsoft stopped it's TMG support. Our goal now is not to prevent these detections but we don't need to have every single successfully blocked attack in our log. This makes the log confusing and trains people to ignore warnings because they think they know what is behind it. An error or warning should be a rare event and every single one should get full attention. This is not possible if you know in advance what to expect in 95% of the warnings. If there is another solution that we have not yet considered, we would be interested to have a look at it... Thx & Bye Tom
  10. Servus Community, in another thread regarding this 'Disable.Attack.Generic' warning we found a place in the policies where this warning can be disabled but the setting seems not to work because these warnings are still logged. See the attached screenshots. Thx & Bye Tom
  11. Servus Marcos, ist the ESET Dynamic Threat Defense feature included in an ESET Secure Business license? It isn't listed in the feature list of any product:
  12. Servus Marcos and Itman, we have discussed this issue with our management, even though we have deactivated the execution of macros in Microsoft Office by group policy but it would be worse if we would forward such an e-mail to a business partner who does not have that many security levels available. This was our biggest concern in this particular case. Our management has classified this as a serious incident, not least because an encryption Trojan recently caused a business partner to suffer significant financial damage. Our preferred configuration would be to remove all macro code from every Office document but still deliver it, but of course if no virus was found or the email was not detected as spam. That's how we had configured it earlier and had actually made good experiences with it. But ESET can't do that in this form as far as I know. But it would be great if it could. If this is not possible, we would be interested in a procedure to collect data about how many Office documents with macro code we receive and how many of them might have been detected as false positives, if we decided to generally reject such documents in a later step. This was the result of our meeting with our management. Do you have any ideas on how we could best solve this? Any suggestions would be welcome. Thx & Bye Tom
  13. Servus Itman, yes, the email arrived on wednesday at 10:50, at that time the two internal mail servers had installed pattern 20750, the border edge mail server even had installed pattern 20751 for a few minutes. The two internal servers both found the virus at 15:01, half an hour after the update to pattern 20752. Thx & Bye Tom
  14. I understood. It would be interesting to know which versions of a virus are covered by which patterns and which version of the virus you are dealing with. This would help to understand what happened and help to take countermeasures. I can remember earlier times where other vendors listed exactly if this or that DLL is found with a size of so many bytes, there is an infection, otherwise with certain listed sizes and version numbers they are unsuspicious original files, depending on the patch level. This way or something similar. This may be a bit much information but for those who need it, it is definitely invaluable. But that's probably not a problem we are solving tonight... 😉 Bye Tom
  15. Hm, that's not good. ESET tells me they've found a virus, but they won't tell me exactly what virus it was. We had the same situation this week with the analysis of the spam detection values in the header of an email, they were not public either. This is really a pity, it was looking so good... Bye Tom
  16. Servus Marcos, is there a public database where you can view more detailed information about specific malware? Such as the history or other useful information to make your own investigations if an infection is suspected... Thx & Bye Tom
  17. Servus Comminity, yesterday at 11:00am we had a false negative detection on our Exchange Server, which accepts the email from outside and is the first instance to check for viruses. This server then forwards the mails to the internal servers, which host the databases of a two-node DAG. At about 15:00pm the virus scanner on the internal Exchange servers has detected and deleted an infected attachment. Due to the delay of four hours I first assumed that this was a zero-day exploit and unfortunately we were among the first to receive this virus. However, further research has shown that ESET has known this virus, or at least a virus with the same name as this one, since 20.01.2020 and would therefore be far away from a zero-day exploit. In the logfile of the virus scanner there are some updates of the detection engine for yesterday, on all three mail servers. How is it possible that the first mail server missed the email and the other two did not have a reaction within four hours? Is this a generic name, as there is no version number in the threat name, are there more detailed information about the found virus? If the name is not specific and is used multiple times, how can you take adequate action in case of an infection? Thx & Bye Tom
  18. Servus Rami, I'm afraid none of this would have helped, because ESET did not know about the virus at 11:00 and only at 15:00 a pattern was inserted which recognized the virus. We only noticed this because we have three exchange servers but only one of them accepts emails from outside, but the virus was only found four hours later on the two internal mail servers where the databases are running. ESET Mail Security is installed on all three servers. Normaly only the first mail server finds viruses and spam, and the other two usually don't even notice how evil the world outside is. Thx & Bye Tom
  19. Servus Rami, yes, i know that this can be disabled in office and we have enabled this policy but it only applies to the computers in our organization. But if we accidentally forward this email to an external business partner, they will receive an infected email from us as the sender. This would be negative, because I can't make sure that the business partner has secured his infrastructure as well in that deep level, and we are the sender of the virus. Thx & Bye Tom
  20. Servus Community, is it possible to setup ESET to remove any macro in Office documents, whether a virus is found or not? So don't delete the office document itself, just remove the macro? Background: Yesterday we received an email at 10:50 with an Office Word document to a mailing list and in this email was a macro with a trojan downloader. Upon receipt, ESET did not classify this email as suspicious. In the afternoon around 15:00 the virus was detected and removed by ESET in the Word document. In the four hours in between, a lot has happened to this email, including it being opened several times. Fortunately, we have configured additional policies in Microsoft Office that prevent the execution of a macro, but this only affects local PCs. But if we forward this email to a business partner who has not set such policies, he will receive a virus from us. Before we switched to ESET, we had Trend Micro and there you could enable an option that removed any macro from the Office documents and still delivered the safe document. No one needs macros and if they do, we'll find a solution. Can we configure ESET to do that? Thx & Bye Tom
  21. Servus Matej, according to the policy, ESET should remove the SCL, and apparently it does, as there is no longer one in the header. Of course I don't know now if Exchange will evaluate the SCL before ESET deletes it. Is there any other overlap where Exchange Server might still be doing things that ESET doesn't know about? What is the order in which an e-mail passes through the individual filters? Anyway, I noticed that since we got the new Exchangers with ESET, only these Amazon mails are now in my junk mail directory. So I guess that ESET checks the mail before Exchange Server does and has already filtered out all spam and a filter behind ESET, classifies this Amazon mail as spam. Then it really looks like a filter in Exchange server. But then it looks like ESET is responsible for the fact that in principle no more spam mails can be found in the junk mail directories of the users. Is it possible to setup that spam mails will be delivered in the Junk Mail folder again. Our users are so used to it... Thx & Bye Tom
  22. Servus Community, I try to figure out why an email is moved to the end users Junk Mail folder in Outlook. Note that we are working an Exchange 2016 DAG with two nodes. An example mail header lokks like the following: X-MS-Exchange-Organization-MessageDirectionality: Incoming X-ESET-AS: R=OK;S=0;OP=CALC;TIME=1580052250;VERSION=7846;MFE-VER=58;MC=2416161006;TRN=2002;CRV=0;IPC=54.240.0.225 X-ESET-Antispam: OK Old-X-EsetResult: clean, is OK Old-X-EsetId: 37303A29666CC669677661 X-MS-Exchange-Organization-Network-Message-Id: 269bf092-eb36-4fb7-8920-08d7a273caf8 X-EsetResult: clean, is OK X-EsetId: 37303A294BD8CC69677661 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 X-MS-Exchange-Organization-AuthSource: UNIVERSE-3.DOMAIN.local X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.5779049 X-MS-Exchange-Processed-By-BccFoldering: 15.01.1847.001 On the Mail Security policy side we are using a standard policy with only two user defined changes: First we configured a white list in the 'Approved sender list in the 'Filitering and Verification section', but we configured it after the false positiv detection and second, we changed the behaviour of the 'Action to take if cleaning not possible' from 'Truncate to zero length' to 'Replace content with action information'. In the header of a false positive example above, we see an 'X-ESET-Antispam: OK' tag, which menas to me, that ESET didn't apply any anti spam action but the question remains, why this E-Mail was moved to the users Junk-Mail folder. Please note that this was an Amazon e-mail, not related to a specific order but offering products for promotional purposes. So it is not that important but a good example how to learn how the anti spam filter works... Is there a documetation about the single values of the 'X-ESET-Antispam' tag? I guess I understand some of the values, like the versions and the receive yes and send no, as well as the time stamp but MC= for example and TRN=, CRV= and IPC= isn't clear to me... Thx in advance & Bye Tom
  23. Servus Community, we have added two Exchange Server 2016 to our infrastructure this week and are currently analyzing the behavior of the servers. The Exchange infrastructure is accessible via HTTPS over the Internet and today we saw three warnings in EMC that we can't unambiguously interpret now. It indicates that the firewall has detected some attacks but not what has been done about them. The warnings are listed as unresolved. Probably they are just brute force attacks on the login of the Exchange Command Panel but what makes us suspicious is that we did not knowingly install a firewall. We only installed the Management Agent and the Mail Security. Is there more information where this firewall comes from now and a best practice tutorial on how to best handle it? And how should we proceed with these unresolved threats? Thx in advance & Bye Tom
  24. Servus Marcos, I agree with you, until now I haven't experienced a negative impact with ESET in the short time we've been using it. But we are already testing the settings by deactivating the virus scanner and placing EICAR test files in the system, when the virus scanner is switched on again the test files have to remain in the excluded paths and the others have to be detected and deleted. We only use these exception lists of the manufacturers for extremely critical database systems, such as Exchange, Domain Controller, SQL Server, Datev, Agenda, backup files, etc., where a false positive detection can cause high potential damage. In some cases, however, we have not installed any virus scanners on such systems but are currently reconsidering our strategy with regard to protection against network-active encryption Trojans. Thx & Bye Tom
×
×
  • Create New...