Hi all, I'm looking to extend an existing internal spacewalk to also allow management of DMZ hosts without having to setup a completely parallel infrastructure. I'd like some advice on how best to lock it down to prevent a compromise of any host in the DMZ (either a client, or the proxy host itself) being used as a platform to attack the internal spacewalk server.
The approach I am considering is running a chain of two Proxy servers, one on inside the DMZ and one internally, with firewall holes open between the two Proxy servers only. I think this would ensure the external proxy doesn't have direct access to communicate with the real master, and any lockdown done on the internal proxy doesn't affect functionality for internal clients. I see that I can disable proxying of the webui, content push (rhn), applet, cobbler, config management and applet endpoints by tweaking the spacewalk-proxy-wsgi apache config file to expose the bare minimum services. However, I'm concerned about the security of the XMLRPC itself. Is there any way to permit only "system registration" and other "read only" API functions necessary for client management (e.g. repo metadata download)? If I understand correctly, leaving the api as-is means the only protection that stands in the way of a password brute force against the admin account via the api interface is a 2s delay on failed logins. Is there any built-in, or suitably easy addon method to whitelist IP addresses for auth.* calls? If I'm on completely the wrong track, how are other people on this list managing DMZ hosts using spacewalk? Thanks all, Ben Roberts _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
