¶ SAP Port and Service Scan
The port and service scan in the RedRays Security Platform opens connections to a list of addresses you supply and records which SAP services answer: on which host, under which instance number, on which port, and what each one returns to a caller who has presented no credentials.
- Unauthenticated, nothing is logged into
- Reaches only the addresses you list
- An inventory, nothing is scored
What comes back is an inventory, not a verdict. Nothing here is scored or ranked. The result is a tree of hosts, instances and services, and that tree is what every later argument stands on: you cannot decide whether a message server should be reachable from a user subnet until you know that it is, and you cannot check a system's configuration or its SAP Security Notes until you know the system is there and how to reach it.
A scan runs against a target that was written down and saved first, so the addresses it may touch are settled before anything is sent.
¶ What question does an SAP port scan answer?
It answers three questions that people usually ask as one. Which SAP processes are running at all, of which kinds. Where each of them answers: which host, which instance number, which port, plain or wrapped in TLS. And what an unauthenticated caller gets back from each one, which is the answer that decides whether the first two matter.
The last question is the reason this is an SAP scan rather than a network scan. A service that identifies itself, its stack and sometimes its system to anyone who connects has told a stranger something before any credential is involved.
¶ How is this different from a general-purpose port scanner?
A general-purpose scanner reports that a port is open and infers the product from the port number. An SAP service scan sends a request the service is expected to recognise and names the service from the reply, which is the only way to be right when several SAP services share the same default port pattern.
Two consequences follow, and both are routine rather than exotic on an SAP landscape:
- The port number does not identify the service. More than one SAP service kind can sit on the same default pattern, and they are told apart only by what they send back. A tool that guesses from the number will name the wrong one on a landscape that is not laid out the way its table assumes.
- The same daemon in two configurations is two different answers. Whether an SAP gateway is running with monitoring enabled is not visible in the port number. It is visible in the reply.
¶ What does a scan record about each thing it finds?
| Level | What it is | What is recorded |
|---|---|---|
| Host | One machine, by address | The address. Not a name, not a credential, not a claim that anything is listening |
| Instance | One SAP system on that host, by its two-digit number | The number, which is what turns a default port pattern into a real port |
| Service | One SAP service kind, on one port | The service kind, the port it answered on, whether the connection was plain or TLS, and how the scan was told to connect |
The host carries an address and nothing else, and the instance number under it is what turns a default port pattern into a real port.
Hosts, instances and SAP services takes each level apart, including what a service row does and does not assert about the machine underneath it.
Nothing is recorded for a port that refused, an address that never replied, or an open port whose reply was not recognised, so an empty branch of the tree cannot say which of those it was.
¶ Does the scan sign in to anything?
No. The sweep is unauthenticated, because it records what an anonymous caller sees. A logon can be stored against an individual service, and it is used by a separate per-service connectivity test that a person runs deliberately, so that a wrong credential is discovered before it matters rather than during a scan.
That is a boundary rather than a missing feature. Signing in changes what a service tells you, and the question this capability answers is what a system tells somebody who has not signed in.
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.
¶ Where does a scan result go?
The tree is machine-readable input for the rest of the platform. Scanned targets are what configuration and vulnerability assessment is offered as its starting inventory, and hosts found to be running an SAP Internet Communication Framework (ICF) stack are what the SAP Security Notes work is pointed at. A reader who wants to know whether something is dangerous is holding the capability that comes before that question.
¶ Limits: what a port scan does not tell you
- An absent service is not a closed port. A refused connection, a filtered address and an open port whose reply was not recognised are all recorded the same way: as nothing. An empty result means that nothing matched, never that nothing is there.
- It measures reachability from one place. Everything recorded was reachable from the machine the scanner runs on. There is no topology, no firewall rule set and no route table behind it, so it never claims that what it reached is what your users, or an attacker elsewhere, can reach.
- It does not enumerate people. No user, no role and no authorisation object appears anywhere in this capability. Who can do what is segregation of duties work.
- It does not grade what it found. A discovered service carries no severity and no recommendation. The judgement that a service should not be listening is made by a person, or by the capability that reads this inventory next.
- It does not test credentials during a sweep. Trying a stored logon is a separate, single-service action.
- It does not discover hosts. A scan reaches exactly the addresses in the target it was given and nothing else. Building that list is scoping and authorising a port scan.
¶ Which page answers which question?
¶ Frequently asked questions
¶ Is an SAP port scan intrusive?
It opens TCP or TLS connections, writes a short request and reads the reply. It does not log in, crawl or send anything designed to change state. Volume is what to plan for rather than depth: a host whose instances are not specified is swept across every instance number, which is a large number of connections to one address.
¶ Why does an SAP service move ports between systems?
Because most SAP default ports are patterns with the two-digit instance number written into them, so the same service answers on a different number on every instance. SAP default ports and instance numbers sets out the rule, and the cases where the digits are not at the end.
¶ Can it scan a network I do not own?
It will send packets to whatever addresses you put in the target, which is why the scope is a written decision before it is a technical one. The product does not check ownership and is in no position to.
¶ Does a completed scan mean the network is clean?
No. It means a scan job finished. A scan that reached nothing and a scan that found nothing produce the same empty result, and telling those two apart is a reading you make from the scope rather than from the result. This is the same distinction described in what a finding does and does not claim.
¶ Does it produce a report?
The output is the inventory and the handover to the capabilities that consume it. Reporting belongs to those capabilities, because this one produces no findings to report.
¶ Related pages
- Why a port list is not an SAP inventory, on what a firewall rule list answers and what it does not.
- Hosts, instances and SAP services, on what one scanned row states.
- SAP default ports and instance numbers, on the arithmetic that decides where a service answers.