Jump to content

zombunny2

Members
  • Content Count

    12
  • Joined

  • Last visited

  • Days Won

    2

zombunny2 last won the day on September 10

zombunny2 had the most liked content!

Community Reputation

2 Neutral

About zombunny2

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Deathinition as I scrolled down this thread I knew you were using either Chromium or a Chromium-based browser. Are you, by any chance, also using either UBlock Origin or Nano Adblocker in it? I repeatedly get this detection from my Immunet install. The filename of the detection is always "f_" followed by a hexadecimal number, and it is always in my Vivaldi (another chromium-based browser) cache folder. In my case, it is a false-positive on one of the blocklists used by UBlock origin. Some of ClamAV and Immunet's signatures trigger on certain malicious web links in text files. UBlock's blocklists are text files filled with, amongst other things, fragments of malicious links (after all, UBlock needs to know what to block). Immunet, unfortunately can't distinguish between "my evil malware site dot com" as a place to go, contained within an evil script, and "my evil malware site dot com" as a place *not* to go, contained within a blocklist! It just sees the link and has to take the cautious approach. I get this same detection if I do a manual scan of my /home directory with ClamAV on GNU/Linux (the OS where I spend >99% of my time). In Vivaldi, there's also a built-in feature that blocks certain really aggressive malvertising features. Most browsers also use the Google safe-browsing database as well. Both of these features of course contain lists of web sites for the browser to avoid - and as a result, both of these features have also triggered this detection in my copy of Immunet before now. But most of the time (almost every time I get this detection), it's UBlock origin updating its filter lists. I can even repeatedly trigger the exact same detection by manuallly forcing UBo to update its blocklists.
  2. I had a quick look at task manager on my Windows PC a bit earlier. Immunet was using about 40-80MB - but it gradually rose to about 350MB while I was observing it. The PC was seemingly idle. However I looked at the "Windows update" dialogue, and it was performing an update in the background, so I think the memory spike was due to Immunet's realtime guard scanning lots of files. The above was measured with blocking mode on and all scanning engines enabled. I suspect that if you disable ClamAV and rely solely on the cloud engines (Ethos and Spero), your memory and CPU usage will decrease significantly - probably down to the tens of megabytes range. I rely on the ClamAV engine as I have an extensive set of custom signatures, so I leave it enabled. If you are always online, then the cloud engines alone will probably provide you adequate protection.
  3. I remember in earlier versions of Immunet, possibly circa 2.0 or 3.0, there was a bug that caused excessive hard disk usage. If I remember right, I think it was related to Immunet's internal logging (scan-result cache). If something caused the realtime guard to scan lots of files, or if the user initiated a system scan, Immunet would thrash the hard disk mercilessly and bring the whole computer to a crawl. Of course, people with SSDs didn't really notice (unless their SSD wore out). Perhaps some sort of regression has been introduced in version 7.0 that affects certain systems? I can confirm it's not happening on a Windows 10 pro machine with a Core i7 8700k. Is Immunet the sole AV, or a companion-AV? Perhaps the workstation's main AV and Immunet are both fighting for access to something, or scanning each other's temporary files, and detecting each other's file-accesses (causing some sort of scanning loop)? This is the only situation where I've noticed this happen in recent years.
  4. If you enable the ClamAV engine, your memory consumption will rise dramatically. I'm not currently logged in to a Windows machine, so I can't doublecheck my RAM consumption, but mine is never that high at idle - and I have the ClamAV engine enabled with numerous custom databases added manually to improve detection rates. The only time it rises that high (and higher) is when actually scanning lots of things (e.g. performing a scan, or installing a new program).
  5. Hello @nirmeshptl please see my post that is immediately above the one I quote here. It answers all of your questions. Thank you for your interest, but I no longer have the issue with 7.0.0.
  6. Are you using Immunet as your sole AV, or is it a companion to another AV? It may be that Immunet is quarantining that other AV's signature updates or temporary files. Does the location in your Temp folder always change? If it doesn't, you could simply create an exclusion for that file (as long as we can all be confident it's not a true detection of course). If your other AV monitors the Windows temp folder, you could, as a last resort, exclude the entire temp folder from Immunet's scanning - but that would cause a decrease in protection.
  7. Hi all! This is just a quick note to say that I completely removed Immunet, purged all its configuration files and quarantine, manually checked the hard disk for leftovers etc. - and then restarted the computer. I then did a completely fresh install of Immunet 7. I now no longer have the "Error 503" problem. I'd recommend those still having problems to try this, as long as it's not too much trouble for them to do it. Before you do so, make sure nothing valuable is sitting in your quarantine, and make a little note of all the scan-exclusions you added in the settings! I do wonder if the last Immunet in the 6.x series might have corrupted a configuration file somewhere. It might be that this bug has disappeared in version 7.0, and that users just need to refresh their installation.
  8. @Rob.Turner I can confirm that I can either see text or get a download prompt for every one of those links supplied. @ritchie58 Don't worry, I of course still allow Windows updates on my internet-connected machine. I have Pro so am fortunately able to defer any non-security updates for up to a year, which I recommend everyone should do before their PC gets bricked. It gives Microsoft a good chance at fixing the worst of their problems before their "improvements" reach your machine - unless the next broken update they release without testing just happens to be a security one... As a side note, When your Windows 7 reaches end-of-life, one option would be to just have a dual-boot scenario: Switch to GNU/Linux for anything that requires the internet, and keep your unsupported Win7 installation as-is, unpatched, for any obscure software you might still need to run occasionally, but can't get on GNU/Linux. You'd just need to keep the Windows 7 installation offline, for instance by disabling your network interfaces in the device-manager, or unplugging your network cables. I'm aware there's a learning-curve, it's a matter of personal taste, and It's not possible for everyone, but I'm about 90% of the way there. I used to dual-boot and value both OSs for their respective qualities, but I'm rapidly getting to the point where I just need to get the work done and Windows now gets in the way of that for me.
  9. I am already in discussion with Rob as he had spotted this thread Nothing odd was found in my log files, which leads me to conclude a recent Windows update has broken something yet again. It's getting that ridiculous, I've actually ditched all my Windows installations apart from one, which I need for a single piece of technical software. I also even use GNU/Linux at work nowadays unless I have to reboot to use a specific proprietary tool. The AV is managed at work, but I've noticed that out of all the machines, it only ever tends to break on the Win10 ones, and even then it's only after an update. Coincidence? I think not!
  10. I have sent a support dump on this issue. I initially thought it might be caused by my custom hosts file, but I have ruled this out (I restored the stock Windows hosts file, rebooted, and the problem persists). Another unusual feature of my installation is that I regularly stop the Immunet services, copy assorted custom databases into the ClamAV folder, then restart Immunet. I doubt this would cause issue (it hasn't in the past), but may make it difficult to interpet the logfiles!
  11. Hello Ritchie, yes still having the same issue. I get the exact same error message, but the ClamAV databases still update as if there's no problem. I also still get cloud detections when I scan my malware archive. I think this issue is simply related to Immunet checking for a new Immunet version. Cloud detection and database updates seem to be unaffected.
  12. Hello - For some reason the forums won't let me sign in to my account - but this is user zombunny. Just a quick note to say I have been having this exact same issue for at least 2 days, on Win10 Pro 64-bit with a fresh install of Immunet 6.5.0.11255 (no quarantine or settings data whatsoever backed-up from the previous installation). I also notice that the Immunet home page (but not the IPTray client) says "0 users protected from 0 threats" - I wonder if this is related?
×
×
  • Create New...