Security questions/concerns, using Slack 14.1 as LAMP server.
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Security questions/concerns, using Slack 14.1 as LAMP server.
I'm setting up a production server using Slackware 14.1. It is used as a LAMP server, but it is not exposed to the Internet. It is exposed to our entire internal network.
What kind of security concerns should I have specific to Slackware 14.1, and are there any things that I should do or be aware of? For now I simply installed it, gave it a strong root password, configured php and apache, and we are off and running. No other changes were made to the default Slack configs.
The choice of security posture can only be made by you. It is a balance between providing easy access for users and defence of sensitive data.
If it is an internal network, then you need to consider the likelihood of malevolent attack and the sensitivity of the data that is being made available.
Part of security is staying up to date with the latest patches. I hope you are aware of the latest patches to Slackware 14.1 which includes php which you are using.
Another part of security is to have an appropriate firewall. You need to create an executable /etc/rc.d/rc.firewall file containing a bash script to configure iptables.
My recommendations would be to make sure you check for new patches regularly and apply them in a timely manner.
Stop any services you don't need. If you don't need nfs not running rc.rpc would be smart. Check your /etc/inetd.conf as well, recent versions of Slackware don't run much of anything by default but its always good to look at.
Check, double check and then check one more time the file and directory permissions on your web app are solid both at the http.conf level and the filesystem level.
Since you are on an internal network and you should not have many services running, iptables is not going to do a whole lot for you. There are some things still worth doing
Set up a simple policy to block connections except on say port 80/443 and ssh inbound.
You might consider restricting the server from initiating outbound connections as well if someone is get Apache, php, or your application to execute code they have uploaded in some way this may prevent them from acquiring a reverse shell. You will need to allow some ports out to specific sites obviously.
You can use use iptables xt_recent ( -m recent ) to limit the rate of connections to the server from an single source, this can provide some protection against some attack tools like dirbuster and such and make it much harder to find vulnerabilities for an attacker, but you need to really understand the use patter of you application because you might drop lots of legitimate connections from heavy users as well.
With just a few services running and everything patched Slackware should be a pretty hard target.
Check, double check and then check one more time the file and directory permissions on your web app are solid both at the http.conf level and the filesystem level. ...
I found file ownership all set to root. And my predecessors seemed to think that a lot of the files should be chmod 777.
I'm the only one that maintains the server, and there is a backup person that doesn't know much about linux or web servers. I set the files to chmod 644. Is there any compelling reason not to let root retain ownership of the files? I can set ownership to my account, but if I get run over by a bus, no one else could get to them without using the root account. I could create a separate account for this, I suppose, is that the "best practice", to have a separate account for ownership of all the htdocs files?
...Part of security is staying up to date with the latest patches. I hope you are aware of the latest patches to Slackware 14.1 which includes php which you are using....
I don't use the Slackware supplied version of php, apache, or mysql (now mariadb). Instead, I get the versions I want (right now the current version) of these, and I have php highly customized for our application. I'm probably going to lock down the versions as this system moves towards production.
Does that ring any security alarms, using more current versions than the Slackware supplied versions?
Does that ring any security alarms, using more current versions than the Slackware supplied versions?</quote>
In generally speaking no, but you will obviously have to watch those projects for security updates and patches. You probably want to stick to what those projects define as 'release' versions of those projects; so that you know there will be a security patch if a vulnerability is found that does not include other changes you might not be ready to integrate.