I'm talking about the "Action" column in the OSSS screenshot. Why the heck doesn't SS offer this? And I don't know where to download OSSS. Yes, I will not upgrade to a new version until they come up with huge improvements, and I'm not happy with their decision to remove skins.
One more thing - try to exlude processes of VPN on list of app which should be ignored by AntiNetworkSpy Module. I'm not sure if it will work but it's worth to do (Settings/Security).
There are plenty of apps in which you can manage all services both system and third party...I'm not sure if SS is aimed to do this, I don't find any reason. Why do you want to include App/Program Data folders to the list of Protected Folders?...there are folders with temporary contents created by almost all apps in system...its obvoius that you recive tons of popup-alerts about them...
Nope, still no remote network folder access. The VPN program itself is not the problem I think, see below. Well, tried this, took me quite some time, and I learned a lot. To reduce clutter, I first killed every process that isn't necessary to run Windows. After that I compared a connection attempt with SS Firewall enabled and a connection attempt with SS Firewall disabled. The big difference is the lsass.exe process, which only makes connection with 10.112.112.146 with SS Firewall disabled. lsass.exe does not show up in the CurrPorts log with the SS Firewall enabled, it looks like it's silently blocked or something. Code: 26-2-2016 17:33:12 Added lsass.exe TCP 10.112.112.146:49299 192.168.9.12:135 26-2-2016 17:33:12 Added lsass.exe TCP 10.112.112.146:49300 192.168.9.12:49167 26-2-2016 17:33:12 Added lsass.exe UDP 127.0.0.1:60748 *:* 26-2-2016 17:33:12 Removed svchost.exe UDP 0.0.0.0:49924 *:* 26-2-2016 17:33:14 Added System TCP 10.112.112.146:49301 192.168.9.15:445 26-2-2016 17:33:14 Added lsass.exe TCP 10.112.112.146:49302 192.168.9.12:88 26-2-2016 17:33:15 Removed lsass.exe TCP 10.112.112.146:49302 192.168.9.12:88 26-2-2016 17:33:17 Removed System TCP 192.168.1.16:49295 172.18.4.165:445 26-2-2016 17:33:18 Removed System TCP 192.168.1.16:49297 172.18.4.165:445 26-2-2016 17:33:18 Removed System TCP 192.168.1.16:49298 172.18.4.165:139 26-2-2016 17:33:19 Added svchost.exe UDP fe80::10d1:7d6b:1d82:c512:546 *:* 26-2-2016 17:33:21 Added svchost.exe UDP 0.0.0.0:60847 *:* 26-2-2016 17:33:21 Added svchost.exe UDP 127.0.0.1:60849 *:* 26-2-2016 17:33:21 Added svchost.exe UDP :::51275 *:* 26-2-2016 17:33:21 Added svchost.exe UDP ::1:60848 *:* 26-2-2016 17:33:21 Removed System TCP 10.112.112.146:49301 192.168.9.15:445 26-2-2016 17:33:21 Removed System TCP 10.112.112.146:139 0.0.0.0:* 26-2-2016 17:33:21 Removed lsass.exe TCP 10.112.112.146:49299 192.168.9.12:135 26-2-2016 17:33:21 Removed System UDP 10.112.112.146:137 *:* 26-2-2016 17:33:21 Removed System UDP 10.112.112.146:138 *:* 26-2-2016 17:33:21 Removed svchost.exe UDP 10.112.112.146:1900 *:* 26-2-2016 17:33:21 Removed svchost.exe UDP 127.0.0.1:49575 *:* 26-2-2016 17:33:21 Removed svchost.exe UDP ::1:49574 *:* 26-2-2016 17:33:21 Removed lsass.exe TCP 10.112.112.146:49300 192.168.9.12:49167 10.112.112.146 is already in the Trusted zones list. I tried to create a new rule for lsass.exe in SS, but SS will not allow me to. lsass.exe shows up in Windows Explorer, maybe lsass.exe is somehow blocked/protected by SS. Any suggestions?
I am not network savvy, but isn't port-forwarding required for it to work under certain circumstances ? In other words, perhaps port-forwarding is needed when using firewall - dependent upon the node type ? I am curious to learn...
Nope, VPN is an encrypted tunnel between two Local Area Networks over a public network like the Internet. https://en.m.wikipedia.org/wiki/Virtual_private_network No portforwarding required.
hello me too not expert in such as remote sharing .. also don't access similar setup but now to me you found the problem first contact spyshelter see what they say and about lsass.exe i can create rule for that under rules->general select lsass.exe from system32 then allow incoming outgoing network traffic then rule will be created or just add this C:\Windows\System32\lsass.exe in component path of creating rule also i think this good to allow other thin for this exe to prevent crashing system. other thing you can try is create trusted network rule for these port.both local and remote port TCP:139, 445 UDP:137, 138 or create allow port rule from 1 to 65535
I did contact SpyShelter indeed, I've been busy with them for a few weeks now, but they seem as lost as us on this specific issue. Maybe they can do something with the CurrPorts info. I simply cannot make a rule for lsass.exe, it does not show up in the SpyShelter dialog: http://static.tweakers.net/ext/f/APQXZjfM1cPiejjuSsWz94nt/full.jpg
I'm running Windows 7 Professional. I have entered lsass.exe manually, because the file doesn't show up in the SS file browser. The file shows up in Windows Explorer and the Command Prompt, but not in SS. The error message confirms that SS cannot see lsass.exe: lsass.exe Can't find the file. Check the filename and try again.
i am in Windows 7 Pro too.so i think SS have no right to read file? are you an limited user account?if so try admin account
SpSFW GUI is 32-bit. It cannot read\access 64 bit processes that use file re-direction (sysnative). That's what I was told by SpS support. For example, services.exe, lsass.exe, taskeng.exe, etc.
Can you guys check if SS passes the AWFT tool? It fails the second test on my system. If the new version doesn't work, you can also download an older version, see link 2. And of course you can also check out the other leak tests. http://www.atelierweb.com/products/firewall-tester/awft-download/ http://www.testmypcsecurity.com/securitytests/all_tests.html#TypesSecurityTests
This seems to be a major shortcoming of SS, it doesn't detect code injection into child processes, and can also not identify a process hollowing attack. And as you mentioned, the anti-exe feature should be improved, apps should not be allowed to execute system processes. Anyone? I have a feeling this is yet another flaw in SS. It doesn't control "network enabled process launch".
Actually, even if you do, they will often focus on other things. I think if they added a dedicated anti-ransom feature and improved the sandbox (protection against exploits), they would be able to generate more sales. They should also fix holes related to various leak-tests. Did you check out AWFT? http://www.testmypcsecurity.com/lea...5sk1=58ec0c9743adf6c4dbe53352982a8192f865b4f8
I suppose Datpol has its own development road map for SpS and SpSFW - and that's fine. There is a complete lack of in-depth infos on SpS - which doesn't inspire confidence in the products. What I find discouraging is no support forum with developer participation. Plus, explanations from support never answer my questions; I have always received one or two sentence replies - that don't fully answer my questions. For example, I ask "What specific limitations are there in the sandbox on 64 bit systems ?" Reply: "Sandbox not fully supported 64 bit system." So this whole rigmarole of trying to get technical answers regarding SpS leaves me with nagging doubts about the product; there are limitations with SpS - but that's not the problem. User understanding and knowledge of SpS limitations can overcome them. What one doesn't know about the product will result in an infection and data loss - so the best one can do is to educate themselves about it. However, there is virtually no in-depth resources. That leaves one final method - malware test and slug your way through it - and try to figure out its capabilities, operation and limitations. Of course, the user faces this situation generally with any security soft - from Avira to Zemana; they all do a less than optimal job of fully documenting their softs and, especially operational\functional limitations and unexpected behaviors. That's very frustrating...
@hjlbx Some good experience wth SS To isolate riskfull aps, it is possible to add an ALLOW ALL on FOLDER and set it to ALLOW FUTURE VERSIONS ALSO, then reverse this setting to a BLOCK ALL (so it effectively BLOCKS ALL suspicious behaviour on programs originating from that folder). Another nice feature is to AUTO ALLOW TRUSTED VENDORS. Because BLOCK overules AUTO ALLOW, you can turn SS HIPS into a behavioral blocker for selected vulnerable processes. Now this is not as good as system wide, but risk based blocking is nearly as effective as global blocking, with the ADVANTAGE to turn it into A ZERO POP-UP HIPS. Try it for yourself, set a BLOCK ALL on Chrome application folder. The AUTO-ALLOW will enable Chrome's updater to update Chrome without zero pop-ups, the BLOCK ALL will effectively Sandbox Chrome broker in a HIPS based policy container. Some bad experience with SS When you isolate an application, the HIPS module does NOT MONITOR that application anymore. Together with the lacking log reporting of isolated apps, this sort of spoils the effectiveness of that option. What I understood is that the developers introduced this feature because they were afraid they would not get the HIPS module to work under x64. Now they have found ways to implement this, they focussed on adding a FW first (in stead of being just another Sandbox application), which I can understand marketing wise.
I tend to consider this as a common problem of HIPS programs... I found that even on a 32-bit VM, many HIPS programs cannot capture and prevent process hollowing attack, including Comodo FW, ESET HIPS, Outpost FW, etc... I think this may be because it is quite difficult to implement an anti-hollowing feature in HIPS programs. Until now, in my own tests I only found two products that can prevent process hollowing attack on a 32-bit OS: Spyshelter FW and Excubits MemProtect. We have known that Spyshelter FW will also fail to prevent process hollowing on 64-bit systems. Some other people say that HMP.A is quite effective in preventing process hollowing, but I have not tested it by myself. Such a "standard" reply really makes me laugh.
@Windows_Security I am not following 1st part. Will have to experiment. 2nd part - about no HIPS\logging of sandboxed application - except for folder access - I agree. It makes the feature much less than what it can be. The bottom line is that Datpol don't listen so good... users suggest things to make SpS better, but a lot of very good suggestions never get implemented. What ? They trying to out-do COMODO in this regard ?
Do all of these ancient leak tests even work correctly on W8\10 ? I recall seeing a post on the COMODO forum stating that the COMODO Leak Test will generate erroneous results when tested against COMODO Internet Security itself. The premise of the post was that CLT is no longer completely valid on W7, 8 & 9. If that is true, then I would assume that would be the case with leak tests that were released almost 10 years ago - like the ones on My PCSecurity. The Matousec test suite is probably a much more accurate indicator of overall protection capacity, but configuring and using it is one heck of a rigmarole.