¶ Scoping and Authorising a Port Scan
Scoping an SAP port scan means deciding, before anything is sent, exactly which addresses the scan may touch; in the RedRays Security Platform a scan reaches the addresses in its saved target and nothing else, and it never discovers hosts of its own accord.
That property is what makes scoping a short exercise rather than a nervous one. There is no sweep that wanders, no automatic subnet expansion at run time, and nothing between typing an address and starting the scan that touches the network. The list you write is the list that is contacted.
¶ What is a target?
A target is a saved configuration: a name, one or more hosts by address, the instances under each host, and the services under each instance. It is not a machine and it is not a scan. A target existing means somebody wrote down an intention to look at these addresses. Scanning it produces a result in the same shape beside the configuration that produced it, so the tree you read afterwards is what answered rather than what you asked for.
A target being built exists in the browser alone, and nothing has been contacted at the point this screen is reached.
¶ How is the address list built?
Three ways, and none of them contacts anything at the moment the target is created.
| Way in | What you supply | What is written | Instances created |
|---|---|---|---|
| By hand | One host at a time, with the instances and services you know about | Exactly what you entered | Only the ones you add |
| From a network mask | A base address and a CIDR mask | One host row per usable address in the range | None, which means the scan sweeps every instance number |
| From a file of addresses | A list of addresses, one per line, plus a span of instance numbers | One host row per line, after de-duplication | The shared unnumbered instance plus every number in the span |
A base address and a mask are turned into one host row per usable address by ordinary subnet arithmetic, with nothing contacted while the target is written.
The range and file routes are enumeration, not discovery. The range is expanded by ordinary subnet arithmetic and the file is read as text: no address in either path is pinged, resolved or connected to, and nothing checks that a line is a machine rather than a typing mistake.
A file of addresses is read as text, and the span of instance numbers to create under each line is chosen before the import runs.
¶ Why does an unconfigured host produce the largest scan?
Because an empty branch is not a narrower instruction, it is a wider one. A host with no instances recorded is swept across every instance number plus the shared unnumbered instance, and each of those is given every service kind whose port pattern fits, which comes to thousands of connection attempts for a single address.
That inverts the intuition, so it is worth stating as a rule of thumb: recording the instances and services you already know about narrows the work, and leaving a host blank widens it, multiplied by the size of the range.
Both are legitimate. A blank host is the right choice when the point of the exercise is to find what nobody wrote down, and the wrong choice when you are re-checking a system you already have documented.
Recording the instances and services you already know about is what narrows a sweep, and it is an edit that has to be saved before a scan will run.
¶ How do you decide which addresses a scan is allowed to touch?
By getting it in writing before the target is built, in the terms the scan will actually use. A workable authorisation names five things:
- The address ranges, exactly as they will be entered, and the ranges explicitly excluded.
- The vantage point, meaning where the scanner sits. A scan measures reachability from one place, so the segment the scanner runs in is part of the scope rather than an implementation detail.
- The window, because the cost of a scan is volume of connections rather than depth, and volume is what a network team notices.
- Who is expecting the traffic. Intrusion detection on a well-run network should notice this. Tell the people who will see it, or find out whether they do, which is a useful result in itself.
- What happens to what is found. The result is an inventory of exposed services, which is a sensitive document even though it contains no credentials.
A common sequence is to start in a non-production segment against systems you own outright, confirm the volume and the alerting behaviour there, and widen from that.
¶ What starts a scan, and what does it do?
A person does. Scans are not started on a timer, and the request covers the whole target rather than a selection inside it: every service of every instance of every host in it. The control starts the work immediately when pressed, so the review of scope happens before the press rather than in a dialog after it.
Once running, the scan opens TCP or TLS connections, writes a short request and reads the reply, then makes further requests against the ports that answered where a system identifier can be determined from them. Nothing is logged into, and stored credentials are not used by the sweep.
¶ Limits worth knowing before you build a target
- A target cannot be deleted from within the capability. It can be renamed and overwritten, and its addresses keep counting against the licensed address ceiling for as long as the row exists. Build the first target deliberately rather than experimentally.
- The address count is a licence unit. It reports distinct stored addresses against the ceiling your licence permits, which is what is stored rather than what exists, answered or was ever contacted. A range larger than the remaining allowance is refused before anything is written, rather than leaving a partial target behind.
- There is no schedule. Re-running a scan is a deliberate act each time, and a rescan overwrites the previous result for that target, so there is no built-in comparison between two scans.
- Nothing verifies that an address is yours. The product sends what you tell it to send, which is why authorisation is a document rather than a setting.
¶ Frequently asked questions
¶ How large a range can be scanned at once?
The range route is capped at a modest CIDR size on purpose, so that a mistyped mask cannot turn into a scan of an entire site. Larger estates are covered by several targets, which also keeps the scope of each one reviewable.
¶ Will a scan disrupt an SAP system?
The traffic is connection-level: open, write a short request, read the reply, close. It does not log on and does not attempt anything designed to change state. The realistic risk is volume against network equipment and alerting rather than harm to the SAP system, which is why the window and the vantage point are part of the scope.
¶ Can I scan a production landscape?
Yes, with authorisation and with the instances of known systems recorded so the sweep stays narrow. Many teams scan production with a specified target and reserve blank-host sweeps for segments where the point is to find unknown systems.
¶ Do stored credentials get sent during a scan?
No. The sweep is unauthenticated. A stored logon is used only by a separate, single-service connectivity test that a person runs on purpose.
¶ What do I do with the result?
Hand it to the capability that answers the next question. The scanned inventory is what configuration and vulnerability assessment starts from, and what a discovered service row does and does not claim is set out in hosts, instances and SAP services.