VPN and open ports

[TheLyppardMan]

Once you use third-party firmware, things always become more complicated, because that opens the door to questions for things you wouldn't either have known to ask, or cared to know in the first place. Third-party firmware is just another red pill experience!

DNS has nothing to do w/ this. These tools are firewall penetration testing tools. And they do the job as intended. But the question you always have to consider is *which* firewall is actually being tested! There can be multiple firewalls between your home router and the GRC servers. You can't just assume there is only your router's firewall. And so each firewall between your router's firewall and the GRC servers acts as a filter. And you end up w/ misleading results if you assume failure on the test means there's necessarily a problem w/ your router's firewall. In all likelihood, there isn't. But it can be disconcerting when you see failures and don't recognize what's actually happening.

The firewall rules I provided are quite simple. The PREROUTING chain of the raw table is always the first thing any packet hits when encountering the router's firewall. All the rules do is *count* the packets seen for any given port (or icmp/ping). If you use Shields Up and afterwords see any w/ zero packets, it means the packet never reached the router's firewall. Something upstream (presumably another firewall) blocked it. It's just that simple.

So, do I just use the code you provided in #14 and also, what results would you expect me to see if things are as secure when using a VPN and when not using a VPN? I did follow the link you provided, but I have to admit that by the time I got to the bottom of the posts, I was more confused than ever about what was trying to be achieved. Also, do I have to create a file to put the code into a file or do I have to do it another way and did I read it right that simply rebooting the router deletes all this extra code?
I'll have another look at this tomorrow as it's getting late and I haven't had much sleep for the past couple of nights.

 

[eibgrad]

The purpose of the code I provided is NOT to determine if you are safe wrt any given ports or even icmp (ping). It's to determine during the probes which of those ports and icmp is able to even reach your router's firewall. As I said, if any of the rules report zero packet counts, it means something upstream (presumably another router's firewall) has either blocked or responded to the probe for that given port (or icmp). That's important in being able to accurately interpret the results of the probes as reported by GRC. If for example, the upstream router intercepts the ping request and responds positively, GRC will report it as a failure of stealth. But it's NOT due to your router's firewall if it shows zero packets for icmp/ping! It's due to the presence of the upstream firewall.

To use the code, you ssh to the router and copy/paste it into the terminal window. Depending on the router, it may take a few seconds to apply all the rules (there are 1025 of them in total, so be patient). You then perform the probes w/ GRC and dump the rules to see which ones report zero packets (I provided the output from my own testing as an example).

Ultimately you're looking for anything where GRC reports a failure of stealthiness ***and*** your router's firewall is showing a NON zero packet count for that specific probe. That proves the probe reached your router's firewall and is the one responsible for the failure as seen by GRC. Now you can look into why that's happening (e.g., perhaps you have ping enabled on the WAN). OTOH, if it shows a failure and a ZERO packet count, there's nothing you can do about it. The upstream firewall is acting preemptively wrt your own router's firewall to handle the probe.

Once you're satisfied you have the necessary information, you can either reboot (the rules are NOT persistent across a reboot) or just flush the PREROUTING chain of the raw table (there's usually nothing else there anyway).

iptables -t raw -F PREROUTING

 

[TheLyppardMan]

The purpose of the code I provided is NOT to determine if you are safe wrt any given ports or even icmp (ping). It's to determine during the probes which of those ports and icmp is able to even reach your router's firewall. As I said, if any of the rules report zero packet counts, it means something upstream (presumably another router's firewall) has either blocked or responded to the probe for that given port (or icmp). That's important in being able to accurately interpret the results of the probes as reported by GRC. If for example, the upstream router intercepts the ping request and responds positively, GRC will report it as a failure of stealth. But it's NOT due to your router's firewall if it shows zero packets for icmp/ping! It's due to the presence of the upstream firewall.

To use the code, you ssh to the router and copy/paste it into the terminal window. Depending on the router, it may take a few seconds to apply all the rules (there are 1025 of them in total, so be patient). You then perform the probes w/ GRC and dump the rules to see which ones report zero packets (I provided the output from my own testing as an example).

Do you mean the code in post #16 and if so, how do I use it? Do I just copy it and SSH into the router with one of my usual utilities (WinSCP & Xshell 7)? I want to make sure I have the correct procedure before I try to use this. Also, what do you mean by "dump the rules"?

Ultimately you're looking for anything where GRC reports a failure of stealthiness ***and*** your router's firewall is showing a NON zero packet count for that specific probe. That proves the probe reached your router's firewall and is the one responsible for the failure as seen by GRC. Now you can look into why that's happening (e.g., perhaps you have ping enabled on the WAN). OTOH, if it shows a failure and a ZERO packet count, there's nothing you can do about it. The upstream firewall is acting preemptively wrt your own router's firewall to handle the probe.

Once you're satisfied you have the necessary information, you can either reboot (the rules are NOT persistent across a reboot) or just flush the PREROUTING chain of the raw table (there's usually nothing else there anyway).

So just to be clear, I copy and paste the line of code into one of the utilities I mentioned above?

iptables -t raw -F PREROUTING