Slackware Server On The Internet.

jjthomas · 06-12-2014, 04:43 AM

I am thinking of putting a server out in the wild. I run a couple of websites, one is based on b2evolution and another based on WordPress and a couple of static websites, and of course email.

I have a UPS, I’m comfortable with Linux, both Slackware and Red Hat (Centos). I’ve been hacked a couple of times, weak password (duh) and a bad script. So I know that somewhere out there, is a hacker gunning for my server.

My thought would be to set the WWW/Email server in a virtual machine. If a hacker were to get root in the VM would they be able to gain access to the host?

Has anybody put a Slackware based server on in the Internet? Any advice?

-JJ

tronayne · 06-12-2014, 06:14 AM

Yes, did that, worked.

But...

You're going to get hit (a lot) from the outside world and IP address walkers. It's a given that the bastards are going to try.

If you do a clean install on that server and pick a good root password (you do not need to password any other accounts except for any user accounts you add, such as your own account -- leave /etc/passwd and /etc/shadow alone).

I would assume you're going to be using Apache HTTP? Don't monkey with it too much, read the security section in the the HTTP documentation, implement the recommended settings (in the configuration files).

Something I did that works automagically is that I installed and run DenyHosts (http://denyhosts.sourceforge.net/:

Quote:

What is DenyHosts?

DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).

If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn't it be better to automatically prevent that attacker from continuing to gain entry into your system?

When you get hit with SSH attacks, they're trying to guess your password and they walk the administrative accounts (which you haven't screwed with and there is no way in the universe to guess or get into an account that has no assigned password and is blocked in /etc/shadow). What DenyHosts does is recognize the attempt and add the URL of the attacker to /etc/hosts.deny in which case that URL will be refused the next time it tries -- over the years, that list has grown to over 20,000 bad actors; they're blocked whenever they attempt to connect.

DenyHosts also will let you share URLs of folks attempting to gains access with other users around the world and merge their experience with yours.

Keeps 'em out of your pants.

You can, if you like, construct the lists as IPTABLES entries and a couple of other methods but I've been perfectly happy with the /etc/hosts.deny method (it's quicker and you don't have to restart IPTABLES periodically).

Other than that, you only need to use good practices. Good root (and your) passwords. Configure /etc/httpd/httpd.conf properly (Apache's documentation is real good for this). Make your web pages as secure as possible and, basically, leave the thing alone (out of the box, Slackware is already secure).

You can fiddle with IPTABLES and some other utilities that do essentially what DenyHosts does and it would be worth your time to look into them; as I say, my experience has been more that satisfactory with DenyHosts (never had an intrusion).

Hope this helps some.

enine · 06-12-2014, 09:26 AM

Put behind a network device first, a simple NAT router with the minimum number of ports open functions as a perimeter router so that narrows the attack vectors down to just the ports you have open.
Use another machine to (virtual or hardware) to separate the web pages from the back end data, i.e layered/tiered approach. Wordpress for example if I recall correctly uses a SQL back end database. So separating the Apache server from the database server helps to limit attack vectors and mitigate damage should the web server be compromised.
I run Owncloud which has an Apache web site, mySQL back end and a file store. I'm splitting the Apache front end onto anther box so even if they get into that box or take it down my database and files are still safe on another box. I'm thinking a small system like a Raspberry Pi or Beagleboard will suffice as just the web front end as my whole setup can be run on a Pi but just really slow.

Mark Pettit · 06-12-2014, 01:12 PM

I think first option should be to disable root login from ssh. Then pick a non-obvious username, login via that and then become root as required via "su -" or sudo.

I'd be hesitant to run anything PHP-based - it's insecure by design - see this article : http://eev.ee/blog/2012/04/09/php-a-...of-bad-design/

Then run a decent firewall - any one that suits you. I prefer shorewall, but there are dozens of others as good, maybe better.

Finally - run the minimum stuff that you need. You might want to consider Nginx as your webserver - I believe it has a built-in email option. Might be simpler to setup.

eloi · 06-12-2014, 01:14 PM

I wrote this time ago:

Code:

#!/bin/sh
# block SSH hackers IPs.

[ $UID -ne 0 ] && echo "You must be root to run this" && exit 1

dir=/root/bin

mv $dir/iplist /tmp/old-iplist

grep -o 'Invalid user .* from .*' /var/log/messages \
       	| awk -F ' ' '{ print $5 }' | sort | uniq >>/tmp/new-iplist

cat /tmp/old-iplist /tmp/new-iplist | sort | uniq > $dir/iplist

# Clean empty lines
sed -i /^$/d $dir/iplist

# Clean firewall rules
/etc/rc.d/rc.firewall restart >/dev/null

while read line ; do
	iptables -I INPUT -s $line -j DROP
done < $dir/iplist

rm /tmp/old-iplist
rm /tmp/new-iplist

exit 0

I think I posted it here time ago. Add it to a cronjob.

David Banner
Scientific

Cesare · 06-12-2014, 02:45 PM

I wonder what would happen if tried to login as "hokus pokus 0.0.0.0/0" into a system where this script is running in a cron job.

szboardstretcher · 06-12-2014, 02:55 PM

Yeah, that script is a terrible idea without further cleansing of user generated data.

ReaperX7 · 06-13-2014, 01:35 AM

Make sure you use a System, host, or network intrusion detection system setup, a good firewall script with proper ports open as needed, and follow proper security protocols and you should be good.

Snort and Samhain should be a good start as well as suricata. You should also perform attack simulations on your system to check for flaws.

eloi · 06-13-2014, 03:30 AM

Quote:

Originally Posted by Cesare

I wonder what would happen if tried to login as "hokus pokus 0.0.0.0/0" into a system where this script is running in a cron job.

So, you thought that I try to solve all with that script?

The examples of shell scripts I use to share are simple and minimal for a reason: to encourage others to write their own themselves. If you find bugs on my example, it did its job ;-).

The idea is to discourage the typical "download this friendly application that do the job just pushing a button", what usually Windows users do.

eloi · 06-13-2014, 04:05 AM

Quote:

Originally Posted by szboardstretcher

Yeah, that script is a terrible idea without further cleansing of user generated data.

If you need to let users ssh access to your server this script is obviously a terrible idea. But, in a 'web' server, if you limit ssh access to just one user (you) just adding a pair of conditionals to that script to filter your user name and the ip addresses you don't want to be blocked would be a first step.

kikinovak · 06-13-2014, 05:48 AM

Here's something that just works, a stanza from my rc.firewall:

Code:

# Limited SSH
iptables -A INPUT -p tcp -i $IFACE_INET --dport 22 -m state --state NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp -i $IFACE_INET --dport 22 -m state --state NEW \
  -m recent --update --seconds 60 --hitcount 2 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp -i $IFACE_INET --dport 22 -j ACCEPT

I'm using this on a production web server running Slackware64 14.1 and hosting several mail and web domains for clients.

Cheers,

Niki

eloi · 06-13-2014, 06:31 AM

Quote:

Originally Posted by kikinovak

Here's something that just works, a stanza from my rc.firewall:

Code:

# Limited SSH
iptables -A INPUT -p tcp -i $IFACE_INET --dport 22 -m state --state NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp -i $IFACE_INET --dport 22 -m state --state NEW \
  -m recent --update --seconds 60 --hitcount 2 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp -i $IFACE_INET --dport 22 -j ACCEPT

I'm using this on a production web server running Slackware64 14.1 and hosting several mail and web domains for clients.

Cheers,

Niki

Well my iptables knowledge is basic, someone please correct me if I am wrong.

Till I know iptables commands override each other. I mean you end allowing input access through port 22 to anybody. Is that your intention?

eloi · 06-13-2014, 07:44 AM

Finally,

If you really don't want to be bothered by bots trying to hack your server via ssh then set an alternative port in sshd_config file (and in your firewall).

Mark Pettit · 06-13-2014, 07:44 AM

Er - that effectively "switches on" network access to port 22. But after that the user STILL has to authenticate - which means there has to be such a user on the machine, with either a matching password or matching keys.

eloi · 06-13-2014, 07:51 AM

Quote:

Originally Posted by Mark Pettit

Er - that effectively "switches on" network access to port 22. But after that the user STILL has to authenticate - which means there has to be such a user on the machine, with either a matching password or matching keys.

There is the annoying side effect of your logs filled by that hacking attempts. The alternative port, like I say above, is the cleanest (and cheapest) solution.