DeineAgenturUG / greenbone-gvm-openvas-for-docker

The Greenbone Vulnerability Management (GVM) and OpenVAS Scanner for Docker!
MIT License
24 stars 7 forks source link

[Enhancement] Support rsync mirroring #22

Open miyoyo opened 2 years ago

miyoyo commented 2 years ago

Is your feature request related to a problem? Please describe. Synchronizing feeds can often be a problem when in severely restricted networks, some network administrators may also be uncomfortable permanently having a server outbound connection open to a third party.

The greenbone feeds also have strict restrictions, such as only allowing a single sync at a time, restricting sync speed, temp-banning IPs that sync too often.

Describe the solution you'd like Gated behind an environment variable, such as "RSYNC" or "PROXY_FEED", the master scanner could publish the data it previously synced via rsync, either

Additional context Rsync sends things through cleartext by default, and I don't think it pins servers either.

To test this, you can use the "--add-host" or "extra_hosts" parameters to redirect feed.community.greenbone.net to a custom server.

Legacy/existing openvas scanners can already do the above to point to a custom server for feed updates.

It looks like it's possible to only allow rsync through ssh, however this is saved in the authorized_keys file, so toggling the environment variable won't necessarily disable rsync: https://serverfault.com/a/965929

Dexus commented 2 years ago

Sounds quite interesting, could you contribute a PoC? I would have to think about it more, but time is a bit short at the moment. But I'll add it to my list if you don't have the possibility to contribute code yourself.

miyoyo commented 2 years ago

Sure, I'll see what I can do, if anyone else is interested, don't hesitate to snipe it, we probably need more than a single approach anyway.

miyoyo commented 2 years ago

Alright, so, to get a basic experiment going, here are the changes that need to be done to run an rsync command manually:

This assumes one master, one slave, and that they are already linked through SSH.

All the config changes must be done on the master:

/etc/ssh/sshd_config: MaxSessions 0 -> MaxSessions 1

/var/lib/gvm/.ssh/authorized_keys: Prepend command="rrsync -ro /var/lib/openvas/plugins" to the key

You can now run this on the slave: rsync -e "ssh -p $MASTER_PORT -i /var/lib/gvm/.ssh/key" --compress-level=9 --links --times --omit-dir-times --recursive --partial --quiet gvm@$MASTER_ADDRESS:/ /var/lib/openvas/plugins

And the directories should now sync.

It may be wise to add more restrictions to the autorized_keys, now that a shell can technically be open, but since rrsync is forced, I don't believe that is much of an issue.

Maybe putting it in sshd instead of authorized_keys would be more beneficial, actually not, would require some sort of restricted shell to be installed, as the sshd_config forcecommand does not take arguments

Since there is almost no burden on the master beyond a quick configuration change, it could be beneficial to always have rrsync be available on the master, and give a configuration flag to the slave in order to select the feed source, like "USE_MASTER_NVTS"