I have a security consultant demanding that we implement encrypted connections to mySQL. He is concerned that the username and pass for the db are being sent cleartext when we connect.
The mysql server is on the same network as the scripts though not the same physical machine. So the credentials will not be passed externally and should be fine unless the server is already compromised.
Am I right that SSL would be overkill?
If you need to implement this security measure, I would set up an encrypted SSH tunnel. On the web server:
ssh -L 3306:localhost:3306 -N someuser#mysql.server.address
Then connect to MySQL on 127.0.0.1 in your web app, and it will be forwarded to the remote MySQL server over an encrypted SSH tunnel.
It should be fine so long as the network isn't compromised. That doesn't necessarily mean the web or db server.
Do you trust everybody who has access to the network? (We don't know the details of your network setup, but for all we know it is shared by cheap staff in a call centre, who bring in USB sticks which they don't realize contain viruses)
Do you trust them enough considering the importance of whatever data is being dealt with?
Even if you do, unless implementing it generates a noticeable performance penalty, it is rare that implementing more security is a bad thing.
Related
Using the Arduino UNO and the ESP-8266, what are the security risks for connecting and uploading data directly from the Arduino? Instead of sending a POST request to a PHP web server with the data?
I know the PHP method is safer but I just want to know clearly what and how data is not safe that way.
I don't think web server is safer than a client application. Though you have https, a lot of database servers supports TLS too for communication, which is also safe.
But you will need to enable the encrypt feature in database server. For mysql, I think it is default to use TLS encryption so it is safe.
The differences need to be considered are:
API
direct db access: need to install DB access client software (api)
web: standard web access, no api installation required
DB exposure
direct db access: exposes db structure and authenticate. Something like user/password is stored locally on the pc and has risk of leaking.
web: only exposes limited information
server port exposure
Usually database port is only accessable in LAN. That means you can not use direct db access on WAN if the port is not open.
connection timespan
web access usually is state-less. That means one page a connection, and connection is closed as soon as page is loaded. direct db access will keep the db connection open throughout the application live period.
usually db connection count is limited. if client app is not well written it may use up all connectiions and make the database not accessible.
version control
web access: you only need to upgrade on the web server.
db access: you need to install new versions on each client pc.
performance
web access: slower than direct db access.
So if all your users are in a LAN and all pcs are trusted, I don't see a reason to introduce a web server.
I am currently working on the release of my project management software to the internet. It is my first tool that I am going to deploy in the www and I am concerned about some Security Factors. At the moment the tool is running on Apache Port 80 (https is to be done) with MySQL and PHP. I got myself a domain name which links back to the public IP of my Windows Server on which Port 80 is open for access.
I am now thinking about deploying a letsencrypt certificate in combination with the win-acme letsencrypt client.
Can the procedure be considered as safe? I would be happy if you could provide me some feedback or improvements.
I have used Let's encrypt for many websites. I have never faced any problems with it. Just make sure you install it correctly.
I suggest using a Firewall and an SSH connection with strong passwords. Setup your Firewall to allow HTTPS incoming connections(PORT 443). You can deny HTTP connections if you want and allow specific IP addresses and port ranges.
Once you do it, it will depend on how efficient your code is. One of the common web hacking techniques is SQL injection. I suggest using PDO.
Hope it helps!
I have a MySQL server installed on an Nginx server on Debian 8.
The production page on the server, say example.com has SSL installed in it.
This MySQL server will be used along with PHP to set and retrive data.
Now I am confused whether to add SSL for the connection between client and MySQL server? What is the best practice?
If the traffic runs through app to MySQL locally, your traffic is secure (as long as your linux server is secure).
You don't need ssl for MySQL to app if the app only accesses MySQL locally.
You need ssl if anyone will be accessing MySQL remotely or if your app server is remote.
You will need to worry about those two things the most.
Transport Security. Does MySQL traffic ever leave your local network? If so, is it encrypted during transmission? If you are doing everything locally, then you have nothing to worry about. If your database connection goes across internet, make sure to use SSL.
System Security. Is your MySQL server accessible from internet? Does it need to be? If not, just add rule into iptables to block all incoming traffic to 3306 that's not from localhost. Also make sure that you are using strong SSH passwords and implement fail2ban, or allow key based authentication only.
SSL is good to help protect your clients. Sniffing packets may be thwarted by SSL. For example, if someone does a credit transaction, the credit card data would not be in plain view, as the data moved between the client to the server. However, SSL is not a way to protected your SQL resources, which is backend between the web serer and SQL database server. You need to run "mysql_secure_installation" for a mysql database, and design you PHP code to prevent SQL injection issues, for example. So, yes, SSL is very important to protect your clients, but other design factors are needed to protect your backend server assets.
I'm needing to synchronise two mysql databases between different servers on a regular basis, by a client-initiated interface. I've been doing it by remote MYSQL connection, and adding the IP of the servers to the whitelist for MYSQL remote connections. Problem is however, that the client has a dynamic IP, so as soon as it changes they can no longer sync.
So I'm trying to find an alternative way of synchronising the two databases via some sort of secure php script.
edit: I should make this a bit clearer. I've got a server (WAMP) running on a PC (Win7) the database of which I need to synchronize (both ways) to an online server. I've been doing it via remote MySQL connect, which I'd like to avoid because of dynamic IPs, and also because the local WAMP server connects to different internet connections (being a laptop) and needs to not be restricted to one IP.
However you want to synchronize the databases (replication, a PHP script, etc.), the best way to secure it would be to either use an IPSec/VPN or SSH tunnel to encrypt all the communication between the two servers. Then you'd just open a regular mysql or http connection through the tunnel.
Using either method, you'll have access to a variety of authentication modes. So you could use a pre-shared key or username/password authentication or both.
You can use an SSH client like PuTTY to initiate an SSH tunnel on a Windows systems. Or if you google IPSec and XAuth, you should be able to find some guides on how to set up an authenticated IPSec VPN.
I have recently written a socket server in PHP that will be handling communication between an Android phone application and my PHP webserver. Due to the fact that Android doesn't natively support push style notifications we are going to be using our webserver as the middleware layer to handle our 'pushes'.
The socket server is stable, runs well, and seems to scale nicely. While I would eventually like to re-write this in C I don't have the skill necessary to do that right now so I am going to be staying in PHP for at least a short while. As of this moment our Android emulator is able to communicate through the server, get pushes, etc. so that part is all covered.
My concern is that, right now, anyone can open a socket to my server and will be given a client connection. While we won't be passing sensitive data back and forth I don't want to allow just anyone to connect over and receive broadcast information, eat up my resources, and clog my server in general.
The question is, how do I secure a server like this? Let's assume that I am running on port 25,000--can I set up some sort of SSL layer on that port and expect devices like the Android to be able to communicate over that port without any special protocols or jumping through hoops?
I have considered asking the connecting clients to authenticate their user against our user database before being given a client connection, but that would require the passing of credentials in plain text over the network which I am NOT about to do.
Any suggestions on this would be very helpful--I am rather new to straight TCP communication from PHP and feel like I might just be missing something simple that allows for authentication on this level.
Additional information: If I am able to get a valid username and password securely I would be using MySQL to validate the user and then accept/reject their connection based on the results of the query.
Thanks in advance..
First, I hope you've implemented your PHP socket server in a fashion that allows more than one client to be connected at the same time. This is not as trivial as it should be given the absence of threads in PHP, but it's certainly.
Now, if you already have a socket server implemented, adding TLS support is easy. Just run stunnel and have your PHP socket server only accept requests on the local interface.
I don't think SSL is really going to solve your problem. At best with SSL you can provide each client with a client certificate and do client certificate validation on the server. But you'll need to manage tons of certificates then. Or give everyone the same client certificate (not a good idea).
You'll have to authenticate the client using his credentials. You are right that you don't want to send the credentials in plain text over the network, but there are simple alternatives. Take a look at e.g. HTTP Digest Authentication (http://en.wikipedia.org/wiki/Digest_access_authentication) or xAuth (http://dev.twitter.com/pages/xauth). You don't have to implement these techniques over HTTP; you can just as well send a challenge (a realm) over a simple tcp socket after you have accepted the connection. The client should then send a valid response within a short timeframe or the server aborts the connection.
By the way, did you consider HTTP streaming? See http://ajaxpatterns.org/HTTP_Streaming
It would probably make your life a lot easier as you can rely upon some other service (e.g. Apache) doing the hard work for you, and you can focus on the business value of your application.
you might want to consider:
Cloud to Device Messaging : http://code.google.com/android/c2dm/index.html
The only drawback is that it is only supported by android >=2.2
Not sure why you guys didn't use some off the shelf messaging library/server for java, then create an android service that connects to the message broker and handles all initial authentication.
The service would simply sit there and wait for any incoming messages.
(I'm pretty sure that listening for network data doesn't power up the radio, only when the data is actually there that the radio powers up. I suspect this is how C2DM works.)
This is better then polling because you're only waiting for data. You're not constantly sending packets requesting data. But you knew that already.
I did this, (I used the rabbitmq-java library and the rabbitmq message queue server) and had push style notification for my app in no-time. Even with Android 1.5 devices.
About security:
You could also implement your own security but without having to send plain-text passwords. Simply encrypt the passwords using something like MD5 before passing it through the network.
Then compare the encrypted password with the encrypted password you have on file.
This way, only encrypted passwords will go through the network.