Re: ShieldsUP! What Components is it testing?

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

stevesr0

Member
Mar 9, 2024
9
0
I have a noobie question.

When I run the ShieldsUP! test from a particular computer on my home network, does ShieldsUP! Examine the ports on the computer, the router or both?

Thanks for enlightenment.

stevesr0
 
If your router is using NAT, and you don't have any ports opened, ShieldsUp will be testing the router. If there are any ports open and forwarded to a machine on your LAN, it will be testing that machine. In other words, it will test as far as it can get.
 
  • Like
Reactions: Steve
Thanks. So, the ports on the devices “behind” the router will get checked only when they are made accessible by the router (port forwarding).

I think of two scenarios:

1. At a computer connected to a router, I send out a request to get something from an Internet address (such as a webpage). The router “knows” I requested this and connects the webpage to my computer.

2. Port forwarding is setup in the router to allow outside stuff to come to a particular port on a specific device on the network.

In the first case, ShieldsUP! will only report router port responses. In the second case, the ports on the computer that the router has setup for forwarding will also be reported.

Do I have that correct?
 
For case 1, it can't detect these. Even if the scanning part is on the same machine as the webpage you're viewing (and not on a different machine with a different IP), when ShieldsUp sends the request, it will have a high port value that is different than the 443 port your browser used. And if the ShieldsUp scan is coming from a different IP, it will be treated as if there's no forwarding on the source port.

I remember for some reason, and previous ISP I had would have the DNS port open for some reason...
 
You need to understand that while you view a TCP connection as one thing, the computer does not. It's actually two things... or four, depending on how you count. A TCP connection is a tuple of four values. These four are (explanations to follow): The destination IP address, the destination port, your source IP address and your source port.

The destination IP is resolved via DNS from the host name. So if you enter www.grc.com it will get resolved to GRC's web server IP address.
The destination port generally depends on the service you're accessing. If it's HTTP it would be port 80, and for HTTPS is would be port 443.

Your source IP address, will translated by NAT. Your PC inside the network will have an address like 192.168.0.5 and the router will map that to the outside public ISP provided IP address on the way out, and map it from your public IP back to your internal PC on the way back in (assuming the NAT entry remains and doesn't expire.)

The source port is a crucial thing from a security perspective. It's meant to be random, but within a certain range. When your PC initiates a connection to the external service, it will be given a source port by the OS as part of the protocol/API. It might be a number like 31084. This is used by your router when it maps the connection on the way out and on the way back in. This is how multiple connections to the same service (or web page) can be differentiated. When the connection closes, the port number is "forgotten" and won't be reused for quite some time. This makes it difficult for an attacker to work their way through your NAT to the PCs on the inside without having been first contacted by you.
 
  • Like
Reactions: JorgeA
The source port is a crucial thing from a security perspective. It's meant to be random, but within a certain range. When your PC initiates a connection to the external service, it will be given a source port by the OS as part of the protocol/API. It might be a number like 31084. This is used by your router when it maps the connection on the way out and on the way back in. This is how multiple connections to the same service (or web page) can be differentiated. When the connection closes, the port number is "forgotten" and won't be reused for quite some time. This makes it difficult for an attacker to work their way through your NAT to the PCs on the inside without having been first contacted by you.
This is interesting!

It leads me to a question: if the source port is random but within a certain range, does that mean that a determined enough attacker could keep trying different port numbers in the range until they hit on the right one?

I'm no expert in this sort of thing, just trying to learn.
 
a determined enough attacker could keep trying different port numbers in the range until they hit on the right one?
In theory, I suppose, yes. In practice however, in TCP, its the tuple of the 4 values that is unique, and they would probably need to have all four to find a way to interfere with your systems. This means they need to know what source port and target port are in use on a connection between which two IP addresses. This presumes, at the minimum, that they're specifically focusing on one target, and not initiating a general attack. They could easily know these things by playing a man in the middle, for example. On the other hand, this is the reason why these days we layer TLS on top of TCP, to protect our data and messages from interference from an attacker.
 
  • Like
Reactions: JorgeA
Wow, interesting clarifications.

Simplistically, what is the difference if I invoke ShieldsUP! from my computer,

1) when it is connected to the network router which is connected to a modem

AND

2) when the computer is directly connected to the router.
 
Simplistically, what is the difference if I invoke ShieldsUP! from my computer,

1) when it is connected to the network router which is connected to a modem

AND

2) when the computer is directly connected to the router.
I don't understand this scenario if by "connected to a modem" you imply connected to the internet, and in option 2, you are only connected to the router, but NOT to the internet, you would not be able to get ShieldsUp to run.

If you meant when your computer is connected directly to the modem, or is connected via a router, there will be differences.

If your computer is connected directly to the modem, it will presumably have a public IP address, so ShieldsUp will be testing your computer directly for open ports. When you connect via a router, that becomes the "public interface" so the testing is against the router's WAN interface.

A modem is defined as the box which converts between DSL ( telephone line) signalling, and ethernet. A router is a box which connects multiple end points together and connects them to the outside world. In an IPv4 connection, this almost always includes Network Address Translation (NAT) to allow multiple client computers to share a single internet connection. Frequently both devices are contained within a single modem/router enclosure.

If you are using IPv6, The situation could, and probably will, be completely different.
 
Thanks, AlanD,

I was confirming that in order to test the computer’s ports, I could connect it directly to the modem.

As a permanent noobie, I wasn’t aware of the distinction between WAN associated ports (public ports) and the ports on LAN devices available for port forwarding.
 
Depending on your provider and connection type, you may find that, if you connect the modem directly to the PC, you have to run some client software on the PC to establish a connection. Signing on to the ISP's network is often done in the gateway/router, it you remove that, you won't get signed on.

Hint: on Windows you would typically set up a new PPP connection in networking with your ISP signin details. YMMV, it depends on how the ISP authenticates you.
 
Hi AlanD, interesting.

In the past, for testing purposes, I believe I have connected my computer directly to my ISP modem and was able to surf without running special software. But, I haven’t tried recently, and it would have to be software running on Linux, not Windows.

Re: public and private ports. I am getting the idea that these are used in concert to allow two way traffic flow. Thus, for example, if a device on the lan requests a web page via the router, this would by default be using port 80 on the router. On the return from the internet, the incoming http stuff will go to port 80 on the router and then be routed to port 80 on the device.

Is this somewhat the way this works or am I completely wrong?
 
Last edited:
You're wrong. I'll try to explain it.

For my description of how TCP works, I'll use the format computer:port to explain everything.

So, we'll start with an HTTP server, and it's listening on port 80, called servera, servera:80, and we'll say there's also a serverb that could be a port scanner (like what Shields Up does)

We'll first ignore the effects of the router for now.

Your computer will be called client. When it connects to servera, it will pick a random port, normally in the high range with the exact range being different for every OS, for the source port. For this example, it will be 35246.

So, your computer connects to servera, and the connection will look like this: client:35246 <---> servera:80. While the connection is opened, if serverb attempts to connect (with its own random port for the source), if it attempts to connect to client:35246, the OS on the client will treat it as if serverb were trying to connect to any other port that would be unused, either just ignoring it, or tell serverb that the port is closed.

Now let's add a NAT router to the path. What the router does is it will see you attempt to connect to servera:80 and it will just pick a random port of its own, and when servera returns data, the router will receive it, look at its table, and return it to your computer.

From your computer's POV, the connection will still look like this client:35246 <---> servera:80, but servera will see this router:34851 <---> servera:80. The final chain would look something like this as a result: client:35246 <--- router:34851 ---> servera:80
 
Hi AlanD, interesting.

In the past, for testing purposes, I believe I have connected my computer directly to my ISP modem and was able to surf without running special software. But, I haven’t tried recently, and it would have to be software running on Linux, not Windows.
If you are running Linux, you may have configured the internet signin in your networking software. As I said, it depends on your ISP, some validate sessions using things like the modem/router MAC address, some require a username and password.