I want to buy SSL and add to my domain, but my concern is about performance and speed. my concern is: Will SSL affect the speed of my chat app ? as it is implemented with socket.io.
currently I am connecting with http : // mydomain.com but after adding SSL I would use https : // mydomain.com, so will https affect the speed of my socket.io app ?
My conditions is:
Performance and speed is a must
Security also is a must
If security is a must then you should use SSL. It prevents people from being able to listen in on your conversations so I wouldn't trust a site if it didn't have a signed SSL certificate.
The impact on performance is so negligible that I wouldn't worry about it. There are so many other things you can do to improve the speed of your app that if your app is ever noticeably slow, it probably won't be due to SSL.
Obviously, if security is important to you, then you should indeed encrypt your network traffic with SSL/TLS.
There is technical overhead to establishing a new SSL/TLS session, and encrypting/decrypting traffic back and forth. But on modern CPUs/networking hardware, that overhead is usually negligible, you may not even notice any delays. Years ago, that was not the case, but technology has evolved alot since the early days of the Internet, and now use of SSL/TLS is very commonplace, even recommended/required in many modern systems.
Related
I built a web application with low traffic so far, after making some advertising I realized there are some suspicious requests against my server, this is what Loggly service shows me in panel:
Logs from Loggly about nginx requests
I am not an expert in security information buy I'm suspecting that someone wants to attack my site or are preparing a future attack.
What does these logs mean exactly?
Should I worry too much about this behavior?
are they using some exploit scanner software ?
I am setting a web application firewall to add some rules to DNS and changing all admin passwords but what other recommendation I must keep in mind?
Yep, some person or bot is using a vulnerability scanner to poke your server.
Unless it's excessive or causing stability issues, this is normal traffic. Every node that's accessible online will see attempts like this, and if you follow basic security practices (e.g. be up-to-date with os/app patches, use 2FA for logins, shut down unnecessary services/ports, vigilantly monitor your logs and usage, or at a bigger scale: invest in WAF, IPS/IDS products or use a vendor like Cloudflare), you shouldn't have much to worry about.
The culprit is Jorgee Security Scanner[1][2]
[1] https://www.checkpoint.com/defense/advisories/public/2016/cpai-2016-0214.html
[2] https://blog.paranoidpenguin.net/2017/04/jorgee-goes-on-a-rampage/
I've found other answers to my question on StackOverflow, but they are old, and things have changed a lot when it comes to security.
I would like a year 2017 re-evaluation of the answer to this question:
Inside my company, should my database require TLS connections from our internal client applications? My database has customer data that would constitute a Yahoo-sized public relations disaster if it leaked. But my client applications are firewall'd away from any public internet access.
TLS is used to prevent someone from sniffing traffic. But from my understanding (correct me if I'm wrong) the only way sniffing traffic is possible is to be a root user on the source or destination server. (assuming we don't have shared Ethernet hubs and such)
The may be be another way to sniff traffic if someone has direct physical access to the network switches in our datacenter.
But trying to protect ourselves against root users and datacenter employees seems overkill to me, especially given that TLS does come at a considerable cost in terms of performance, complexity, and maintainability.
Or is this just one of those situations where we need to be absolute in our security choices rather than try to reason cost-benefit, because cost-benefit is impossible to calculate accurately when it comes to security breaches anyway?
Thanks! :)
Using TLS for an internal network helps simplify the threat model. More would have to go wrong in order for the transmitted data to be leaked to an adversary.
An adversary who has compromised any system on the same network as the database can use ARP spoofing to reroute traffic. From a threat modeling perspective, this increases the attack surface, and every system on the same network needs to have the same security guarantee. Many routers have a configuration option that protects the ARP table from such attacks - and this option can be disabled by a firmware update. Using TLS is defense-in-depth because this measure protects core assets, even when other systems fail.
I am planning to start my first website. The website is a little HTML5+CSS+JS website with a backend running node.js that serves the data stored on mongodb. I would like to know which one is the best solution regarding mostly the security:
Web hosting (SSL and cloudflare) + VPS serving on port 3000 (with SSL, cloudflare and node.js with sensible data;users and pass and a local mongodb)
Everything in the same VPS.
Any other approach you can give.
The thing is that in the first approach there are two elements in the architecture so if someone wants to hack it i suppose it's more difficult. On the other hand in the second approach if the VPS is hacked everything is hacked and they could access to passwords, mongodb database. I am quite obsessed with security as it is my first website and i don't know what meassures to make to protect my VPS (node.js and mongodb).
Furthermore, i would like to know in terms of efficiency which would be best solution imagine for a 10MB website with 1.000 visits a day.
Regardless of how many actual servers you decide to deploy on, I'd strongly suggest not serving your site directly from node.js. Instead, proxy it through a more robust http server such as Apache or Nginx or even lighttpd. For the very simple reason that the http module in node.js was never meant to protect against worms and hacking attempts and various other malware.
I've written web servers from scratch myself and have noticed that in general, you'll get your first hacking attempt within the first hour of putting your server online. You'll get around a dozen or so hacking attempt per day on the slowest days and it goes up from there. These attempts are so common that most server software no longer log them in access logs and simply block them.
From my own personal experience I estimate that around 5% to 10% of my bandwidth is consumed by failed hacking/infection attempts. That is when I'm not being actively attacked.
Security through obscurity is not good security. Especially since node's http module is not very obscure in the first place and someone is bound to find a hackable weakness one of these days.
Apart from security, you also waste fewer CPU cycles ignoring these hacking attempts in Apache or Nginx compared to node.js since you don't need to run any javascript code to handle them.
You can make the choice between the two architectures moot. Both architectures are hackable, and your data will be exposed.
If security is paramount, check out Mylar - it's a platform that protects data confidentiality even when an attacker gets full access to servers. Mylar stores only encrypted data on the server, and decrypts data only in users' browsers.
It runs on top of Meteor, which in turn runs on top of Node.js and uses MongoDB, so if your web app is small, it should be easy to port the code. Meteor also stores passwords using bcrpyt, the best
password hashing algorithm nowadays.
Wondering if ReSTful webservice is really the answer in my case of Enterprise application where there are some security concerns such as avoiding man-in-the-middle attacks, ensuring that a trusted client is connecting, client being sure that it is indeed talking to the real server etc.
Is HTTPS the solution? Have read some concerns being raised about its adequacy and fitment, although with a not-so-strong background in IT/application security, don't quite understand, why so!
I see ReST being talked (/ raved) about, and being projected as The-thing, and do see its adoption picking up, by can't seem to understand why the security thing isn't such a big concern, and if it is, what can be done about it.
If you are really serious about securing your service and avoiding man-in-the-middle attacks you should issue certificates to your clients and only accept requests that are signed with those certificates. It is more work for you and for your clients, but in an Enterprise setting, the extra effort may be worth it. It is definitely an option that is worth looking into.
Out of the box you are not going to have any type of message level security, and you would need to leverage HTTPS to do transport level security.
I have seen people attempt to use signed atom feeds, but its nothing to the level of the WS-* stack that comes with SOAP.
We need to host a java richfaces/hibernate app in our hosting service. As a requirement of our security department we cannot make any connection from that application to our internal databases. One suggested solution was to make an internal webservice, but changing all the database layer is hard. I want to use AJP instead. Is it secure enough?
[Edit]
By asking this I mean the apache httpd will be serving https and by wrapping AJP to go inside our internal servers may the channel be monitored (plaintext)? I don't find documentation of the protocol itself.
AJP is a direct replacement for HTTP between a front-end web server and a back-end app server. As such, it's no more or less secure than HTTP. If you choose AJP, you choose it purely for performance reasons, nothing else. If you're considering it for other reasons, you need to rethink your requirements.
Secure enough for what ? Plaintext monitoring across the net ? Secure enough that an average SO reader can't intercept and read it ? Or the NSA ?
Security is a trade-off, and you need to determine what sort of attacks you're trying to repel, and how much effort you're going to put in. I know that doesn't answer your question, but I don't believe that question can be answered without thinking about this.