Preview
This guide is a preview. Its content may change.
Register with Remote Scan#
Read Only the Method You Use
With this method, one server with the scanner installed (the scanner server) connects over SSH to other servers on the same network and scans them on their behalf. You don't need to install the scanner on the servers being scanned.
How Remote Scan Works#
flowchart LR
S["Scanner server<br>(one server already set up with Local Scan)"] -->|SSH| T1["Target server 1"]
S -->|SSH| T2["Target server 2"]
S -->|SSH| T3["Target server 3"]
S -->|"Sends all results together"| F["FutureVuls"]How it works in detail (you can follow the steps without reading this)
"Remote" doesn't mean that FutureVuls scans your servers remotely over the internet. Your own management server scans the servers on your internal network.
Each target server is registered individually in FutureVuls, and you are billed for each one.
What You Need#
| What you need | Details |
|---|---|
| One scanner server | A server with the scanner installed by following the Local Scan steps. It must be on the same network as the target servers |
| A user that can log in with SSH public key authentication | The username, private key, and public key used to log in to the target servers. Password authentication is not supported |
| Preparation on the target servers (Linux) | Install the dependency packages and configure /etc/sudoers. For the steps, see Remote Scan |
You can also scan Windows target servers (an administrator user is recommended). In that case, also prepare the following.
- Each target Windows server needs SSH configured. You also add the SSH connection information to the configuration file.
- If the target Windows servers can't connect to Windows Update, use the cab file method. Place the cab file (wsusscn2.cab, about 800 MB) somewhere the target Windows servers can read it (either on each server or in one place on a file server; the file server method requires Linux scanner v0.24.9 or later). For details, see Remote Scan and this blog post.
Steps#
1. Place the Private Key and Confirm You Can SSH Manually#
Make the vuls-saas user the owner of the private key and set its permissions to 600. Then log in to the target server once as the vuls-saas user.
# スキャナサーバで root として実行
cp target.pem /home/vuls-saas/.ssh/
chown vuls-saas:vuls-saas /home/vuls-saas/.ssh/target.pem
chmod 600 /home/vuls-saas/.ssh/target.pem
# vuls-saas ユーザで対象サーバに一度ログインする
su - vuls-saas
ssh -i ~/.ssh/target.pem ec2-user@192.168.0.100
exit
Why you log in manually once first
You log in manually once to record the host verification (fingerprint) on the first connection. If you skip this, the connection hangs during automatic scans.
2. Add the Target Servers to the Configuration File#
In /opt/vuls-saas/config.toml on the scanner server, add one block for each target server. The xxx in [servers.xxx] becomes the server name in FutureVuls.
[default]
port = "22"
keyPath = "/home/vuls-saas/.ssh/target.pem"
scanMode = ["fast-root"]
[servers]
[servers.localhost] # インストーラが自動で設定（スキャナサーバ自身）
host = "localhost"
port = "local"
[servers.web01] # 対象サーバ1台ごとに1ブロック追加
user = "ec2-user"
host = "192.168.0.100"
| Setting | Details |
|---|---|
| user | The username for SSH login |
| host | An IP address or a resolvable hostname |
| port | The SSH port. If it's the same for all servers, put it in [default] |
| keyPath | The location of the private key. If it's the same for all servers, put it in [default] |
To register a range of servers at once, you can use CIDR notation, such as host = "192.168.0.0/28". However, if even one IP address fails, the scan stops partway through.
Don't include servers that are already registered by remote scan in the CIDR range. If you do, their UUIDs are overwritten with new ones, and FutureVuls treats them as different servers. If a UUID is overwritten, edit the configuration file (/opt/vuls-saas/config.toml) directly and restore the original UUID. You can find the original UUID in the server details on the Server / Product tab (notes on CIDR range remote scanning).
The UUID is issued automatically on the first scan. If you write one yourself, make sure it doesn't duplicate any other server's.
3. Run a Scan and Check the Results#
sudo -H -u vuls-saas /opt/vuls-saas/vuls-saas.sh
You're done when each server in the configuration file is added as its own row in the server list. From then on, the servers are scanned automatically every day.
Common Issues#
| Message or symptom | Cause and solution |
|---|---|
Permission denied (publickey) |
Check the key's owner and permissions (600) and the spelling of user |
Host key verification failed |
Redo the manual SSH login in step 1 |
sudo: a password is required |
Check the /etc/sudoers settings on the target server |
| Servers don't appear on the screen | Check /opt/vuls-saas/report.log for submission errors (such as proxy issues) |
Connection and sudo problems are logged in /opt/vuls-saas/scan.log, and submission problems are logged in /opt/vuls-saas/report.log.
Troubleshooting#
If something isn't working, see Troubleshooting (FAQ).
If that doesn't solve the problem, contact us through the support contact form. Including the configuration file (excluding keys and passwords), error messages, and scan.log helps us investigate faster.
Learn More#
Next Page#
Once registration is complete, check your progress in the "After You Register All Servers in the Initial Scope" section of Setup 2: Register Servers and Products.