Changing network ports from closed to stealthed

I've been using Shields Up to check which ports are visible from the Internet.

With my NAT router set up as normal, all ports show as "stealthed" in Shields Up i.e. a probe to the port gives no response. This is viewed as a good thing.

When I DMZ to my Pi (running a VPN server as a test) I can see all the ports as "closed" apart from the VPN port. As I understand it the Pi is sending a negative response to a request to open the port. This tells the far end that there is a device there managing the ports, which is an invitation to try again and expand the range of ports probed.

I would like to tell the Pi to ignore all connection requests and stealth the ports.

Google is not currently my friend. Does anyone know how to do this?

Cheers

Dave R

--
Windows 8.1 on PCSpecialist box
Reply to
David
Loading thread data ...

Where did you run this second scan from? Was it another Shields Up! scan, i.e. the probe came from Gibson's site, or was it run from from somewhere else?

If I want to scan something on my LAN, I run nmap locally.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

Only by the creator of that site. Most other experts view that as baloney.

Reply to
Rob

Interesting. And how is it a good idea to reveal unnecessarily the existence of a port?

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Reply to
Michael J. Mahon

There is no "revealing the existence of a port".

Reply to
Rob

Enlighten me. If I probe a port and get a NAK, doesn't that reveal that something is there? And doesn't that invite further probes?

I'm seriously curious.

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Reply to
Michael J. Mahon

On Thu, 30 Jul 2015 17:12:21 -0500, Michael J. Mahon declaimed the following:

"Stealth" only means something if ALL port probes drop the incoming packet on the floor with no response -- meaning the IP (not port) becomes "not there".

As soon as you allow anything through, which would be the only reason for the "DMZ" mode -- to allow an outside host to send connection requests to the DMZ internal host, it no longer matters if only one port or all respond with ACK or NAK. The single pass-through destination port is enough to identify a live target host. If, OTOH, ALL outside requests are dropped, the probing host doesn't even know that there is a host machine seeing the packets -- but in that case, you don't need the DMZ pass through.

If you still want to mask the non-listening ports -- run a firewall on the R-Pi configured to drop packets to any port except the open one. It won't reduce the probe traffic since finding the listening port will be enough to signal the prober to continue beating on the firewall looking for another open port.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

you can keep yours toes warm on the CPU power beeded to respond with a refusal to connect from all those far east DOS attacks...

--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
 Click to see the full signature
Reply to
The Natural Philosopher

There is if it sends back a NACK - ie a connection refused.

--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
 Click to see the full signature
Reply to
The Natural Philosopher

It is not important.

ALL ports with a valid port number "exist". But you can only connect to them when sending a TCP SYN results in receiving a TCP SYN ACK. You then send a TCP ACK and from there you have an open connection over which you can exchange data.

All other replies, no matter if it is TCP RST, ICMP Destination Unreachable (with a subtype of "protocol not reachable", "port not reachable", "host not reachable", "network not reachable", "communication administratively prohibited" or whatever other subtype) mean that you do not get the connection.

That does not bring the other side any nearer to a connection. It just does not matter if there is a reply or not from the port. There is no "further probe" that will yield anything useful (a connection) when there is one of those replies that would not be possible when there is no reply.

Reply to
Rob

I wouldn't use the DMZ feature, as this exposes all the services you have running on the Pi to the internet, and you need to be absolutely sure you've configured tem all securely. Instead set the router up to forward just ssh to the Pi, and set up your ssh client to tunnel all the ports your are interested in via the Pi.

Make sure you configure ssh securely on the Pi, so only authorised non-root users can get on, there is plenty of information on the internet about how to do this. I have mine set up to only allow a special restricted gateway user to be logged on to using a 2048bit RSA key and not a password. If forwarding ports this is all that is required, if you want to get to a user account, you do an su from there.

If you forward the ssh port 22 on the router to port 22 on the Pi, you instantly see attempts to gain access in the /var/log/auth.log If instead you pick some random high number above 1000 on the router and forward that to port 22 on the Pi, you'll see far less attempts. Make sure you use this new port number with any ssh clients.

---druck

Reply to
druck

I run servers out there on the wild internet on port 22 ssh and I cant say that I see many attack attempts, if any, to that port.

The number of people trying to get past the http protocol and looking for misconfigured wordpress, joomla or other content managers is however immense.

--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
 Click to see the full signature
Reply to
The Natural Philosopher

But *no reply at all* does not even reveal that a service exists on that port, nor does it waste any CPU or network bandwidth.

Better still it wastes attacker's time listening for a response that never comes.

Like trolls, denial of service attackers are best ignored, not given negative responses, because, like internet trolls, what they want is a response - any response.

No one is talking about a connection, we are talking about denial of service attacks.

Repeated hits on a port that sends a NACK have in some cases resulted in vulnerabilities being exposed.

All this was discussed in length back in the 90's. The consensus was that dropping packets ra5her than nacking them was ultimately the safest approach in a hostile world.

It was rude to people who had made a genuine mistake, true, but thats life :-(

--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
 Click to see the full signature
Reply to
The Natural Philosopher

Again, there is no "revealing" here. Either you provide a service or you don't, and it does not matter if you tell that you don't or if you don't reply at all.

Those responses do not require noticable resources, especially when compared to normal operation of the system.

I know that it has been discussed, but my opinion is that the result is baloney. There is no reason to panic when that website finds something and marks it "not stealth". Really.

When you are going to provide a service, it can be detected. That is the purpose of providing a service. The OP wanted to open a VPN service, so of course it is detected as not stealth. Nothing to see here, move along.

Reply to
Rob

well in theory yes, in practice no one hangs a service on a port that simply says 'no' for no good reason

We are not talking about normal operation: we are talking about DOS attacks.

No, there is no reason to panic, but there is a reason to pause and consider.

*shrug* its possible to restrict a ports response to a range of sender addresses and firewall the rest out by silently dropping a packet.

I personally prefer to silently shut everything out except for ports you actually need, from ip addresses you actually need.

--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
 Click to see the full signature
Reply to
The Natural Philosopher

Just to note that I am using PPTP and not ssh.

I may at some point move to OpenVPN (or a variant of same) but for initial minor use PPTP seems to work O.K.

I know it can be brute forced, but threat assessment suggests that allocating 24 hours of serious CPU time to break every PPTP instance visible world wide may be too expensive for the projected return.

I may well (as suggested) remove the DMZ configuration and just forward one port instead. Firewall rules could also restrict the IP address ranges which would be allowed to connect. My TUIT is far from round ATM, unfortunately.

Oh, and if the configuration is set to forward all incoming VPN connections back out to the Internet, presumably there is no simple way for someone connected via the VPN to access the internal LAN?

Thanks to all.

Dave R

--
Windows 8.1 on PCSpecialist box
Reply to
David

Both cases running Shields Up from a Windows PC on my local LAN - once when there was no DMZ configuration and once when there was.

So same test under two different configurations of the router.

Cheers

Dave R

--
Windows 8.1 on PCSpecialist box
Reply to
David

So the way to go may be to configure a firewall to silently drop any incoming requests which are not from a chosen IP address (or address range)?

So that all generic probes will just get no response, as if there is no device connected to that IP address, and only the chosen few can go through the protocol to start a session.

That is, the whole port range is stealthed to virtually all the Internet and there is a single port visible to the select few.

Cheers

Dave R

--
Windows 8.1 on PCSpecialist box
Reply to
David

Just to be sure, are you saying that the random probes running all the time to try and locate vulnerable hosts probe all possible ports on every IP address right up to the highest possible port number? That is, up to

65535?

I was expecting that the probes would check the first 1056 ports at first pass and then proceed to look higher only if they got some kind of response to the initial range.

They might even check a few "common ports" initially to decide if they should expend further resource.

In which case being stealthed in the lower ranges might save you from being probed by aliens!

Cheers

Dave R

--
Windows 8.1 on PCSpecialist box
Reply to
David

I do not base my system configuration on some observation someone made in the nineties, and I see no reason why a scanner would stop when they get no reply on some port, and continue when they get "not reachable".

This is just as stupid as "do not reply to ping!".

Reply to
Rob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.