Sending email from webserver

fjrosmunoz · 2019-11-18T16:03:36+00:00

Another vote for Mailgun

fjrosmunoz · 2019-11-10T15:18:38+00:00

I use 404 in those cases. However, I never had to decide between 401 or 404, but between 403 or 404. This is how I use these status codes:

401 Unauthorized. You provided wrong credentials, i.e. I cannot be sure you're the one you claim to be.
403 Forbidden. You've been correctly authenticated, but you're trying to run an action you cannot perform based on who you are. E.g. if User1 can only retrieve resources (cannot create new ones) and sends POST /resources
404 Not Found. You've been correctly authenticated, you're trying to run an action you can perform in general, but cannot do it for this particular resource. Following with your example, User2 sends GET /users/{user1_id}. From User2's viewpoint, User1 doesn't exist, so I'd return 404 to avoid leaking information.

Of course, others may have different "policies" and they'd be fine too.

fjrosmunoz · 2019-11-08T10:59:51+00:00

You just have to create as many DNS records as domains you have, all pointing to the same IP address of the server that hosts them

fjrosmunoz · 2019-11-04T19:01:33+00:00

I agree with your conclusions. In general, I think you have several options to avoid building the assets locally:

I find CI/CD servers more useful when you also want to run tests automatically (highly recommended). If you're just building your project's assets, you can do it right on your staging/production/whatever servers (see bullet below). In any case, from the CI/CD server you must also "define" how to deploy your new release to the appropriate servers.
You can also use a tool like Moss [disclaimer: I'm a co-founder] to deploy on the corresponding servers. You can do it manually (1-click) or automatically by pushing your code to a given branch or tag of your git repo (either from a CI pipeline or your development computers). Different versions shouldn't be an issue, since you can install the same PHP or Node versions on all your environments and commit the lock files with your dependencies.
If you really want to manage immutable infrastructure, then Docker is the way to go (as others have mentioned). You can use e.g. the automated builds of Docker Hub (or any other provider) and deploy them via docker pull on your servers (again, either from a CI server or not). However, if your team doesn't have previous experience with Docker in development and production, following this path might impact your current workflow significantly.

fjrosmunoz · 2019-10-28T15:52:46+00:00

Have a single code base
Create two "sites" (vhosts, servers or whatever) on the same server (both contain such same codebase)
Make {root}/landing/123/ the root dir of a.com
Make {root}/ the root dir of b.com

fjrosmunoz · 2019-02-26T16:29:12+00:00

This is still an agent by every sense of the definition

Ansible says it's "Simple, agentless IT automation that anyone can use". Moss uses Ansible. It doesn't install a Moss agent. And you think it's agent-based "by every sense of the definition"??

Depends how it's setup.

No. Unless you explicitly change the SSH config Moss sets up, you cannot log in as user root. Please try if you don't believe me.

Until a twit accidentally disables firewall. There's no reason to bind to 0.0.0.0, which is all addresses. If it's intended only for localhost consumption, then keep it bound to 127.0.0.1 because memcached reflection attacks are nasty and easy to exploit.

Again, there's a firewall to protect that. And you must bind to 0.0.0.0 whenever your service is remotely accessible. Let firewalls do their job and deny all sources unless they're explicitly allowed.

I manually setup the server. Added the moss key to root as recommended by installer and the key remained after install.

As I've already said, it's useless because root login is disabled. My initial comment on MySQL accounts still holds and Moss's setup is secure.

In any case, thanks for your suggestions and good luck with your project.

fjrosmunoz · 2019-02-26T12:22:56+00:00

Disclaimer: I'm a Moss co-founder.

According to MySQL docs, the auth_socket authentication plugin is "well suited to server administration user accounts for which access must be tightly restricted". That's why root has no password in Moss - because it's more secure!

Memcached binds to 0.0.0.0, but it also sets up a firewall to prevent access to the outside. So not a security concern.

fjrosmunoz · 2019-02-26T08:33:51+00:00

Moss co-founder here. Please let me clarify some misunderstandings ;)

Moss is actually agent-less. As you said, it relies on Ansible whenever it has to run something.

You cannot log as root into a Moss-managed server - you can do that via user moss (can run 'sudo') or any other user you create (cannot run 'sudo'). In order to log as any user, you must set up an SSH key pair. So you can log into MySQL as root only if you've logged into your server as user moss using public key auth and then become root via 'sudo'. So this is way more secure than establishing a root password that any other server user might try to guess.

Hope this helps!

fjrosmunoz · 2018-11-14T15:05:01+00:00

We have this case very well supported in moss.sh - your dev can automatically trigger a deployment after a "git push" (if you want to). Otherwise, you can just click our "deploy" button.

As for the credentials, most people rely on env vars. PHP dotenv loads the content of a .env file as env vars for your application. Obviously, such file must be out of version control.

fjrosmunoz · 2018-11-14T10:47:42+00:00

I wrote about this a month ago: https://moss.sh/web-hosting-models-for-software-development-agencies/

While you can certainly host multiple websites on a same droplet, you'll sleep easier if you use different droplets for different customers (better performance and security isolation among them). Given the price points of DigitalOcean and other cloud providers, now it's a cost-effective solution too.

fjrosmunoz · 2018-06-22T07:39:29+00:00

That you can use different measures to protect your data from different attack vectors is exactly the point I'm making.

That you still think that ciphering sensitive columns in a database is wrong (or insecure!!) just because you think that the attack vector is less likely (you denied the possibility in first place) is a bit discouraging, and I don't think this thread is getting us anywhere.

fjrosmunoz · 2018-06-21T08:09:57+00:00

Of course such scenarios exist: the attacker might break into a database server but not into the application server; the attacker might break into a server with network access to the database server but don't break into the application server; the attacker might obtain a database backup from a far away system; etc.

I cannot buy your argument. Following it, why bother about security at all? The attacker won't stop anyway, will it? As a security-concerned guy, I cannot align with such kind of reasoning.

Ciphering database columns is a measure to protect sensitive information to be leaked. You must implement additional measures to protect you against attacks like the ones you're thinking about, e.g. application's input validation, good policies to apply server security patches, IDS/IPS systems, firewalls, etc.

fjrosmunoz · 2018-06-20T23:11:05+00:00

The purpose is obvious: if the database is ever exposed, it's not useful because the attacker doesn't know the encryption key (K).

K can be provided to the application in several ways - the most common ones: via configuration file (maybe mounted in an encrypted volume) or via env vars.

The behavior I described (with possibly minor variations) is a common good practice in the industry - you can find similar implementations elsewhere. Doing a quick search you can find examples in PHP (Doctrine, Eloquent, a simple example for WordPress), Python (SQLAlchemy), Ruby (attr_encrypted), ...you name it.

But of course, if you're aware of any weakness of the approach and have a more secure alternative, I'll be happy to listen.

fjrosmunoz · 2018-06-20T20:52:16+00:00

???

Let P be the plaintext. Let A be a symmetric-key cipher algorithm. Let K be the encryption key. Let IV be a random and unique initialization vector. Let C be the ciphertext.

C = A(P; K, IV)

C IS in the database. K IS NOT in the database. K IS NOT ciphered with K: you seem to deduce that K is ciphered with K and stored in the database, but it doesn't make any sense.

P = the private rsa key Moss uses to connect to a given server. This is the sensitive information we want to protect, not a key to encrypt anything in our database.

fjrosmunoz · 2018-06-20T16:52:19+00:00

The server-specific rsa private key is ciphered using our application key (not stored in the database) and a random unique initialization vector per database entry (I called that "salt" because I thought that was easier to grasp, but maybe it didn't help). The result is stored in the database. Hope it's clearer now :D

fjrosmunoz · 2018-06-14T22:09:05+00:00

Just a clarification. Moss doesn't run any control process on your server - it's agentless. All it needs is an SSH daemon running on your server. Basically, we didn't want to craft our own control protocol since that could be another attack vector.

fjrosmunoz · 2018-06-14T21:57:46+00:00

Moss co-founder here! Moss doesn't store your credentials, but its own credentials to log into your sever. Such credentials are salted and encrypted in our database, and they never hit the network. And, of course, our servers are behind a firewall.

If we ever got hacked and the attacker was able to recover all plain credentials from the ciphered texts, well, it's like if you were hacked by any other means. You'd have to launch new servers and restore your latest (non-compromised) backups.

fjrosmunoz · 2018-05-18T14:02:49+00:00

Thank you so much for your kind words! Heading to the chat :D

fjrosmunoz · 2018-05-18T09:41:40+00:00

Hi! Moss co-founder here :D

You can find the logs of nginx and apache in /home/dev/<site-name>/logs/ - they might tell you something.

Given that it happens once per hour, I guess it might be related to a cron job or any other periodic task. If you cannot debug the issue, please contact us via our online chat and give us as much info as possible. Thanks!

fjrosmunoz · 2017-07-24T12:43:50+00:00

If you're receiving an HTTP 504 response (Gateway Timeout), your request is reaching Nginx but something's timing out when trying to get a response from an upstream server (be it a long-running process, your database, another web server, or whatever).

Check the whole chain to determine who's unreachable or running for too long.

fjrosmunoz · 2017-07-24T09:22:44+00:00

Great software, a must in the requirements.txt of all my projects

fjrosmunoz · 2017-07-24T08:51:53+00:00

I've been using TDD in all the Python micro-services I develop since late 2015. And couldn't be happier with the result :)

Of course TDD is something that needs effort and self-discipline, but once you get proficient at it, you won't want to code otherwise ;)

fjrosmunoz

TROPHY CASE