dylanm

Description: Global overrides and better config management for Endpoint/Server Security products. Details: The typical power user/administrator when setting up the protection products starts with the advanced configuration at the top level in Detection Engine and you're presented with Real-Time & Machine Learning protection settings. These act as a sort of global configuration for the rest of the product. After configuring the base product (or is it the real-time configuration in Detection Engine?), the next item is to configure the Real-time file system protection, then Malware scans (skipping cloud protection). In the Malware scans setup we're presented with On-Demand scanning profiles, Idle-state profile, Startup Scan profile and the Document protection profile. Currently, any On-Demand scan profile's first real setting is whether to use the Real-time file system protection settings. This is very close to a global setting or default configuration that I'm certain pleases many users. My feature request is to extract that setting concept (a reference/pointer), and then combine that with an added base on-demand/event scan profile that every other profile references. The base config concept could also be combined with the Policies concept from the management server, with each option becoming ignored, set as default, or forced. The base scan profile would include all the protection categories, threat sense parameters, scanner limits, and the system's Other ( scan ADS, preserve timestamp, etc. ) settings. Rationale: Consolidates the 3 to 7 to X number of places to change settings when deploying or configuring the product. Doesn't lock users in via policy (not always the desired effect). Potential to protect user's from bad ESET settings (automatically modifying the last accessed timestamp for example). Description: Add a configurable scanning profile for AMSI scanning. Details: If Document Protection, an API based scanning integration, gets to have it's own scanning profile then shouldn't AMSI scanning get the same treatment as well?

Description: Add learning rule aggregation and analysis. Details: HIPS has a learning mode and so does the firewall. It would be great if the management server could collect all of the learning data from all (or select) managed clients and present it in one big workbook that labeled how many times a learned rule was hit and on how many clients. If related rules are created (or hits are logged) across multiple clients it should be possible to automatically or with assistance create simplified rules by combining similar ports/port-ranges/program names/source or destination addresses and so on.

Description: Edit Endpoint/Security Product configurations and other Policy improvements. Details: Currently the only supported way of remotely editing the underlying configuration of an installed Security Product is to use a Run Command task and ecmd to import a configuration. This is annoying since you have to already be in possession of a desired configuration in .xml format. If you aren't in possession of an .xml file as a template to write a new configuration you have to obtain one by running an ecmd export task and then remotely pull the file. An admin can request the configuration from a machine but that configuration also includes applied policies. A requested configuration can be downloaded as a .dat file which is not so secretly a base64 encoded json file. There is no way to convert a downloaded json/policy to a product configuration xml. For server products it is possible to script eshell to change configurations, except that eshell isn't bundled with client endpoint protection products. The whole ecmd process is a hassle and then on top of that you're editing an xml file. Feature requests: Add the ability to export/download product policy to a product .xml configuration file. Add the ability to import a product configuration file to a policy. Add the ability to merge two or more policies of the same product. Add the ability to view the difference between two product configurations/policies. Add the ability to convert an existing policy for a product to a policy for a different product. For example: If I wanted to convert an ESET Server Security for Windows policy to an Endpoint policy, where the configurable components are probably 90% identical, I should be able to select it as action from the policies menu or the edit menu. After it is converted there should be a note somewhere saying that incompatible settings, like OneDrive scanning, were dropped in the conversion. Add the ability to edit a product's configuration on a computer from the ESET Protect administration page. Just like editing it from the computer itself. Ship protection products with a read-only copy of a default configuration for the product. Ship ESET Protect console with copies of default configurations for the programs it manages. Either a UI option to download a configuration or keep copies in the install target directory or the application's data directory. Add a security product task to set a product configuration to a provided policy (like configuring All-In-One installers). Add a security product task to set a product configuration to a given .xml file (essentially ecmd import except as an actual task). Add a security product task to reset a product's configuration. Task settings for: Resetting the whole product configuration. Ability to select individual modules/sections to reset to their defaults. Ability to ignore or reset HIPS rules, firewall rules, exceptions and so on. Any of the detailed configuration rules/lists that get prepended/replaced/appended should also be configurable for a reset.

The Endpoint firewall has some pretty good features when it comes to zones/profiles/rule matching. It would be a great addition to the Windows Server products since the Windows firewall falls short for advanced scenarios such as multi-homed machines. I would use it for servers, even if it came in a separate installer, with a giant hazard label that said it wasn't stable enough for servers, and was entirely unsupported by ESET.

Description: A feature that acts like a peer to peer version of the shared local cache for Endpoint/File Server Security products. Details: Take a standard file client/server scenario where a document/file server has any number of clients connecting to the server and all the machines are protected by Endpoint or ESET Server File Security product with default settings. If my memory serves correct, the default settings for both products are to scan network files on open/create/modify/execute operations. That would mean that for every network file operation, scanning is taking place on both the client and the server (or each peer). That would mean that every file is scanned twice on every file operation over the network (in theory anyways). To speed things up it would be beneficial for file servers to send and receive cached scan results for files on the server as they're being accessed by clients. In the future, the communication could be used to further optimize network file operations by allowing either the client or the server to perform scanning operations based on processing speed or load. At the very least I'd like to see ESET's File Server products have the option of running a scan cache for Endpoint products to optionally connect to when performing networked file operations. What would be even better is if all ESET business products receive the capability to cache results for other networked ESET clients under the same administrative control. The net result would be another reason to ignore the shared cache appliance for local networks and hopefully faster networked file operations in general.

Description: Enable more advanced configuration and control scenarios for administrators via the command line. 1. Add eShell to Endpoint software. Details: Adding the text based interface to the Endpoint client software will allow administrators to script the product and remotely access and configure the product without interrupting end user activities. 2. Add WMI classes for interacting (reading/writing settings and configurations) to security products. Details: Expand upon the existing WMI support by allowing clients to configure security products using WMI/CIM interfaces. 3. Add a powershell module to security products. Details: Tools that would further allow for configuring, testing, troubleshooting and working with the security products. A powershell module would complement the existing eshell tool and would further enable advanced administration with the tools administrators are using. WMI tooling would allow for other tools to work with security products outside of the small handful of RMM integrations. ---------- Description: Make ecmd more useful. Add a list/help parameter to ecmd. Something to list all the available commands. For example: -h --help /? /help /list /listcmds Add a reset configuration parameter. ecmd /resetcfg to reset the product to it's default configuration. Maybe add a parameter to get the default config as an xml file. Something like ecmd /getdefaultcfg <filename.xml>. ---------- Description: Add profile selection to ecls or add a new command line scanner that uses profiles and outputs to the application's log. Details: If adding eShell doesn't get added to Endpoint, add a "profile" parameter to the ESET command line scanner program so that users don't have to try to configure the command line scanner to emulate a predefined scanning profile. Alternatively a new command line scanner that simplifies the ecls experience but also fits nicely with remote management would be nice. Currently ecls has options for specifying where to quarantine/log/load modules which is all very advanced and most people don't need. I think a scanner that uses the same profiles and logs as the main application would be a lot more friendly to end users and administrators. Example: > eclods.exe ESET Command Line On-Demand Scanner Usage: eclods [SCAN PROFILE] [OPTIONS..] FILES.. [/exclude] FILES.. Scan Profiles: Profile names should be quoted. Alternatively spaces can be replaced with underscores ( _ ) or dashes ( - ). Smart scan The Smart scan profile uses Smart Optimization caching, which excludes files that were previously found to be clean. Context-Menu scan You can start an on-demand scan of any file from the context menu. The Context menu scan profile allows you to define a scan configuration that will be used when you trigger the scan this way. (default) In-depth scan The In-depth scan profile does not use Smart optimization by default, so no files are excluded from scanning using this profile. Computer scan This is the default profile used in the standard computer scan in eGUI. Custom scan profile names can also be specified. Create custom scan profiles in the product graphical user interface. Options: /subdir scan subfolders (default) /no-subdir do not scan subfolders /log-file=FILE log output to FILE /log-rewrite overwrite output file (default - append) /log-console log output to console (default) /quiet do not output to console Files: If no files are specified the profile's predefined targets will be used.

This has not been fixed in the recently released 7.1.2053.0 but was fixed in ESET NOD32 Antivirus, ESET Internet Security and ESET Smart Security Premium version 12.2.23.0 according to the release notes. It is taking an exceptionally long time to publish a patch for an issue that consumes CPU and interferes with normal desktop usage when the issue was supposedly identified and patched in April/May.

I just had a 32-bit Windows 7 computer BSOD on me. Checking the dump gave me epfwwfp.sys as the culprit and IRQL_NOT_LESS_OR_EQUAL as the issue. Can anyone tell me whether this is the same issue as outlined in https://support.eset.com/kb2567/ which can be fixed by applying this https://support.microsoft.com/en-us/help/2664888/ hotfix? Here's the seemingly relevant bugcheck info: IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 0072006f, memory referenced Arg2: 00000002, IRQL Arg3: 00000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: 83a18fa9, address which referenced memory FAULTING_IP: hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+29 83a18fa9 8902 mov dword ptr [edx],eax TRAP_FRAME: 83b80950 -- (.trap 0xffffffff83b80950) ErrCode = 00000003 eax=83b80a04 ebx=86c0c3a8 ecx=8a6b8574 edx=0072006f esi=8a6b84e8 edi=8a6b85a8 eip=83a18fa9 esp=83b809c4 ebp=83b80a30 iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282 hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0x29: 83a18fa9 8902 mov dword ptr [edx],eax ds:0023:0072006f=???????? Resetting default scope LAST_CONTROL_TRANSFER: from 83a18fa9 to 83a92623 STACK_TEXT: Page a8ba4 not present in the dump file. Type ".hh dbgerr004" for details 83b80950 83a18fa9 badb0d00 0072006f 00000000 nt!KiTrap0E+0x353 83b809c0 9e40417b 83b8acc0 83b80aac 00000000 hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0x29 WARNING: Stack unwind information not available. Following frames may be wrong. 83b80a30 9e403cdb 83b80a7c 83ab7a7a 86c0c3f0 epfwwfp+0x417b 83b80a38 83ab7a7a 86c0c3f0 86c0c3a8 c9620c18 epfwwfp+0x3cdb 83b80a7c 83ab7a1d 80b96120 83b80ba8 00000001 nt!KiProcessTimerDpcTable+0x51 83b80b68 83ab78da 80b96120 83b80ba8 00000000 nt!KiProcessExpiredTimerList+0x101 83b80bdc 83ab58aa 0093dd47 877b2030 83b8acc0 nt!KiTimerExpiration+0x25c 83b80c20 83ab56c2 00000000 0000000e 00000000 nt!KiRetireDpcList+0xcb 83b80c24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46 THREAD_SHA1_HASH_MOD_FUNC: 6c7bfcddebf5ec77ecef028d4c0bc84b2c5c706a THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 0861c39d7c4013f1434a247142212272a8e0c777 THREAD_SHA1_HASH_MOD: 499ccb1114d9c774835e65a03d3aa1e4c4282652 FOLLOWUP_IP: epfwwfp+417b 9e40417b 8b86b8000000 mov eax,dword ptr [esi+0B8h]