¶ Hosts, Instances and SAP Services
An SAP port and service scan in the RedRays Security Platform records three levels for every service it finds: the host by address, the SAP instance by its two-digit number, and the service itself with the port it answered on and whether the connection was plain or wrapped in TLS.
Those three levels are the whole data model, and each is a narrower claim than it looks. This page states what a scanned row asserts, what it does not, and where an absence in the tree comes from.
¶ What are the three levels of a scanned tree?
| Level | The product's definition | What it asserts |
|---|---|---|
| Host | One machine, by address. A landscape has several | That somebody put this address in scope. Not that a machine exists there |
| Instance | One SAP system on that host, identified by its two-digit number | That this instance number was configured or discovered. The number is what resolves a default port pattern into a real port |
| Service | One SAP service kind, pinned to one port, plus how to talk to it | That a service of this kind answered on this port, or that somebody configured the scan to look for one there |
The host holds an address and nothing else: no port, no system name and no reachability flag. The ports come from the instance, which is why the address is entered without one.
¶ What does one service row actually state?
The strongest true reading of a discovered service row is narrow, and worth writing out in full: something at this address, on this port, answered an unauthenticated connection with the greeting that this SAP service kind produces.
That is a fact about exposure and identification, and producing it is what the capability is for. Everything a reader is tempted to add is not in the row:
- It does not say that anybody can log on, that a default account still exists, or that any user exists at all.
- It does not say the port is reachable from anywhere except the machine that ran the scan, which on a segmented network is frequently the entire question.
- It says nothing about the other instance numbers. A dispatcher on a neighbouring instance would be a separate row, and its absence is an absence of evidence rather than evidence of absence.
- It does not say the service should not be listening. Nothing here is scored.
¶ How is a service identified?
By what it sends back. The scanner opens one connection to one address and one port, writes a short request the service kind is expected to recognise, reads the reply and compares it against what that kind is expected to say. A match means the reply carried the expected signature, and nothing beyond that.
Four properties follow, and they are why this is a fingerprint rather than an interrogation:
- It does not sign in. An anonymous probe carries no authorisation at all, so what it records is what a stranger sees.
- It does not crawl or enumerate. Nothing is followed, no directory is walked, and the service is not asked for its version.
- It does not grade. A discovered service is a row in a tree, with no severity attached.
- Its negative is silent. This is the expensive part, and the next section is about it.
¶ What happens to the things that did not answer?
Nothing is recorded. A port that refused the connection, an address that never replied, and an open port whose reply was not recognised are all stored identically: as an absence.
So an empty branch of the tree has at least four possible causes, and the tree cannot separate them:
| Cause of an absence | What it would mean |
|---|---|
| The connection was refused | Something is there and that port is closed |
| The connection was filtered or timed out | A device between the scanner and the host said no, or nothing is there at all |
| The port was open and the reply was not recognised | Something is listening that this catalogue does not name |
| The port was never in scope | Nobody asked the question |
This is why a scan that reached nothing and a scan that found nothing look the same, and why the scope is part of reading the result rather than a preliminary to it. Scoping and authorising a port scan covers how the address list is decided.
¶ What does anonymous mean on a service?
It describes how the scan will connect, not what was found. An anonymous service is one the scan approaches with no credentials, which is the default. Turning that off opens a place to record a logon for that one service, in the form the service expects, including the SAP client where the service kind has a client concept.
Anonymous is a setting about how the scan will connect, and switching it off opens the place where a logon for that single service is recorded.
Three readings to avoid:
- Anonymous does not mean the service accepts anonymous callers. It means no credentials will be offered.
- A stored logon does not mean the service demanded one. It means an operator recorded one.
- Where a service kind cannot be given a logon at all, that is a property of the service catalogue rather than a measurement of the host. Two machines running the same service kind are described the same way.
Where the catalogue gives a service kind no logon, the card offers nowhere to put one, which is a fact about the catalogue and not about the host.
¶ Limits of what the tree can say
- There is no per-service history. A service is a position in the current tree, so the capability cannot state that a port on a host is the same one that was there last month.
- A rescan replaces the result rather than extending it, so there is no built-in comparison of two scans and no timeline. Since only discoveries are stored, a rescan of a narrow tree cannot widen back out to a port that was closed the first time unless the scope is widened deliberately.
- A stored port beats the arithmetic. Where a service already carries an explicit port, that number is used as written and the default pattern is never consulted, so renumbering an instance recomputes nothing.
- Nothing here is a report. The tree is an inventory that other capabilities consume.
¶ Frequently asked questions
¶ Why does the same port appear more than once under one instance?
Because a service row is a port plus how to talk to it. One SAP Internet Communication Framework (ICF) listener serves every SAP client on the system, and the client is chosen per request rather than per socket, so three clients worth checking on one listener is three rows.
¶ Does the scan tell me the SAP system ID?
Where it can be determined from what answered, the system identifier is recorded. Where it cannot, the product says that none was detected, which is a different statement from leaving the field blank.
¶ Can I tell from the tree whether a service is exposed to the internet?
No. The tree records reachability from the machine that ran the scan, so answering the exposure question means running the scan from the vantage point you care about.
¶ What if a service is listening on a non-standard port?
It is found if that port is in scope, either because it was written down explicitly or because it falls in the swept range for its service kind. A service moved outside every pattern the catalogue knows has to be entered by hand.