Aug 192019
 

TL;DR: SphinxSearch comes with a insecure default configuration that opens a listener on port 9306. No auth required. Connections using a mysql client are possible.

I recently stumbled upon SphinxSearch. A fast database that can do full-text search much faster than MySQL/MariaDB (at least in my scenario) and runs on lower ressources than Lucene, Solr or Elasticsearch (which also performed the worst in my scenario).

One thing I came accross while installing it was the default configuration. In the default configuration SphinxSearch has a listener on TCP port 9306 with no authentication. Actually authentication is not implemented in SphinxSearch as far as I know. This would make you think that this listener is at least limited to localhost? Nope. The default setup creates a listener on 0.0.0.0:9306 (reading all interfaces, any IP port 9306) and allows connections without credentials using the MySQL client.

This is a screenshot from the official documentation as of August 2019:

“Archive” screenshot

I have tried contacting the SphinxSearch team using the website form and via Skype since July, but no reply.

How to fix it?
Just go to your SphinxSearch configuration and edit the listen variable to include only localhost or put a (host) firewall like iptables in front of your installation.

Sample of a localhost listener configuration:

[..]
searchd
 {
         listen                  = localhost:9312
         listen                  = localhost:9306:mysql41
[..]

At the time of writing the Internet has 100+ exposed installations. Some of them might be on purpose or the data might not be a secret, but for some it might be an issue. I know at least one project for email archiving which uses SphinxSearch – piler. Users should check it immediately.

This is an example of a SphinxSearch login using mysqlclient:

root@vmd292 ~/sphinx/sphinx-3.1.1/bin # mysql -P9306 -h127.0.0.1
 Welcome to the MariaDB monitor.  Commands end with ; or \g.
 Your MySQL connection id is 1
 Server version: 3.1.1 (commit 612d99f) Copyright (c) 2000, 2018, 
Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MySQL [(none)]> show tables;

+---------------+-------------+

| Index         | Type        |

+---------------+-------------+

| idx1_template | local       |

| idx1p0        | local       |

| idx1p1        | local       |

| idx1p10       | local       |

| idx1p11       | local       |

| idx1p12       | local       |

| idx1p13       | local       |

| idx1p14       | local       |

| idx1p15       | local       |

| idx1p16       | local       |

| idx1p17       | local       |

| idx1p18       | local       |

| idx1p19       | local       |

| idx1p2        | local       |

| idx1p20       | local       |

| idx1p3        | local       |

| idx1p4        | local       |

| idx1p5        | local       |

| idx1p6        | local       |

| idx1p7        | local       |

| idx1p8        | local       |

| idx1p9        | local       |

| test1         | distributed |

+---------------+-------------+

23 rows in set (0.001 sec)
MySQL [(none)]> quit
 Bye
 root@vmd292 ~/sphinx/sphinx-3.1.1/bin # 
May 012020
 

I ran into a nasty issue with a VPS that has only 256MB RAM and updating using yum update failed due to memory issues with some packages. I ended up in a state where some packages were updated and some where not. This means I had duplicate packages of old and new ones and broken dependencies. Coming from Debian (apt) I was not so comfortable with yum, but this is how I solved it and learned new commands:

1. Add some memory (even being swap)

Lets add some swap memory to the VPS. 1GB should be fine:

swapon –show
fallocate -l 1G /swapfile
dd if=/dev/zero of=/swapfile bs=1024 count=1048576
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo “/swapfile swap swap defaults 0 0” >> /etc/fstab
reboot # might be needed – I had to do it

2. Find the problematic packages

yum already gave me hints about the packages that have issues. In my case iptables and iptables-service. I checked which versions I have installed using

yum list installed | grep iptables

and found that I have multiple versions installed.

3. Remove the duplicates

yum update already mentioned some issues, but I figured out that the root cause was duplicates. I learned that there is a command to remove duplicates in CentOS:

package-cleanup –cleandupes

I wonder how often this happens that you need a tool for this … anyway.

If you want to remove only a specific version of a package you can do this using

yum remove iptables-services-1.4.21-33.el7.x86_64

You take the package name, append “-” and the version, append “.” and the architecture.

4. Re-run update

Finally I was able to run yum update -y and yum was able to install the new versions of all packages and all went fine.