Jump to content

zombunny2

Members
  • Content Count

    85
  • Joined

  • Last visited

  • Days Won

    16

zombunny2 last won the day on August 2

zombunny2 had the most liked content!

Community Reputation

24 Excellent

About zombunny2

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. I would second Ritchie's recommendation to seek alternatives to Defender, even if the computer isn't really used for anything online. Windows Defender currently seems to get good reviews and provide good protection, according to some of the test labs, however there are three major problems with it: It's the built-in solution, so most malware will target holes in it, be designed to disable it, or will be specifically designed to evade its detection. Its historical record has been extremely variable and patchy. One month it has been the worst performer and the next, one of the top performers. It's not historically been consistent like the well-known names have. Its ransomware and exploit protection ("controlled folder access") is responsible for much of its apparent effectiveness, but is horrendously simplistic and aggressive. It even blocks built-in Windows features such as the commandline utilities format.com, chkdsk, xcopy and so on... It also blocks non-Microsoft browsers such as Firefox. In whitelisting these features, you essentially open-up each one of them to exploit. In order to have a usable system, I had to exclude Firefox, cmd, PowerShell and others from the "controlled folder access". This essentially opened-up the main vector for malware-delivery (the browser), and also opened-up the main two script interpreters used by ransomware, effectively leaving me with no protection at all. Additionally, I find it breaks most installation programs, because it doesn't allow them to save files or create shortcuts! If you really want Windows Defender, I'd recommend running it in tandem with MalwareBytes premium (with "integrate with security center" turned off so it doesn't disable defender), and make sure to disable "controlled folder access" within defender, as MalwareBytes would handle that part of the protection. You could also run MalwareBytes in tandem with Immunet, but Immunet will disable Defender (like virtually all other AVs do). You could also run just MalwareBytes, or just Immunet. Immunet's static file detection rate isn't the best, but it's sometimes better than Defender, and I think Immunet's behavoural blocking is less intrusive than Defender's. It certainly breaks your system less! Besides MalwareBytes, I've noticed Sophos Home Free works brilliantly alongside Immunet. Kaspersky free also works well, but I had stability issues until I put Kaspersky's folders in Immunet's exclusions, and Immunet's folders in Kaspersky's exclusions. F-Secure Antivirus (I haven't tried Total/Safe etc) works perfectly with Immunet too. Comodo Internet Security also worked well when I tried it a couple of years ago, but its behavioural/HIPS/firewall components are incredibly noisy and aggressive, so you have to use it a long time before it learns what's good or not so good on your system. If you want a lightweight solution, I'd recommend Immunet alongside either Voodooshield or NoVirusThanks OSArmor. Voodooshield is pretty noisy at first, but is free (gratis); I think OSArmor is far more polished and user-friendly, and worth paying for. Alternatively, just wipe the hard disk and install Linux Mint, Trisquel, or Debian, and have no worries about all this nonsense.
  2. Your query looks a lot like you are running Immunet in some sort of organisation or corporate environment. Immunet is targeted at home users, so you may find you can only accomplish what you need with the corporate "version", Cisco AMP, instead. Additionally, support is not provided to Immunet users in corporate environments. If you have already tried adding the relevant scripts and program components to Immunet's exception lists, and it still doesn't work, and you're not a home user, just buy AMP. To the best of my knowledge you can't add specific ports as exceptions in Immunet and it's not intended for having config changes pushed remotely (e.g. via Powershell) because those are the sorts of things home users don't usually need to do.
  3. I have found Immunet to play nicely with Sophos home free in the past. It worked with no exclusions added to either; however to be on the safe side, I excluded Sophos's "program files" and "programdata" folders in Immunet, and Immunet's (Program Files\Immunet, Program Files\Cisco\Immunet, Programdata\Immunet, Programdata\Cisco\Immunet) in Sophos. I also tried Immunet with Kaspersky home free and I seem to remember it worked OK but did require each being added to the other's exclusions list to be stable. On my Windows box, I currently use it in tandem with both F-Secure AV and Malwarebytes Premium with no issues (because Malwarebytes itself is also a "companion AV"). To ensure this will work with no problems, I enter each program and add the other two solutions' "Program Files" and "Programdata" folders as exclusions. You'd think it would drag it down but it works fine on a circa-2011 machine with 4GB RAM and a mechanical hard disk drive. That said, I don't use Windows much nowadays as am almost completely a full-time Linux user. The solution is probably overkill, especially for my limited usage, but it's a Windows box, it's the low-hanging fruit that all opportunistic crackers and social-engineering scammers go for. It's the weak point from which all my documents could get trashed or accounts compromised. I figure even it it's overkill, a year's protection from the two paid-for solutions still costs less than a single tank of fuel for your car.
  4. I love that you have kept that machine running so long, and that you still have a use for it! I still use a 32-bit Intel Atom netbook when I need an ultra-portable computer, but that's running Debian GNU/Linux now since XP support ended. You may be pleased to know that ClamWin has come back from the dead and the latest version of the ClamAV engine has been ported to it. I believe ClamWin still supports all Windows versions back to 98. There are only two downsides I can see: (You would also have this problem with Immunet) - The standard ClamAV databases main.cvd, daily.cvd and bytecode.cvd currently occupy ~430MB (at the time of writing) just on disk. In other words, loading them into RAM on your XP machine would consume almost all of its RAM, even before we consider the scanning engine, GUI components and Windows itself. In everyday usage I tend to experience ClamAV occupying around 1GB RAM when doing a scan of a directory, whether that's measured using Linux's "top" command or Windows' "task manager" utility. Therefore you may find that scans on your old XP machine simply don't run, or it pages to disk so much that it slows to a crawl. ClamWin doesn't do "on-access" scanning unlike most other AVs (including Immunet). You have to manually scan things yourself on-demand. Regarding the second downside, years ago I used to just do a daily full scan of all hard disks with ClamWin and a periodic (e.g. hourly) scan of the running processes in memory (ClamWin's "memory scan" option, similar to Immunet's "flash scan"). For an internet-connected machine in the modern day, this wouldn't be enough, but for your offline XP machine I'm sure it'd suffice, even if inconvenient. Regarding the first downside - if you can find some old SDRAM on online auction sites, old computers your friends have in the attic, or even your local computer repair shop*, just max out the RAM on your board. If you get it to 1 or 2 GB you'll probably find it'll run adequately. *A few years ago, an independent repair shop near me still had a few AMD 486-DX4 CPUs and 4MB sticks of RAM in stock. Your PIII's RAM is a lot more modern (probably PC100 SDRAM). You might find your PIII can cope with 4 sticks of 256MB (or possibly even 512MB) each of this stuff, giving you enough of a total to fire-up ClamWin. Good luck!
  5. P.S. to anyone that may have PM'd me about this issue, I'm not ignoring you, I just can't get access or reply on this forum software as it doesn't work properly. I can just see the preview that gets sent to my e-mail. Will keep periodically trying...
  6. Update: I have just tried Immunet on 2 different machines, and my previous trick of enabling ClamAV and database updates, but not blocking mode, and waiting for ages doing nothing, seems to have resulted in an initial download of the databse files main.cvd, daily.cvd and bytecode.cvd on both machines. Now, clicking "update now" from the GUI correctly results in the message "virus definitions are up to date". This is a very strange and intermittent issue. Maybe it is something to do with connectivity issues, especially since it began around a similar time to the ClamAV infrastructure no longer allowing database downloads via wget or a web browser. Having said that, the fact that a database download is attempted but fails to be applied seems rather odd to me, and would suggest it's actually an infrequent issue to do with write permissions to the Immunet installation folder (possibly Immunet's self-protection mechanism?). Anyway, I now have 2 Immunet installations where the ClamAV virus database has updated successfully at least once. Very strange but worth investigating by devs.
  7. I've just tried the latest 7.4 version of Immunet, and the ClamAV update bug is still present. Enabling ClamAV and virus db updates should result in Immunet automatically downloading the main.cvd, daily,cvd, and bytecode.cvd files to %programfiles%\Immunet\clamav\[clamav-version]\ . No cvd or cld files appear anywhere on the partition where Windows is installed, tested over a period of several hours. Manually checking for updates from the Immunet GUI (main screen --> update now) results in an attempt to download the ClamAV databases (starting with daily.cvd), however this reaches 100% and then terminates with the error "The updates could not be installed. Please try again later". This always fails (the error is consistent). None of the various kluges or workarounds I've previously tried with older 7.x versions work any more. Meanwhile, a plain ClamAV installation updates flawlessly via freshclam. So just a warning to other Immunet users - you probably have no offline protection at all (or severely outdated offline protection). And a request to devs to actually fix this longstanding issue. Steps to reproduce: 1. Install Immunet on a fresh W10 x64 PC or VM. 2. Enable ClamAV and db updates, if not already enabled. 3. Wait for database to be downloaded, and/or manually update via "update now". Works on every machine I've tried so far, for the past few Immunet versions. What's most concerning (apart from the very longstanding nature of this bug) is that the failure is silent, unless the update has been triggered by the GUI. The silent failure potentially leads users into a false sense of security, thinking they have protection via ClamAV when in fact they don't.
  8. Many generic Windows installers can be called from the "run" dialogue (SUPER + R) or from the command prompt with the "/silent" option. It's generally undocumented and support is not universal, but it sometimes works. So, if the Immunet installer is called "setup.exe" and resides in the root of drive D:, you'd hit SUPER+R, and type "D:\setup.exe /silent" in the box, then hit enter/OK. Other commandline options that may get you what you want: /silentinstall or /verysilent or /y I've not tried any of the above but I've seen and used them for various other installers. I'm fairly certain Chocolatey makes use of this trick for most installers, so you may want to see if you can find Immunet's NuGet install script on Chocolatey's web site to see how it calls Immunet's installer. To deploy this on another machine, you'd have a .bat file calling the installer with the correct commandline option, and run that instead of running the installer directly. This does of course sound a bit like you might be managing some sort of commercial deployment, so if this is the case then AMP will suit your needs better and is of course licenced and supported for such scenarios. Sometimes it's worse to use the wrong tool for the job than to just not do the job at all. If something's worth doing, it's worth doing right. If you're doing this for an organisation, just get AMP.
  9. I suspect that adding Adobe's "program files" directory will do little or nothing to alleviate your problem, unless it also uses that location for its cache. Do you know (or know how to find out) where your Adobe software stores all its cache files? Seeing as all the file reading and writing is causing Immunet to repeatedly scan everything as it's read/written, you need to find out the location on this disk where all the reading/writing is taking place. I.e. you need to find the directory that Adobe uses for its cache. If you exclude this directory, you may find that performance returns to normal acceptable levels. Good candidates to watch would be any "Adobe" related folder that resides within %programdata%, or see if Adobe creates an "Adobe" folder within %temp%. In the meantime, you can speed up your systems slightly by de-activating the ClamAV engine, and/or blocking mode - however the former will decrease your offline-protection and the latter will decrease your overall protection. Good luck.
  10. I've just had a look at the Blackmart app description and I'm not surprised Immunet's quarantining it. It's an unofficial app store, so contains code to download other apps - hence might have code similarities to trojan droppers. So could be a false-positive. But there are much bigger concerns with this app: It's worth noting that Blackmart's description says it makes-available cracked versions of premium software. I'd therefore suggest you don't use it as you're far more likely to get a virus or trojan in cracked software and the app-stores that promote such software. Shady developers of cracked apps already have less morals, therefore are more-likely to insert malware to further their own ends. They have no problem stealing from developers, why would they suddenly develop a conscience when faced with the choice of stealing your bank details or uploading your nude selfies to porn sites? They also come into contact with other shady developers and shady apps more often, therefore are more likely to have been compromised themselves, and therefore are more likely to unknowingly be inserting malware into their apps. I'd recommend steering clear. There's no need to ever crack an app when there's almost-always a freeware or free/open-source app with the same functionality. Try to stick to app-stores such as F-Droid (free and open-source), UpToDown (virus-scans their apps and supplies legitimate apps), the /e/ store (legitimate apps) and Aptoide (if you stick to the verified apps and avoid cracked apps, there are a few security checks performed on them). If it's a particular game you want to crack, or something else that you can't really find an equivalent to, make your decision: it's either worth paying-for or it's not worth playing at all.
  11. You're right, an Android .apk will not harm a Windows system, as Windows can't execute an APK by itself, without an Android emulator. However, it's common (and a bit of a courtesy) for virus scanners to detect malware for other platforms - ClamAV, the engine that powers Immunet's offline detection capabilities, wouldn't exist if this wasn't the case, as it was originally developed for Unix-like platforms at a time when viruses for these platforms were simply not observed in the wild. The ability to detect threats in .apk archives is therefore handy for people who sideload apps on to their Android devices using ADB, etc. - Just as scanning a word .doc on your BSD or Linux system helps prevent you passing an infection on to a Windows user when you send it to them. If you don't know where the APK file is coming from, I suspect a web site is dropping it on your computer in an attempt to infect you. Most web exploits used to target Windows, but with the massive amount of Android devices now, as well as the fact that manufacturers stop releasing security-patches for them far too early, this means that there are millions of people browsing the net on insecure Android devices, which makes them a desirable and easy target, much like Windows used to be. One of the web sites you're viewing may have been compromised, (or more likely, the ad network displaying ads on it has been compromised) and it's speculatively dropping an infected apk onto your machine, in the hope you're an Android user who can get infected. Immunet rightly detects the apk and attempts to quarantine it. If the site deletes it before Immunet has had the chance to quarantine it, then quarantine will naturally fail. Also, if Immunet is your secondary protection, your primary protection might neutralise it before Immunet gets the chance, resulting in the "quarantine failed" message. If you have downloaded the APK manually yourself, there's a good chance that the .apk file is compromised and has a trojan in it along with the legitimate program. Sometimes it's a malicious download where someone's compromised a popular app and uploaded it to one of the many download sites - and sometimes it's the developer's fault because they often bundle in telemetry and adware into apps (especially gratis ones). After e-mail, the biggest vector I've ever seen for malware-distribution is the advertising/tracking networks. You can embed an ad in your website or app one day, thinking it's clean - but the ad will be different each time it's viewed, and each time is an opportunity for a malicious ad to get displayed. The ad networks don't care so don't check their own ads before serving them. Again, this will result in a detection from Immunet and a quarantine-failure if either the file is deleted or your primary AV cleans it, before Immunet gets the chance. It might be worth doing a full scan of your system with Immunet, and then another with your primary protection (and/or Windows Defender) to root-out anything stubborn. Don't use your computer until the full scans are all complete, and try to close anything you can that's running in the background before you do the scans (temporarily close/exit any unnecessary tray icons like Skype, your printer software, your Sat Nav updater, iTunes, and so on).
  12. If you are running Immunet in parallel with another AV like Norton, you can safely disable the ClamAV module in Immunet. ClamAV is very CPU-intensive, and you may find that this is the component that's causing the CPU-spike. I personally leave ClamAV enabled, because I often add custom signatures to it - but it does really hammer that CPU. You should also make sure you've gone into Immunet's settings and excluded Symantec/Norton's directories under %programfiles%, %programfiles(x86)% and %programdata% as relevant/necessary. You may also want to add Immunet's folders to Norton's exclusions (these are %programfiles%\Cisco\Immunet, %programfiles%\Immunet, %programdata%\Cisco\Immunet, %programdata%\Immunet if you are running 64-bit). I'd be willing to bet a lot of your trouble is Norton and Immunet scanning each other whenever they do anything. As WilliamKing321 states, updates and things also cause this behaviour. I know when my W10 is running an update because Immunet in particular starts consuming massive resources scanning it all. And seeing as I'm a fairly infrequent Windows user, this is very noticeable every time I have the misfortune of needing to boot that operating-system.
  13. Oh, and by the way, I forgot to mention Ritchie, it goes without saying that all the work you do on these forums is really appreciated. It must be pretty hard as it's probably quite a frustrating and thankless task, but the fact you haven't given up is an absolute godsend to the remaining loyal users! I try my best to help too, but you seem to have super-powers and have usually already solved someone's issue before I've even read their post!
  14. I have done a little more investigating. It seems that on a fresh install, attempting to run an update manually from the gui ("update now") fails if ClamAV is enabled and it's a new, fresh install that hasn't updated before. If you leave it for a while to silently-update, the process then seems to be "fixed" (i.e. works as expected). I've tried on a couple of PCs now. Basically I install Immunet, disable ClamAV, blocking-mode, and ClamAV updates, and leave it for a few minutes. I then re-enable ClamAV and ClamAV updates, and again leave it for a few minutes. Then, triggering an update in the GUI seems to result in the statement that "everything is up to date" - and indeed, checking the ClamAV subfolder within Immunet's program folder, reveals that main.cvd, daily.cvd and bytecode.cvd are all present with a recent timestamp. Finally, I re-enable blocking mode. All seems OK. On a slower machine, you can actually tell when this first automatic update happens in the background, because when ClamAV first verifies/loads the database, it will consume a lot of CPU for a moment, causing the machine to be less responsive, and causing Immunet to appear frozen/not responding for a few seconds to a minute. Then, all is well. I'm not sure why updates were temporarily broken on my older installation though.
  15. Haha thank you Ritchie! I'd of course "like" your posts, but until you mentioned it I didn't even know how you gave other people "likes" on here! Will give it a go on your post. I don't always keep Immunet installed, but I do pop on here occasionally to check on its progress and to help other users as I really want it to succeed. It's lightweight and minimalistic, doesn't require an account in order to use, and optionally uses the ClamAV engine, which I find indispensable as it means I can add custom signatures. TL;DR I really like Immunet when it works, and I don't want to stop using it!
×
×
  • Create New...