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.

1 members found this post helpful.

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?

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?

<quote>
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.