Jump to content

JimChev3

Members
  • Posts

    19
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by JimChev3

  1. Sorry to say, you've still got work to do. I've had some sporadic incidents one by one throughout the morning, but just got notified a few minutes ago that 10% of my computers had issues, and it is indeed the push notification service cannot be reached issue again.
  2. I also just started receiving this notification this morning. A little less than half of our devices are currently affected since around 9AM this morning and still occurring. Glad to see you guys are on it. Update 4/25/23, 7AM Eastern Time: It appears to still be a problem, although less so than yesterday. None of my systems were showing the error when I got in this morning. However, I've had three pop up with it in the last 30 minutes or so. Rebooted the first two and so far, they're still OK, but they may just not have triggered the notification yet also. I'm not sure how long that takes.
  3. I also just started receiving this notification this morning. A little less than half of our devices are currently affected since around 9AM this morning and still occurring. Glad to see you guys are on it.
  4. As of this morning, 4/24/23, most of my environment has started showing that error. Windows clients (ESET Endpoint Security v10.0.2045.0) and servers (ESET Server Security v10.0.12010.0) alike. Ports 8883 and 443 are open to epns.eset.com and the firewall is not showing any denied traffic on those ports except for the rare, odd incoming traffic from IP addresses that are not on your list of ports and addresses document online. There were some TCP SYN checking issues on traffic coming from your push notification servers (tcp syn checking failed, expecting SYN packet for new TCP connections but received ACK FIN or RST instead), but even after turning that off and thereby seeing no more denied traffic for that, everything is still unhappy. I am running an ESET Protect virtual appliance here that everything is connected to. That appliance is reporting as server version 10.0.2133.0, web console version 10.0.132.0. As far as I can tell, everything is on the most current versions available. It's currently showing on 46 of 69 devices in my ESET console. I'm assuming most of the rest just haven't started reporting it yet as the number has been slowly climbing all morning. The only thing I've found on it so far by searching that I have not tried are the instructions at https://support.eset.com/en/kb8207-resolve-push-notification-service-servers-cannot-be-reached-alert-in-eset-endpoint-products. Largely because I'm not sure if these are even still applicable, and also because everything was working fine up until this morning, so I'm not sure why I would all of a sudden need to do this when it hasn't been needed before. I stand ready to provide any further information that I can, but I need some guidance on where to go from here please.
  5. Ah, I was just asking it to scan the URL. I've forwarded all your information on to someone at that township. Again, thank you so much for your help!
  6. Really? What did you run Virustotal against? I ran the URL check against the main web site URL (the one I listed in my original email) and it came back clean. I just ran it again and got the same results. I'd love to be able to point to something more than just you and Sucuri when talking to the web admin about it.
  7. One of my employees visits a web site regularly for information. The web site is www[.]perrysburgtownship[.]us. Starting this week, whenever she tries to go there, ESET triggers a JS/Agent.PIV detection on what appears to be every .js file on their web site. I tried to verify that detection independently of ESET, but the only other thing I've found that triggers on it is Sucuri, which also has a write-up about what's it's detecting at https://blog.sucuri.net/2022/06/analysis-massive-ndsw-ndsx-malware-campaign.html. Sucuri is triggering specifically on a piece of js code: "if(ndsw===" break inserted by me to prevent any detections on the string in question "undefined)". No one else is detecting malware on this site, but the write-up by Sucuri was written back in June, 2022, so this isn't something new that might not be detected yet by other scanners. I've also visited the site in an isolated Windows notebook outside of our firewall with only Windows Defender on it to see if anything untoward seemed to happen and nothing appeared to be going on. I also tried with a Linux Mint notebook under similarly safe circumstances. I'm hesitant to contact the webmaster of the site about the problem since only you and Sucuri are saying there is one. Can you guys check this and see if it's actually malware embedded on the site or simply a coincidence that this site uses that particular snippet of code? I've attached a screen shot of the detection info from ESET (just one of the occurrences). Thank you.
  8. I should also mention that since my first email, I've also added that server IP to the IP Allow list., since that may have had an impact on it as well.
  9. He just replied to an email I sent him earlier and it came through. Seeing as how this isn't the first time this has happened with them, any diea what's going on? Is there something happening with them that causes them to end up temporarily on your blacklist every now and then or are they not even on there and something else is going on?
  10. Sorry about that, guess I should've been a little more specific. This isn't a client problem, it's a problem with Mail Security for Microsoft Exchange. Client settings aren't even in the picture for this problem, it's happening at the transport level, so it hasn't even made it to the server, let alone the mailbox to be looked at by client settings.
  11. I've got a city that we do business with that, whenever they send us anything recently, their emails are being bounced with that reason. The IP address in question is 205.245.84.78. Since they've had problems before with this, most recently back in Sep. and Oct. of 2022, I already had them whitelisted by the domain of @cityofbryan.com. That worked up until today. Now their mail is getting bounced again in spite of being whitelisted. Attached report is one of three attempts this morning. So I have two questions. First, that IP address doesn't seem to be blacklisted anywhere else (checked via mxtoolbox), so why is it with ESET? Second, is there any way that I can get mail flowing from them again in spite of the blacklisting? Will it be overridden if I whitelist the IP address, or does no whitelisting take precendence over being on your own blacklist? And I apologize for not submitting a false positive through the normal channels, but your normal reporting wants the email in question and I'm not receiving it since it's being bounced. There's also no feedback from that channel and I would like to know what's going on.
  12. Good to hear! That's all I needed to know. Looking forward to further news as it comes in. Thank you Peter!
  13. I also experienced this issue first in December and only on Server 2019 systems (mix of virtual and physical servers) and again now in January, although it appears to have spread to 2016 servers as well. Server 2022 doesn't appear to be affected so far. As with others, it's a timeout on ekrn during the reboot following application of the monthly updates. Either manually starting the "ESET Service" or a second reboot will re-enable functionality. I would also add that I think it's rather disingenuous to simply point at Microsoft and wipe your hands of the issue. Even if it is something Microsoft did to cause it, at the very least, you should be working with them to figure out why and what can be done to resolve this, whether it's on their end or yours. All it takes is one moment of inattention on a customer's part and there's a public-facing server with no protection for who knows how long until the problem is noticed. I personally feel like if you have no intention of taking this matter up with them and getting it resolved, I'm going to soon be forced to find another vendor. This is too big an issue to just shrug your shoulders and live with indefinitely.
  14. After installing the most recent ESET Endpoint Security 9.1.2051.0 to a test grouping of clients, those clients are now shutting down after a scheduled scan with no post-scan behavior selected. This is occurring on both Win10 and Win11 clients. Event log shows: The process C:\Program Files\ESET\ESET Security\ekrn.exe (ComputerName) has initiated the power off of computer ComputerName on behalf of user NT AUTHORITY\SYSTEM for the following reason: Other (Planned) Reason Code: 0x80000000 Shutdown Type: power off Behavior is identical to what happened back in v7.2, as referenced in this thread: I've shut down the scheduled scans for now to prevent the computers from shutting down, but a quick fix for this would be very helpful as I don't like not scanning regularly.
  15. Sorry about the delay, but I had limited windows in which to test this on two of the three affected servers and just finished last night. To reiterate for clarity, no, I do not have ESET Inspect/EDR running in this environment. Only the Mgmt Agent and Server Security are on each system. I did exclude the MUI extension in the real-time protection setup and attempted the upgrade from v8.0.12013.0 to v9.0.12012.0 again on all of them. This time they all succeeded. What I don't know, however, is if that was just a fluke or not. I had not attempted any of those updates again before excluding that extension to see if they failed again. So in short, I would say it's a qualified yes that it made a difference. I still have a six servers to go. I've modified the bootmgr setup on the remote ones to enable F8 on boot in case there are any more problems so I don't have to have someone physically there to aid in recovery. If I do encounter any more problems (which at this point, would be with the MUI exclusion in place), I'll let you know in this thread. The rest of them will be done by this weekend.
  16. No, it is not. I made the change you suggested and tried installing the 9.0 update again on the three computers that had the problem. They all worked fine this time. Whether it had to do with that or not, I can't say of course since I hadn't re-tried before making the change.
  17. Seems way out of left field for the problem, but I'll assume this is familiar to you in some way so I'll go with it. Since this is causing an issue during the installation process, should I then be looking at excluding the MUI file extension in the Protect configuration covering the servers now, make sure they get the updated configuration and then resume installing and see if it happens again? And once the install is done, should I be leaving that exclusion in place to prevent future similar issues on updates or remove it once the updates are done?
  18. I started pushing the install of this version to my servers yesterday. Ran into a problem yesterday with 3 of the first 14 servers that I installed it on. I believe it happens on attempting to reboot as one of the servers affected has Faxback on it and that informed me that the service had been shut down right before it stopped responding to everything else. All were updated by using an install task as I usually do. All three failures had these same symptoms. The servers stopped communicating in any way except for ping. No RDP access, no SMB access, they wouldn't respond to anything else. Just ping. All are VMware virtual machines, running Windows 2019 (although I had other VMs with Win2019 that updated just fine) The VMWare Remote Console couldn't even initiate a CTRL-ALT-DEL to attempt to log in. On doing the virtual equivalent of pulling the plug and restarting, Windows would boot up to the point where it said "Applying group policy registry policy" and sit there forever with the same symptoms as described in #1 above. To recover, I had to do the following. Boot into safe mode with networking Run the ESETUninstaller.exe downloaded from ESET's site to remove ESET Server Security while in safe mode Reboot normally, at which time everything was back to normal with the VMs I then reinstalled the 8.0.12013.0 version that had been on it before. I have not yet tried the update on any of these servers again to see if I can reproduce the problem or not. Thought I should check to see if anyone else is reporting the same and, should I encounter this again on trying to update, is there anything I can do from safe mode to try to get you more information about what is going on?
×
×
  • Create New...