4 ms·

Particularly with Docker a lot of security can now happen at the OS level. This is great because it requires no changes to code, particularly for super legacy a

Particularly with Docker a lot of security can now happen at the OS level. This is great because it requires no changes to code, particularly for super legacy apps where there simply is no way to secure say PHP 5.4. HTTP Security Headers. These are big. There are 8 or 9 of them now. Content Security Policy especially. GeoIP Blocking. Also this is big. I think AWS WAF lets you even filter down to the state level now if you want. This dramatically reduces the open ip space you’re exposed to. Easy to circumvent yes, but still large benefits. 4096 SSL keys. Also would disable anything below TLS 1.1 (TLS 1.2 would be better). SPF, DKIM, and DMARC records for DNS address. IP Blacklists. Lots of known malicious IP lists you can download daily and block with IPTables. If you’re using Docker, you can block via Apache mod_rewrite and a fast look up dbm file (convert from txt to dbm via httptxttodbm tool). ModSecurity. A pain to setup sometimes, but it’s not bad. Just enable a few options and you’re ready to go.

s_streichsbier 8y ago
These are excellent suggestions Bucephalus. One note though, they mainly deal with the infrastructure/network/os level security. A simple SQL injection in the code would still be exploitable regardless of the countermeasures above. So on top of what you have suggested, what are your ideas to get the security right on the code level of the applications?
- ramtatatam 8y ago
  Well said, there are tons of issues the one can encounter even with perfectly secured infrastructure. Somebody made good effort identifying some: https://www.hacksplaining.com/ https://www.hacksplaining.com/ Learn to think like somebody who will try to exploit your system and embed guards into your code as you build it.
throwawaymath 8y ago
> 4096 SSL keys. Why do you say this? You should keep in mind the following: 1. Most TLS vulnerabilities occur due to design or implementation flaws, not due to insufficient key size (in particular side channel attacks of various flavors); 2. RSA is not the only algorithm which can be used for TLS. In fact, it’s not even the most advisable one. You can also use authenticated encryption via AES-GCM or Curve25519. These are safer. “4096 bit keys” are not a coherent recommendation for these algorithms, because security doesn’t correlate with key size; 3. You generally want to choose libraries which are secure by default and don’t require (or encourage!) developers to make decisions about details like key sizes. Choose an algorithm if you kust (avoid RSA!), but limit further decision making.

s_streichsbier 8y ago

These are excellent suggestions Bucephalus. One note though, they mainly deal with the infrastructure/network/os level security. A simple SQL injection in the code would still be exploitable regardless of the countermeasures above. So on top of what you have suggested, what are your ideas to get the security right on the code level of the applications?

ramtatatam 8y ago
Well said, there are tons of issues the one can encounter even with perfectly secured infrastructure. Somebody made good effort identifying some: https://www.hacksplaining.com/ https://www.hacksplaining.com/ Learn to think like somebody who will try to exploit your system and embed guards into your code as you build it.

throwawaymath 8y ago

> 4096 SSL keys. Why do you say this? You should keep in mind the following: 1. Most TLS vulnerabilities occur due to design or implementation flaws, not due to insufficient key size (in particular side channel attacks of various flavors); 2. RSA is not the only algorithm which can be used for TLS. In fact, it’s not even the most advisable one. You can also use authenticated encryption via AES-GCM or Curve25519. These are safer. “4096 bit keys” are not a coherent recommendation for these algorithms, because security doesn’t correlate with key size; 3. You generally want to choose libraries which are secure by default and don’t require (or encourage!) developers to make decisions about details like key sizes. Choose an algorithm if you kust (avoid RSA!), but limit further decision making.