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 questi开发者_JS百科on 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.
精彩评论