Tutorial Tips to securing your server

Tutorial Tips to securing your server - Printable Version

+- Sinisterly (https://sinister.ly)
+-- Forum: Hacking (https://sinister.ly/Forum-Hacking)
+--- Forum: Website & Server Hacking (https://sinister.ly/Forum-Website-Server-Hacking)
+--- Thread: Tutorial Tips to securing your server (/Thread-Tutorial-Tips-to-securing-your-server)

Pages: 1 2

Tips to securing your server - Kizaru - 08-06-2014

Now, I'm not saying these are the best methods out there, nor am I saying I'm the best at securing muh shit.
But it's what I do, it's pretty much a list of common sense that everyone should do.
Though I'll include shit that might help you on your way. I'm not writing this because of that competition. Only because I'm bored. I might as well enter it.

Content

Securing accounts and SSH
Permissions
Auditing
Things to check out and probably install

Securing accounts and SSH

Now, there are different ways of doing this, but remember, this is what I do.

First off, you should always have your own account that isn't root.
This account of course need sudo and all that shit. Not all servers come with sudo pre-installed because we don't like bloated OS right?

So just use the package manger that comes with your server.

Debian / Ubuntu

Code:
apt-get install sudo

Centos

Code:
Yum install sudo

Now to add your own user it's quite simple.

Code:
useradd -m -G sudo -s /bin/bash faggot

-m Creates the /home/folder
-G adds the user to a group
-s Specifies which shell the user is spawned with

Now that we have a qt account that's in the sudo group we can now disable some shit in SSH.
Yeah yeah, I know there was a thread just about it, but I'm going to list shit up anyways.

First off you need to edit your /etc/ssh/sshd_config because the default is stupid.

Always have this set as no.

Code:
# Authentication:
PermitRootLogin no
Protocol 2
AllowUsers you,are,a,faggot

It's a reason why we added a new user with sudo.
You can also change the port for SSH but I'm to lazy to add -p ever time I ssh into my box.
Though I wouldn't recommend putting it above 1024 as above port 1024 anyone can setup a service running there.
So if your sshd crashes another user can setup their own service running @ 1024 capturing your info and whatnot.

So yeah anything under 1024 is okey, since those are restricted to the root user of the server.

Now that we have fixed your SSH and user we can also look into creating a pair of private ssh keys to use instead of passwords, so we can have a much stronger password later.

Code:
ssh-keygen -t rsa -C "istole@your.waifu

This will generate pair of keys for you to use, one private and one public.
Now, to actually use these keys to login you need to put them on your server in the home folder of the user you are going to login into.

If you're on Linux you can always do this.

Code:
ssh-copy-id faggot@yourserverisshit.com

If you don't want to do that, you can find your key in

Code:
/home/faggot/.ssh/id_rsa.pub

And then gently place them in

Code:
/home/faggot/.ssh/authorized_keys

But if you're on winblows for some stupid reason you probably know where your public keys are.
So since you're now using your public keys to login to your server you can always change the password for your account.
An easy method of getting noice passwords is just cat /dev/urandom

Code:
cat /dev/urandom| tr -dc 'a-zA-Z0-9-_!@#$%^&*()_+{}|:<>?='|fold -w 32| head -n 4

<)cfw060-Iier^ueL?yToh|BHA|8%gI@$^xw
J<XUdc4>V*jCmc&j^DCFy*|?N:41Y2VP!b)R
:LQ++K)3!>>_kzV7|1A2g{d^FI)$sY5zkDQ8
Z}a7WP0Vg6Mx2v2Yu*wsh#x+G=O?Ts2gR9s2

Woah, finally done with accounts and SSH right? No?
Well, you can always install this nifty little shit. fail2ban
Just read that wiki if you're confused, I can't be assed to write down all the things you can do with it.

Permissions

Note: Now this is mostly aimed torwads people that run websites and all that shit.

Now since we have setup an account with sudo and disabled root login we are going to go to permissions.
Permissions is rather simple actually, we are just going to only allow root to modify files but other users should be allowed to read the files which are being served on your website.

So, how do we do this? As I've said, rather simple.

Code:
chown root:root -R /var/www/yoursite
chmod 644 -R  /var/www/yoursite

-R means it changes files and directories recursively
644 Means that only the owner ( root for us ) of the files can modify them. Normal users can read them

Of course, this means that only you ( as root ) can edit the files. If you're running software such as mybb/wordpress it would mean that they can't edit the config files which will break a few things, so I suggest giving them write permissions.

Code:
chmod 666 FilesToWriteTo.php

I would also recommend giving certain tools 700 so that only you can use them.

g++
gcc
python ( you can enable this if you're going to use python for specific stuff
mysql ( I do shit via root, but they can still access it via PHP-PDO/SQL so it's just to make it a bit worse for them )
mysqldump

The list can go on and on, it's mostly based on what you're going to use, and what you aren't going to use, since some of them can make certain task easier for the attacker.

Oh, and one last tips. Try putting this in your .bashrc

Code:
echo "umask 077" >> /etc/faggot/.bashrc

It will make all new files 700 so others can't read them.

Audit logs
Now, this is a very important thing, that can also be quite interesting if you didn't know about it.
By default, the GNU/Linux system logs a lot which can be used for fixing small issues and also finding out if your system have been touched by some rude hands.

Auth logs.

Centos

Code:
/var/log/secure

Ubuntu / Debian

Code:
/var/log/auth.log

Checking last logins for users

Code:
$ last 
 $ last <user>
$lastb

This will check the time and IP of the last logins for the current or specified user.

Checking the shared libaries for each program that you can suspect being fucked with,
such as ls and ps.

Code:
$ ldd /bin/ls
	linux-vdso.so.1 =>  (0x00007fff16b71000)
	librt.so.1 => /lib/librt.so.1 (0x00007fa1bd775000)
	libselinux.so.1 => /lib/libselinux.so.1 (0x00007fa1bd557000)
	libacl.so.1 => /lib/libacl.so.1 (0x00007fa1bd34e000)
	libc.so.6 => /lib/libc.so.6 (0x00007fa1bcfcb000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa1bcdae000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa1bd99c000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007fa1bcba9000)
	libattr.so.1 => /lib/libattr.so.1 (0x00007fa1bc9a4000)

An example of a rootkit being detected with ldd.

Code:
$ ldd /bin/ls
  linux-vdso.so.1 =>  (0x00007fff86dff000)
  /XxJynx/jynx2.so (0x00007f6ce5a3e000) // GE I WONDER WHAT THIS IS
  libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6ce5806000)
  librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6ce55fe000)
  libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f6ce53f6000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6ce506f000)
  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6ce4e6a000)
  libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f6ce4c18000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f6ce5c48000)
  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6ce49fc000)
  libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f6ce47f7000)
  libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f6ce4431000)
  libz.so.1 => /usr/lib/libz.so.1 (0x00007f6ce421a000)

Things to check out and probably install

Now we get to the fun stuff, at least I think so.

I'll make a list of useful shit that you can consider installing.

Grsecurity + pax
AppArmor
Fail2Ban
ecryptfs-utils
suhosin ( PHP hardening )

I would not recommend installing chkrootkit
http://www.exploit-db.com/exploits/33899/

Partitioning
If you have /tmp,/boot, or /var mounted on a separate a partition, you can disable direct execution of binaries in those locations by appending the "noexec" option to /etc/fstab.

/etc/fstab

Code:
/dev/sda5           	/tmp     	ext4      	rw,relatime,noexec,data=ordered	0 2

Grsecurity
Don't do this if you don't know what you're doing, it'll most likely fuck up your bootup since you're doing it incorecctly.

Grsecurity + PaX is a set of patches for the Linux kernel which are aimed for securing your shit properly. Made by our queen spender and his gang. Now, There are a lot of ways to install this but it will require you to edit your bootloader. So if you have a VPS that doesn't allow full virtualization ( Such as OpenVZ ) You can't do this, KVM however it works just fine.

There is a great starter guide on the grsecurity's webiste.
Quickstart.pdf

Debian and Ubuntu
http://kernelsec.cr0.org/

You need to add their repository.

Ubuntu

Code:
echo http://ubuntu.cr0.org/repo/ kernel-security/ >> /etc/apt/source.list

Debian

Code:
echo http://debian.cr0.org/repo/ kernel-security/ >> /etc/apt/source.list

Now to verify their repo, and update yours.

Code:
wget http://kernelsec.cr0.org/kernel-security.asc && apt-key add kernel-security.asc
apt-get update && apt-get install linux-image-grsec

Centos
I stole this off another tutorial @here Since I don't use Centos.

Code:
$ cd /etc/yum.repos.d/
$ wget http://repos.coredumb.net/grsecurity/grsecurity.repo

$ yum clean all
$ yum install kernel gradm

$ reboot

ArchLinux
Now, i wouldn't recommend using Arch for server stuff, but you can still install it on arch.

Code:
Sudo pacman -S linux-grsec paxd

Now you need to edit your bootloader such as syslinux and grub.

Don't do this if you don't know what you're doing, it'll most likely fuck up your bootup since you're doing it incorecctly. So keep the fallback as default.
syslinux

Code:
vim /boot/syslinux/syslinux.cfg

Now, you edit this.

Code:
LABEL arch
    MENU LABEL Arch Linux
    LINUX ../vmlinuz-linux
    APPEND root=/dev/sda3 rw
    INITRD ../initramfs-linux.img

To this.

Code:
LABEL arch
    MENU LABEL Arch Linux
    LINUX ../vmlinuz-linux-grsec
    APPEND root=/dev/sda3 rw
    INITRD ../initramfs-linux-grsec.img

PaX

I haven't really gone too far into configuring PaX so I'll either have a friend help me write this down. But if you want to read a good documentation on ArchLinux's Wiki. Here is the link.
https://wiki.archlinux.org/index.php/PaX

Grsecurity's RBAC// stolen from gentoo.org

Role Based Access Control

There are two basic types of access control mechanisms used to prevent unauthorized access to files (or information in general): DAC (Discretionary Access Control) and MAC (Mandatory Access Control). By default, Linux uses a DAC mechanism: the creator of the file can define who has access to the file. A MAC system however forces everyone to follow rules set by the administrator.

The MAC implementation grsecurity supports is called Role Based Access Control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you haven't thought of.

Installing gradm

Ubuntu / debian

Code:
sudo apt-get install gradm2

CentOS

Code:
Yum install gradm

ArchLinux

Code:
pacman -S gradm

Great documentaion for setting up gradm ( grsec's RBAC )
Here

Thread ends here. for now.
Should I continue writing this? I don't know if most of you find this interesting or even care to read all of this.
But if you think I should continue to write about each thing and find more stuff to make it easier to secure your server I'll probably do so.
Oh, and if you found something that I've done terribly wrong or do recommend feel free to post about it. I'm all about learning new stuff.

There is a lot of topics I haven't even started and more content I haven't. I'll probably ask some friends if they want to help me make this thread a great source of information for security.

If you want to help contribute feel free to PM me about stuff you think is either wrong or just

RE: Tips to securing your server - Dyme - 08-06-2014

(08-06-2014, 04:58 PM)Yagmi Wrote: I would not recommend installing chkrootkit
http://www.exploit-db.com/exploits/33899/

If your reason for not setting up chkrootkit is CVE-2014-0476, it was patched over two months ago.

[Image: 2EF0AmC.png]

(08-06-2014, 04:58 PM)Yagmi Wrote: So, how do we do this? As I've said, rather simple.

Code:
chown root:root -R /var/www/yoursite chmod 644 -R /var/www/yoursite

Unless your website is completely static, this will cause errors with web applications like wordpress or mybb which write and modify files.

RE: Tips to securing your server - Kizaru - 08-06-2014

(08-06-2014, 06:36 PM)Dyme Wrote: If your reason for not setting up chkrootkit is CVE-2014-0476, it was patched over two months ago.

Unless your website is completely static, this will cause errors with web applications like wordpress or mybb which write and modify files.

Yeah, I forgot to point that out. I'll edit the permission part.
Both Ubuntu's and Debian's repositories haven't updated to .50 So unless you want to manually install that shit it.
>minor bug fixes

RE: Tips to securing your server - xlogo - 08-06-2014

Some good info in there but with phases like 'all that shit' & 'I can't be assed to write down' you come across like a two year old who is embarrassed to say what they know.

Be big - be bold.

RE: Tips to securing your server - Kizaru - 08-06-2014

(08-06-2014, 07:11 PM)xlogo Wrote: Some good info in there but with phases like 'all that shit' & 'I can't be assed to write down' you come across like a two year old who is embarrassed to say what they know.

Be big - be bold.

I'll edit a few, but I still won't create a mini tutorial just about fail2ban, there is a full wiki linked that you can get a good understanding to what you're doing.

RE: Tips to securing your server - Dyme - 08-06-2014

(08-06-2014, 06:44 PM)Yagmi Wrote: Yeah, I forgot to point that out. I'll edit the permission part.
Both Ubuntu's and Debian's repositories haven't updated to .50 So unless you want to manually install that shit it.
>minor bug fixes

>CVE-2014-0476 fix (the vulnerability you referred to in the op)

And yes, installing from source might take you 10 seconds longer but hey, if I can't use apt then fuckit.

RE: Tips to securing your server - Oni - 08-06-2014

(08-06-2014, 07:33 PM)Dyme Wrote: >CVE-2014-0476 fix (the vulnerability you referred to in the op)

And yes, installing from source might take you 10 seconds longer but hey, if I can't use apt then fuckit.

Toobleedingedge4me. Joking. Although some people (often stupid) prefer to rely on repositories.

RE: Tips to securing your server - Dyme - 08-06-2014

(08-06-2014, 07:35 PM)Oni Wrote: Toobleedingedge4me. Joking. Although some people (often stupid) prefer to rely on repositories.

yes becuz we all know that becuz arch lunix uses the most up-to-date softwares it makes it unstable because bleeding edge mmm yesss this is why we download old softwares like chrootkit from debian repos cause it's stable, othr than the fact ur box could get rooted.

RE: Tips to securing your server - Kizaru - 08-06-2014

(08-06-2014, 07:42 PM)Dyme Wrote: yes becuz we all know that becuz arch lunix uses the most up-to-date softwares it makes it unstable because bleeding edge mmm yesss this is why we download old softwares like chrootkit from debian repos cause it's stable, othr than the fact ur box could get rooted.

If you are using chkrootkit you probably don't even know how to build it from source.

RE: Tips to securing your server - Oni - 08-06-2014

(08-06-2014, 07:42 PM)Dyme Wrote: yes becuz we all know that becuz arch lunix uses the most up-to-date softwares it makes it unstable because bleeding edge mmm yesss this is why we download old softwares like chrootkit from debian repos cause it's stable, othr than the fact ur box could get rooted.

There's issues with both. I'd have to agree that Arch would be much more appealing in this case. Tongue