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 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.