I ran Shields Up against my new OpenWrt router. Can someone explain what the difference between Closed and Stealth results and what OpenWrt settings controls that?
As far as I know shields up is testing your computer not your router
I believe the difference is dropped vs rejected packets. When packets are dropped, the sender doesn’t get any notification of that action. On the other hand, when the packets are rejected, the sender is informed.
The result is functionally similar in that no connection is possible, but the sender is aware of the presence of the host when packets are rejected. Think of it like knocking on a door - if there is no answer, you don’t know if the person is not home or just not answering. If they answer and say “go away” you know they are there, but in both cases you are not being invited into the house.
4 Likes
I think it checks your router...
https://en.m.wikipedia.org/wiki/ShieldsUP
Peter G. Ten Eyck III
Gmail (personal)
Makes sense... so not a vunerbility. How is that control within OpenWrt?
Peter G. Ten Eyck III
Gmail (personal)
Functionally, it's a no response vs a Closed response..
And while security via obscurity is a bogus security model - when taken alone - websites like Shodan make a NON-RESPONSIVE port sweep better than one that is reporting CLOSED. Will it keep someone from knowing an IP is active or not? No.. Will it keep a casual sweep from exposing potential beach-heads by reporting a vulnerable service as it says Go Away? Yes..
Learned a few things... thanks.
Peter G. Ten Eyck III
Gmail (personal)
Incorrect, assuming your OpenWrt router is in between.
- Closed - WAN INPUT set to REJECT
- Stealth - WAN INPUT set to DROP
This is on the Firewall General settings page:
And a scanner cannot report on a port it cannot "see" (i.e. get some kind of response from); but yes, this is just obscurity...but I do count that my router will not be DDoSed by my router sending replies to malicious connections, pings, traceroutes, etc. (with further configuration for some of those).
1 Like
closed - pkt is thrown away and an ICMP msg is returned to the sender - so an attacker can map your system using this response
stealth - pkt dropped, sender requests time out, sender never gets any notification
Except, most ISPs will give a differential response whether an IP is assigned and in use or not, hence the remote scanner knows whether a host is up or not, true that is not a direct transmission of information from the router, but the essential information (host is up) is there.
IMHO people have been barking up the wrong tree here, if the ICMP responses can be used to fingerprint the OS of the responding hop, the solution is not to stay silent, but to make sure those ICMP responses are identical on all (relevant) OSs... But, that "insight" is not going to help anybody today (and since nobody is picking it up, it will also not help in the future).
5 Likes
well, I would use drop in most of the cases, think about that sending out anything, at least double the network traffic, packet you send back can be used for DoS, also any info leaves your system can be used as valuable info for an attacker, it's usually not innocent attempt when I want my system to drop the pkts.
I would say the solution to this issue (should it crop up) is to rate limit the ICMP responses...
That is a paranoid mindset I do not share, but I also do not consider my router's firewall the end all of security and run firewalls on all internal hosts as well...
It is the same misguided absolutist approach to security that essentially killed ICMP types 13/14 (timestamps) which otherwise would be a decent tool to estimate one-way delays. All this should reveal is the time a packet was handled by the reflector hop: "All timestamps are in units of milliseconds since midnight UT." Tell me what information besides the one-way delay is leaked by that, and why this puts my system at risk? If the issue is that this might reveal a wrong clock, then surely the solution is a method to automatically set the correct time (NTP?) instead of shamefully not responding? 
And I am all for your ability to do that, but please keep in mind that absolute network security is not really achievable and hence always a trade-off. Yes, there are different positions on the continuum that reasonable rationale people can take/choose, but IMHO these should be taken considering the trade-offs.
2 Likes
Unless your computer is in a DMZ or you've turned the router firewall off then it's testing the router. The only exception is the Browser Headers test.
2 Likes
On my setup, its testing the firewall on the WISP antenna receiver. I can't stop a ping reply. It's how the ISP keep track of who's receiver is up and running.
Actually, they are exactly the same 
What we were talking is the difference between a port that doesn't answer unsolicited traffic vs one that Actively Rejects (aka "Go Away").
A sweep, be is Shodan.io or self-run scripts, will record requests that are REJECTED, along with whatever info they can get from the server and service in question that rejected the probe. This makes this person a target, where-as the port that DROPPED that packet it knew nothing about returns nothing than "nothing came back", which probably just puts it on a check-later list outside of the normal sweep params since IP addresses are finite resources and likely to be used SOMETIME.
The exposure level of BOTH are minimal. Realistically, the chances of a probe are high regardless, but the RISK is low. However, between setting the router to ignore (DROP) packets it doesn't know about vs telling it to REJECT the packet, with a flip of a switch? Why wouldn't you.
And that is what the ShieldsUp! test is designed to show. Turn on UPNP and see what opens ports in your network without actually telling you. It's also good to note that while the test can be useful, the context of the website isn't. I remember when that test came online, and ZoneAlarm was the thing to have because Hubs > Switches back then and people had reason to test their PC. It is actually very difficult to direct-connect a PC to the Internet these days without knowledge as to why this wouldn't be a good thing.
It's also a great way to test that your port-forward is actually working
1 Like