So, maybe, let's simplify a little.

• Install Slackware, use a good password for root.
• Configure your network connection (preferably Ethernet, not wi-fi). Include your ISP or other DNS server addresses (two at most).
• Open any necessary ports in your router; e.g., 22, 80, 123. Don't open any others. You're going to need SSH access to administer the thing unless you attach a monitor, keyboard and mouse.
• Download and apply all patches (including the kernel patches if it's a 64-bit box); do this before you startx.
• Add your user account, use a good password.
• Think through what you're trying to do; i.e., what are your web pages going to provide. If you're going to do LAMP (or LAPP -- PostgreSQL instead of MariaDB), get familiar with data base security and apply it now.
• Configure HTTP appropriately, taking all security measures.
• Figure out what to do to keep script kiddies and robots out of your universe be that any of the suggested firewall and other security tools recommended above. Don't overdo it but don't underdo it either -- make the thing usable, trust but verify. Want to allow Google's or other search engines robots? OK, but make them secure. Otherwise, shut 'em off.
• Carefully review your web pages. Use whatever tools you can find to fix any grammar and syntax errors or omissions there may be, apply any security methods as recommended by Apache and other sources. Build in log in and password mechanisms for web access users, use HTTPS, don't grant access without an e-mail verification.
• If necessary, split your data bases off on a secure server, follow the Amazon model.

Accept that SSH works and works well (so far anyway), but use and insist upon good practice (require a unique passphrase) for any SSH user. Every SSH user has a unique environment in their account home and anything they or you do gets logged -- review the logs at least weekly.

Lots of folks are evaluating OpenSSL as a result of Heartbleed and there have since been more than one fix applied -- subscribe to the Slackware security mailing list and apply security patches as they become available (for anything, not just SSH and OpenSSL).

Consider using the "hosts" files in /etc. You add host names and addresses to /etc/hosts.allow and /etc/hosts.deny (and, of course, /etc/hosts). The communications system looks in the /etc/hosts files before looking externally. You can really lock things down with them without resorting to lots of overhead. It might be old-fashioned, but it works.

There are probably more security tools and methods than you can shake a stick at... well, not probably, there are. You need to review and decide on what you need to do to make your system (and your clients!) secure. The really good sources are Apache, MariaDB and PostgreSQL security documentation, throw in PHP documentation for good measure, eh?

Hope this helps some.

3 members found this post helpful.

There is also a fail2ban SlackBuild available:

1 members found this post helpful.

I wouldn't even open ssh on the internet. If you go with the original scenario of running your web server as a vm just use the vm console to manage it or just allow ssh from the host. Make a snapshot of the vm once its running then if its ever gets 0wn3d you just replace it with the working snapshot.

3 members found this post helpful.

You know what, people here are right. Learning iptables, shell scripting, sshd configuration, all a stupid waste of time. Just install Fedora that surely will come with a friendly graphical interface to configure your firewall and other "professional" tools that will do the job for you. When something get broken report the bug to RH.

Or better, use Windows Server, easier.

By

The iptables rules above limit SSH access on my server to one attempt per minute. Which effectively kills all the brute force attacks.

KISSH principle

That's a very strange thing to say. The whole point of SSH is that it's a secure protocol for connecting to remote machines over the internet. I don't see how a browser-based, SSL-encrypted session to a VM console could possibly be considered more secure. If a properly configured, locked-down SSH is not secure over a WAN link then why don't we give up altogether?

1 members found this post helpful.

You said 'add this to a cronjob.' You didn't offer any of these caveats originally. That script is a terrible idea and it's dangerous IMO.

Each end user might need something different, depending on their skills and abilities. Sarcasm and internet anger aren't going to get the user a solution.

All help is obviously appreciated, but I consider it wrong to offer a 'secure' solution when you know that it isn't secure. And if you don't know whether it is secure or not, it's ok to offer it up and say something like 'this is what i do, but i don't know if its secure or not, any opinions?'

1 members found this post helpful.

Seriously, just use fail2ban. It scans your log messages for suspicious activity, and bans the offending ip addresses.

2 members found this post helpful.

Tiered approach. Terminate your SSH management connection into a different box. Then if your web server is unresponsive due to ddos or some other exploit you can down it from your vmware console or lights out management board for a hardware server.

I understand just reading the rules about the limit. My doubt is if your last rule doesn't override the others. I am not a iptables expert that's why I ask.

The better way to be secure is *you* to know what happens in your system. If you will 'cut and paste' advices in forums you are taking the wrong way (to not use a offensive word). If you will use ready solutions you're taking the wrong way.

What I posted here is an 'example', I assume that being this a Slackware forum users will not take it like a click_here.exe . Cesare is surely clever enough to add i.e. grep -v '0\.0\.0\.0' in the filter pipe.

Giving users a 'solution' is not a good practice. You're spoon feeding them that is so dangerous, destructive and insecure in the long term as closing the code. I had to work teaching, the typical thing you do when you're a newbie teaching is giving the other 'all' the information. Wrong. Draw an ear, a nose, some hair and let the pupil to complete the face. The other must put some from him, not to be passive.

You've said it yourself 'Each end user might need something different', that exactly what each end user must take in care. Would you paste here a 200 lines shell script useful for everyone in any case? Is that clever for you?

By the way, please, help giving some example of why that script is so "dangerous".

Great information. I just setup for the "Commercial" package from my ISP. $15 more than my "Residential" package. Basically it opens all but the NetBIOS and NNTP ports. NetBIOS is already blocked at the router and I don't plan to host newsgroups.

Since the computer is located next to my left knee cap, I really don't need port 22 open.

I plan to install Slackware 14.1 without a desktop and X. Webmin will do most of the work.

I like the Denyhost and plan to use it.

I've been using FirewallBuilder to make my iptables. I've also configured iptables from the command line.

I looked at the shell script when you posted it and my first thought was how to build on it. I'm one of those types that starts changing things to suit my needs as soon as the installation is done.

Since this will be a virtual machine, the snapshot idea is a great one. I don't think it would be worth the time to spread this across different boxes (VM's in my case). If they root my VM, I may lose a couple of days work of work. NBD.

As I think about this the only thing I need coming in from the Internet is http, https and e-mail.

Thank you.

-JJ

Well if you run it headless, you'll need to access via ssh anyway but you can restrict access just to your LAN.


My experience.

I had Slackware running in a VPS like a web server years ago. I gave up with that because I needed it like a business solution and I found VPS not reliable enough (a real dedicated server was too expensive to me). That was my first time (true is I had studied intensively how to do it) and I had no need to use Webmin, FirewalBuilder, shorewall, GYMfromDuo, AB Prince PRO, etc. I configured all manually. What's the sense of doing it in the Windows way? I mean, before using artificial fertiliser in my home made vegetable patch I buy the tomatoes in Lidl :-).

I did something similar to what Mark Pettit told, I disabled root login in sshd_config and allowed ssh access only to one common user. So, it's very difficult that some one could crack it via a brute force attack, the annoying thing is that that brute force attacks fill your logs day after day.

In that scenario, the script I shared here did the job. The only thing I had to care was to filter my user name. This script is not convenient with a lot of users with ssh access granted, if someone put the wrong password his IP will get blocked. Instead of using iptables I could write the output to /etc/hosts.deny (following tronayne advice) avoiding the need of restarting the firewall. Anyway, I assume you will monitor your server, this is not a "push the button and forget about it" solution. Dangerous? Well, not less than any software that automate blocking IPs.

I saw every day the hacking attempts in /var/log/messages, they disappeared using an alternative high port (i.e. 3200) in sshd_config. That's why I told that's the better solution in this scenario. That avoids blocking IPs, that's not a nice solution.

I've had VPS for years on a CentOS server. I've always managed to figure out a way to keep the break-in attempts out of my messages (log). I think log rotation should keep the logs manageable. The VM will be install on a pair of 230G drives in a RAID1 configuration.

The Windows way does not bother me. The computers are to serve me, not the other way around. There are a lot of things I do from the CLI as well as from a GUI. I'm one of those "Which ever works" type of guy.

-JJ

It's not about how much disk your log files consume, it's about readability. Of course a "Windows type of guy" doesn't bother about monitoring.

Using simple scripts (like my example) you know what happens and see the flaws at a first sight. Be sure that behind all 'ready to use' solutions a lot of things happen that you are not aware of. You have your computer sending spam everywhere, and effectively you're machine "works" :-).

That is true for all software, see how many years we all ignored OpenSSL bug. I mean, the simpler and clean you have your system the better is to know what happens and to have control over it. It's better a bad script of yours that a fully featured professional solution. That's why I'm against bloating, and friendly interfaces are the biggest contribution to that happens.

For the record. I have no 'religious' or 'football shirt' kind of problem with Windows OS (or capitalism). I use 'Windows' comparison to shorten all the above explanation. A lot of "Slackers" here are "Windows type of guy" ;-).


TEXT ADDED:

I'd like to add another example of what I try to say, taking advantage of some comment about PHP in this thread. You don't need to be a experienced programmer, you don't even need to be a programmer to know that PHP is a 'dialect' (I mean dirty, young). But there is a BIG difference if you write your sites from scratch (like I do), that makes you aware of PHP flaws and limitations, instead of using 'solutions'.