On Mon, Mar 16, 2020 at 11:43:10AM -0400, Ryan W wrote: > On Mon, Mar 16, 2020 at 11:40 AM Walter Underwood <wun...@wunderwood.org> > wrote: > > > Also, even if you prevent access to the admin UI, a request to /update can > > delete > > all the content. It is really easy. This Gist shows how. > > > > https://gist.github.com/nz/673027/313f70681daa985ea13ba33a385753aef951a0f3 > > > > This seems important. In other words, my work isn't necessarily done if > I've secured the graphical UI. I can't just visit the admin UI page to see > if my efforts are successful.
It is VERY IMPORTANT. You are correct. The Admin. GUI is just a convenience layer over extensive REST APIs. You need to secure access to the APIs, not just the admin. application that runs on top of them. If all use is from the local host, then running Solr only on the loopback address will keep outsiders from connecting to any part of it. If other internal hosts need access, then I would run Solr only on an RFC1918 (non-routed) address, and set up the Solr host's firewall to grant access to Solr's port (8983 by default) only from permitted hosts. https://tools.ietf.org/html/rfc1918 Who/what needs access to Solr? Do you need to grant different levels of access to specific groups of users? Then you need something like Role-Based Access Control. This is true even if access is only internal or even just from the same host. Address-based controls only divide the universe between those who can do nothing to your Solr and those who can do *everything* to your Solr. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu
signature.asc
Description: PGP signature
