Hi Peter,
Adding that inbound rule to System doesn't solve it - just tried connecting from another machine via both the No-IP host and my real IP and both connections were permitted. When creating the inbound rule, I also set it up so that it'd log a security event when the rule is triggered, but found nothing in the firewall history.
In the meantime, I'll revert to adding the computer as Restricted in the Trust Control.
I still suggest this may be a bug (perhaps specific to me, even though I haven't done anything special aside using Hamachi).
Is there any way to properly solve this? I have a feeling that a restricted trust control might cause problems with the program rules I have in place...
Thanks.
Bumping this again.
After other tests, it appears that while the computer's access in the Trust Control is set to Restricted, the following things happen:
- I can't connect if I'm using new IPs.
- I CAN connect using any IPs I've made rules for in the past (my workplace has several IP addresses which I've configured the firewall to allow RDP traffic from).
- I can always connect if I'm using the NO-IP virtual hostname.
Concluding, I suspect that:
1. The previous rules may be still in efect, even though I have deleted them, restarted the firewall and even reinstalled without keeping the settings. Is there anyway I can dump the firewall rules to a file so I can pass them to support for analysis?
2. The NIS firewall can't apply rules to connections targeting the NO-IP vDNS, which is, I guess, normal because most personal firewalls have rulesets for local subnets (and the no-ip might appear as a different, unknown subnet). Can anyone confirm this, please?
fauxpride wrote:
Hi Peter,
These are the system rules I have after I've reinstalled:
I have created an inbound rule for the custom RDP port I use - will test to see if it works when I get to another machine.
A question though - If I ever want to allow RDP again for a certain IP, will a custom traffic rule for that IP override this system rule?
Thanks.
Your use of a custom RDP port may be an issue here. That port may be valid for the connections you are making through VPN, but anyone else trying would be using the standard port to connect. You have to remember the SmartFirewall in Norton products is designed for home users who do not set up detailed custom rules.
Can you try reconfiguring your RDP to the standard settings again, and then test the access rules again?
I'm sorry, but this is not acceptable.
Using RDP on the default port isn't really an option - portscans on 3389 can expose my machine to the internet and it's a well known fact that RDP encryption isn't the strongest, not to mention that it's easily one of the most targeted protocols for vulnerabilities.
I also stopped using Hamachi (their free client is basically useless) so right now I'm only being able to use RDP directly over the internet until I setup another type of VPN for tunnelling purposes.
Normally, NIS should stealth 3389 (along with all standard/sensible ports), but I don't feel like leaving that to chance, given the risks.
Also, the fact that creating custom rules are supported by the NIS firewall should imply that they should also be working. Every personal firewall I know of supports custom rules and at this point they're a standard feature, not something only meant for advanced/enterprise use.
Furthermore, the finds I detailed in post 22 indicate that this looks more like a bug, not as an intended functional side-effect.
Have you tested your machine's 'vulnerability' with the default settings using the Shields Up from Gibson Research? https://www.grc.com/x/ne.dll?bh0bkyd2
Try resetting your port settings to defaults, have your NIS fully updated, and run the Shields Up scan.
Please share the results with us.
With all due respect, I was expecting a more knowledgeable answer than that.
I don't think we're on the same page; the vulnerabilities I was referring to do not pertain to the general meaning of "breach in the computer's defense", but to more specific security weaknesses in the RDP protocol and client implementation.
These are generally programming mistakes that allow remote code execution on the target machine - the only way to defend against these is to either make sure you have your machine up to date with the latest patches (that fix them) or, in this case, completely hide the presence of the vulnerable service from the internet.
Hiding RDP from the internet is generally a better idea because it's also a way to prevent 0 days (vulns that aren't known to the software vendor yet, so no patches are available for them). There are underground markets that pay hefty for 0 days, and software companies also reward whitehats for finding them.
That ShieldsUP test is really old and is basically a really simple port scanning tool that checks if your port is stealthed and if it can respond to pings. The default test sets don't even check for the RDP port. There are other far more complex pentesting tools: metasploit, shodan, core impact, SQLninja, w3af to name a few.
The only thing I'm asking is for someone to officially confirm whether this is a bug or not, and if it's not, let me know how to fix it.
Thank you.
First a quick reminder that most posters here, including myself are just volunteers trying to help others by passing along our experiences with the Norton Products. Norton employees have their names in Bold red letters.
I will have to defer to other users here that may have more information that applies to the specific questions you have.
I was just trying to suggest a path to try to diagnose the issue.
edit: remove unconfirmed information.
peterweb wrote:
First a quick reminder that most posters here, including myself are just volunteers trying to help others by passing along our experiences with the Norton Products. Norton employees have their names in Bold red letters.
I will have to defer to other users here that may have more information that applies to the specific questions you have.
I was just trying to suggest a path to try to diagnose the issue.
edit: remove unconfirmed information.
I apologize if my earlier post sounded derogatory. I was just annoyed that I couldn't get answers to fix for such a crucial issue and a got a bit carried away.
In the meantime, I realized that when I created the rule that Peter Linhardt suggested I hadn't moved it on top of the list so it can take priority over the other overlapping rules. I did that and now the connection is properly blocked. I still don't get a security entry in the logs entry when it's blocked, but for now the fact that it works is good enough for me.
Thanks to everyone who helped troubleshoot the issue.
Glad to hear you figured it out.
We are here if you need us again.