Security recommendations

For start, here are the ports used by MyDMAM:

Port Used by Configuration default (*) Protocol restrictions Potential danger if leaking outside
TCP/22 SSH All Linux instances Not used by default with MyDMAM, only for Linux admin. Nothing more than SSH. Various. Please set a good password.
TCP/7000 Cassandra: cluster communication between nodes. Only localhost Absolutely nothing. Theft, loss of datas, loss of service.
TCP/9160 Cassandra: thrift clients, communication between Cassandra and MyDMAM.  Only localhost Absolutely nothing. Theft, loss of datas, loss of service.
TCP/9200 Elasticsearch HTTP access. Only localhost HTTP 1.1 with Json messages. Theft, loss of datas, loss of service, remote execution.
TCP/9300 Elasticsearch binary access. Only localhost Java serialized objects. Theft, loss of datas, loss of service, remote execution.
UDP/54328 Elasticsearch node snitching. Enabled by default. Zen Discovery. Used in broadcast. Made for found other Elasticsearch instances.  Unknown.
TCP/20, 21, and others FTP Client for MyDMAM Not used Cleartext authentication. Non-ciphered data. Theft, loss of datas.
TCP/445, and others SMB Client for MyDMAM Not used Non-ciphered data. Theft, loss of datas.
TCP/9001 MyDMAM Play Web server Open if enabled. HTTP 1.1, cleartext authentication. Nothing with good passwords and front TLS reverse proxy (see below).

(*) If using MyDMAM Packs.

All rules in force are respected as best as possible. No storing of passwords in clear, but a heavy hashs (Bcrypt with salting) and an encryption in AES in base.

The admin password is randomly created at first launch if the databases are empty. The Administrator account can not be disabled, but there may be multiple accounts with Administrator privileges (that is, with all privileges).

A user can not list his privileges if he does not have the right to change them (he can just guess some).

The access privileges are injected into the web pages and managed on the Javascript side to propose only the available functions, and verified on the server side with the controllers. In fact it is not the privileges of the user who sent it by Javascript but the list of controllers that it has access.

The privileges for a user are stored in the Play cache, with an adjustable ttl, and the session key is sent encrypted in a cookie.

MyDMAM can handle brute force login attempts with the conf/app.d/access_control.yml configuration file. You can white, black or never block some adresses ranges in IPv4/IPv6. Blocking can be tuned with a max attempt count and a grace period time.

SQL injections are not possible either… because MyDMAM does not use (more) SQL. In other cases, Play checks the entries, sometimes, for other reasons, it is the Json deserializers that do this work. Either it can take it, and then the data is processed and usually sent to the base, via the Java API of the database (and in fact, it will be hard to inject something). Otherwise a silent error for the client.

Web access is HTTP, but you can configure Play in HTTPS and / or put an HTTPS reverse proxy in the front end.

If Play is configured correctly, the URLs will follow. If the cache engine is centralized by a memcached, you can have as many Play servers as you want. Isolate your memcached server from your network.

Play is by default put into prod mode, without the errors (server side) displayed on the client browser. The dev mode should only be enabled if you want to develop something on the web interface.

The default security features built into Play did not need to be bypassed, only extended (like the Secure module). And they have been simplified for greater readability.

The SSH private key generated for SSH / SCP functions is written with restricted rights (chmod 700).

Neither Play nor MyDMAM directly manipulate “business” (media) files in their process, but always use external processes (ffmpeg, imagemagick …). It is up to you to update them if there is a security problem. This also ensures that there will be no problems with memory overflow when processing very large files (such as the JVM memory implosion).

Access to the ElasticSearch and Cassandra databases is without authentication or encryption. So be careful with your firewall configurations if you put it in a cloud or dedicated server!

In any case, it is not yet recommended to put MyDMAM in front of the web for security reasons (there has never been a security audit). If you do, you must check as you can do:

  • Keep you informed of the activity of MyDMAM, ideally to contact me about to be aware as soon as possible of a problem.
  • Post an HTTPS front end with a true certificate.
  • Monitor logs regularly, especially with logcheck
  • Install the server updates, do it regularly
  • Backup of databases, either via MyDMAM, or directly on the base files themselves, or on the servers themselves.
  • Configure the mail client of MyDMAM, and to have added your email address. Your mail server should not take these emails for spam.
  • Use Play in prod mode, by default.
  • Have a password policy via AD / LDAP account management.
  • Train your users on social engineering techniques. But that’s another story.