I am not sure how solr is exactly set up currently, much less on any specific system. But, for operations which are largely reading, *maybe* like a query, you might be able run on a read only partition.
A firewall is a lot less work and a good start, like 90% of the problem. To do this, you bring up the system with two partitions, one read-only and one read-write. You chroot into the readonly partition and start the query server. This process would only be allowed to run queries and would only be read only. The indexing process, if exposed to the world, would have to have a firewall in front of it with white listing of various parts of the world. (Preferably with an ssh enabled exchange, but security is hard, lets go shopping.) This is complicated to set up. If I recall, we had to build up the used parts of the OS as a sub-mount and then run there. However, once it is mounted read only, any subprocess in that root would not be allowed to write. As an simple example, this type of change requires network logging and then a whole lot of qualification to get to useful production. On Sat, Aug 25, 2018 at 7:10 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 8/25/2018 12:59 PM, humanitarian wrote: > > I am struggling to fight an attack were the solr user is being used to > > crate files used for mining cryptocurrencies. The files are being > > created in the /var/tmp and /tmp folders. > > > > It will use 100% of the CPU. > > > > I am looking for help in stopping these attacks. > > > > All files are created under the solr user. > > At least some of what I'm writing is a repeat of what was said in > SOLR-12700 -- an issue in Jira with a description that's extremely > similar to the subject of this message. > > The Solr server should never be exposed to untrusted parties, especially > the open Internet. This is probably our number one recommendation for > security. If an attacker cannot reach a server, they cannot compromise it. > > There are a lot of possible vectors in Solr that could have been used to > compromise the system. Most of the vulnerabilities that have been found > are in third-party dependencies that Solr utilizes to create certain > functionality. > > This is not the first time I've encountered this. On at least one other > occasion, a user found weird software on their system running as the > solr user. It turned out to be a crypto-mining program. > > If you have Solr logs from when your system was compromised, we can > check them to see if there's anything useful. There may not be anything > useful. One of the better logs for tracking this sort of thing is the > Jetty request log, but this log is not enabled by default in the Solr > download. This log will be the only way you can get the IP address > making requests. > > Lock down your Solr server(s) so that only trusted network addresses can > reach them. This will need to be done outside of Solr. The operating > system will have a firewall available, and your network equipment might > also have filtering capability. > > Thanks, > Shawn > >
