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!
Related
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 have been trying to make things work for a while now but I did not succeed. I also have done a lot of research, in vain. I really hope that someone is able to help me find the root cause of that issue:
I am trying to connect to my localhost:8000 from another computer (which actually is an arduino ethernet but that doesn't make a difference I guess) by using an ip address. I set the ip address manually in network settings (192.168.1.5).
funny enough, the connection from the external device to 192.168.1.5:80 (which is the normal apache server) works, hence the problem cannot be IP-based.
However, the connection to the php built in webserver running on localhost:8000 does not work. I am trying to access it with '192.168.1.5:8000' obviously - I guess this can not be the mistake?
Now I am wondering what the cause of the problem is. Is anything preventing the connection to port 8000 or does the php built in webserver not respond to the manually given ip? Why does the apache respond to that IP though?
Thanks so much for any hint!!
Steffen
The built in server is, by default, only available on localhost. You have to provide a address wildcard mask, if you want to access it over the local network.
$ php -S 0.0.0.0:8000
However, please be aware of the security implications. If your machine is connected to the internet directly, automatic port scanners will find it sooner or later and may take advantage of security problems.
An address mask of 0.255.255.255 will do fine for 10...* networks, and 0.0.255.255 will do fine for 192.168.. networks.
I tried Google and it failed.
I want to set up a localhost website from my computer that people from the Internet can access...
I am using Windows Vista (64-bit). I use WAMP but am open to others... I plan on using no-ip.org for DNS.
If anyone knows of a definitive guide.. please let me know -- thanks
If you are able to setup WAMP and access your webserver using "localhost," you will need your IP. If people cannot access the IP, make sure you allow these daemons to run through Windows Firewall and if you have a router, you may need to do some port forwarding (very simple) or, if this computer is always public access, look into DMZ (demilitarized zone) to remove the computer from the router's firewall.
An easy WAMP solution is using XAMPP which is an all-in-one package.
Step-by-step guide:
http://www.dkszone.net/install-xampp-windows-step-step-guide
You need:
a webserver,know your IP adress.
If dynamic.. Dynamic DNS, this will bind your new routerIP to a domainname
make sure your router allow traffic by the port 80 and you are done!
ppl will access your home server just by setting the dynamicDNS domain.
Key points-
0) To install IIS on vista: http://www.howtogeek.com/howto/windows-vista/how-to-install-iis-on-windows-vista/
1) Your cable/dsl company has to open port 80 for you, or else it will not be accessible outside of your house.
2) You're router will have to forward port 80 to the server. You can find out how to do that here: http://portforward.com/english/routers/port_forwarding/Linksys/BEFSR41/BEFSR41index.htm
3) before picking a dns service, check if your router supports one, it is the easiest way to maintain it.
I've been learning to setup servers to use for my web-apps - and have found that my favourite (fastest and easiest to get going) setup is CentOS5.5/Lighttpd/fastcgi and SQL. I don't, however, know how secure these are out of the box - I installed them using Yum and have modified some settings to encourage PHP to play ball - is there anything I should be doing to increase my security levels, prevent tampering with my scripts?
The server doesn't have FTP, any additional users from root, mail or anything else installed at all, and all directories are owned by lighttpd:lighttpd and not CHMOD for any world use. The greater world won't ever be using the apps I'm writing, they are for personal and for my employees / partners to keep track of money and clients (hence my wish for them to be secure).
Thanks guys!
If you are talking about servers (plural) and you have the budget / ability I would encourage you to only have servers that are client facing that serve static content only. Move your PHP and SQL back to internal only.
Web server with 80 / 443 open to the world and the SSH port open only to trusted IP's or listening only on an internal interface you can access
Application server with port 80 listening only to requests from the front end web server through a private IP address (if possible). Otherwise, restrict it's access to the public IP of the front end webservers and consider having HTTPS (443) communications between the two.
Your SQL instance / server should have the same concept, only being accessible from the Application server.
This allows you to have multiple levels of security and dedicated resources to process specific tasks (FE webserving / Middleware Application serving / Backend data services)
In addition, if your FE is compromised, they wont have immediate access to your PHP source and the database content.
If it is a single server, ensure only 80/443 are open to the world and make sure you have a firewall, or firewall concepts in place, to restrict/deny access to all other ports except from trusted sources. Consider moving SSH from port 22 (default) to an alternate port ...
I have a classifieds website...
As you might imagine, as a webmaster (administrator) I need to sometimes remove classifieds, edit them etc etc.
I have my own Linux server, with root access offcourse.
Currently I have a section of my website with all administrative php scripts which I use to remove classifieds, edit them etc:
/www/adm/ //Location of administrative tools
This section above is protected today by a simple authentication using apache2.conf file:
<Directory /var/www/adm>
AuthType Basic
AuthName "Adm"
AuthUserFile /path/to/password
Require user username
</Directory>
My question is, is this enough to prevent outsiders access to my administrative tools?
Because it would be devastating if somebody with the wrong intentions got their hands on these tools. They would be able to delete all records from my databases... I do have backups, but it would mean tons of work...
What is usually done in cases like this?
Only thing I can think of is upload the administrative scripts whenever I plan on using them, and then remove them from the server after using them.
Other information which may help you decide what solution I should use:
I manage the website and server from only one and same computer
The IP adress is dynamic of that computer
I use secure ftp transfers of files to server
The administrative tools are PHP codes which communicate with the databases
I have IPTables firewall setup to only allow connections to database from my own server/website.
I backup all files every day
Thanks
If anybody else has access shell to the server, you should be very careful with permissions.
Otherwise, basic Apache auth is OK, but keep in mind that if you are using an unencrypted connection (not SSL), you password is sent as clear text across the web, so there's always the possibility of it being sniffed.
To enable SSL you need:
mod_ssl enabled on your apache
a self-signed (free) certificate
Change your apache configuration to include SSL port
You can refer to this tutorial on how to enable SSL on Debian.
A better option, on top of the usual password protection, IP restrictions, SSL, etc... is to host the tools on a completely seperate domain. Someone might guess that you have example.com/admin and try to brute force their way in, but hosting a simple login page on somecompletelydifferentdomain.com with no branding/markings to relate it to example.com is a better defence yet.
Apache auth can also restrict by IP address, so if you have a static IP, using that and a password should be pretty safe. I would also use AuthDigestFile instead of AuthUserFile if you're worried about attacks.
This page explains it well:
Unlike basic authentication, digest authentication always sends the password from the client browser to the server as an MD5 encryted string making it impossible for a packet sniffer to see the raw password.
If you must have direct remote access to the administrative tools, find an out-of-band way to prevent the web server from running them at all when they're not needed. You might, for example, do a chmod 000 /var/www/adm under normal circumstances, change it to something usable (say, 500) when you need to use them and back to 000 when you're done.
Better would be to secure the entire path between you and the administrative tools:
Use port knocking to enable SSH on some port other than 22 (e.g., 2222).
Lock down the sshd on that port to whatever your requirements.
Run a separate instance of your web server that listens on a port other than 80 (e.g., 8080) that can't be seen from the outside and has configuration to allow access to /var/www/adm but restrict access to the local host only.
When it comes time to use the administrative tools:
Knock to open the SSH port.
SSH into port 2222 and establish a tunnel from 8080 on the remote host to port 8080 on the server.
Use the remote browser to visit localhost:8080 and access your tools. The server will see the connection as coming from the local system.