d5_0x02_DNFWAH_debian_gnu-linux_security_chklist_hardening

eZine lover (@eZine)

Published in 

Do not fuck with a hacker

 · 5 years ago

  

 
[sth0r@shawn-fortress]$ uname -a 
Linux shawn-fortress 3.7-trunk-686-pae #1 SMP Debian 3.7.2-0+kali8 i686 GNU/Linux 

|=-----------------------------------------------------------------=| 
|=-----=[ D O   N O T   F U C K   W I T H   A   H A C K E R ]=-----=| 
|=-----------------------------------------------------------------=| 
|=------------------------[ #5 File 0x02 ]-------------------------=| 
|=-----------------------------------------------------------------=| 
|=----=[ Debian GNU/Linux security checklist and hardening ]=------=| 
|=-----------------------------------------------------------------=| 
|=-------------------=[ By Shawn the R0ck   ]=---------------------=| 
|=-----------------------------------------------------------------=| 
|=-----------------------------------------------------------------=| 
|=-------------------=[ Update: Apr 8 2015 ]=----------------------=| 
|=-----------------------------------------------------------------=| 

--[ CONTENTS 

0. About this doc 

1. Security updates 

2. Vulnerability Assessment 

   2.1 GCC mitigation 

   2.2 0ld sch00l *nix file auditing 

   2.3 GNU/Linux's auditd 

   2.4 T00ls 

3. Kernel security 

   3.1 Apparmor 

   3.2 SELinux 

   3.3 Mempo kernel 

       3.3.1 PaX/Grsecurity 

4. SSL/TLS Checklist 

   4.1 Ciphersuites in Apache2/Nginx 

   4.2 OpenSSH 

       4.2.1 OpenSSH in post-prism era 

5. Web security 

   5.1 Web server( Apache/Nginx?) 

   5.2 WAF( Web Application Firewall) 

6. Security standard 

   6.1 STIGs for Debian       

7. Reference 

 

--[ 0. About this documentation 

GNU/Linux already become one of most important fundamental element in 
*modern* IT platform. Almost every important applications heavily rely 
on the core component of GNU system: GCC, Glibc and linux 
kernel. GNU/Linux is totally free/libre and open source software( 
FLOSS). Many people thinks free/libre and open source software is 
secure because its open to many eyes. Yes, that's true. According to 
Coverity's report: 

http://developers.slashdot.org/story/14/04/16/2021227/code-quality-open-source-vs-proprietary 

The source code quality of FLOSS project are better than closed 
software systems. But the FLOSS is not unbreakable. This documentation 
is going to discuss something we should know about GNU/Linux security 
operations. These examples in this doc has been tested only on Debian 
GNU/Linux 7.5. 

 
--[ 1. Security update 

Follow the minimal installation principle: Debian is providing mini 
installation iso. 

To check which packages need security updates: 

#sudo apt-get upgrade -s | grep -i security 

 
--[ 2. Vulnerability Assessment 

Know your GNU/Linux system as your *enemy* does. Your enmey might hide 
in the shadow and watch and learn the ways you've been using the 
system. As a defender, some philosophical ideas( thanks to Bruce 
Schneier) should be kept in mind: 

https://www.schneier.com/essays/archives/2000/04/the_process_of_secur.html 

----------------------------------------------------------------------- 
Security is NOT: 
* Security is NOT installing a firewall 
* Security is NOT a Product or Service 
* Security is Not a Product; It's a Process 

Security is: 
* Security is a Process, Methodology, Costs, Policies and People 
* Security is only as good as your "weakest link" 
* Security is 24x7x365 ... constantly ongoing .. never ending 
----------------------------------------------------------------------- 

A security system is only as strong as its weakest 
link. Defense-in-depth seems the only option we have. You should be 
the best professional paranoia and also need a proper threat 
model. "Who's gonna attack your system" would be daily bread for your 
mind;-) 

Those two articles are good examples of assessing GNU/Linux distros: 

https://labs.mwrinfosecurity.com/blog/2010/06/29/assessing-the-tux-strength-part-1---userspace-memory-protection/ 
https://labs.mwrinfosecurity.com/blog/2010/09/02/assessing-the-tux-strength-part-2---into-the-kernel/ 

"checksec.sh" is very useful tool from trapkit: 

#wget http://www.trapkit.de/tools/checksec.sh 

Be very careful with those binaries, which has suid( or sgid?) bit: 

#!/bin/bash 

SETUID_PROGS=`find / -type f -perm -4000` 

echo $SETUID_PROGS 

for i in $SETUID_PROGS; do 
        ./checksec.sh --file $i 
done 

 
----[ 2.1 GCC mitigation 

setuid binaries are highly risks if the program had the bug that can 
be exploitable.  The setuid binaries should be protected under GCC's 
mitigation.  We only examine 4 mitigation options here: 

http://phrack.org/archives/issues/67/13.txt ( some GCC mitigation 
description from one Phrack paper, thanks pi3..dude, did I owe you a 
beer?) 

*) NX 

This feature can prevent shellcode execution on the stack.  This 
mechanism can be implemented by hardware or software emulation. Take a 
look: 
  
http://en.wikipedia.org/wiki/NX_bit  

In GCC's options, NX is enable by default. If you want to turn it off, 
use "-z execstack". 

Check method:  
shawn@shawn-fortress ~ $ readelf -l a.out | grep GNU_STACK  
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x8 

*) Stack canaries (canaries of the death) 

This is a compiler mechanism, in contrast to previously kernel-based 
described techniques. When a function is called, the code inserted by 
the compiler in its prologue stores a special value (the so-called 
cookie) on the stack before the metadata. This value is a kind of 
defender of sensitive data. During the epilogue the stack value is 
compared with the original one and if they are not the same then a 
memory corruption must have occurred. The program is then killed and 
this situation is reported in the system logs. Details about technical 
implementation and little arm race between protection and bypassing 
protection in this area will be explained further. 

GCC options: 
-fno-stack-protector,  do not add any canary onto any functions 

-fstack-protector, only add the canary onto a few functions in compile 
 time 

-fstack-protector-all , add the canary onto all functions, be cautions 
 about this one. It'd be triggered the heavily performance hit. 

-fstack-protector-strong, add the canary onto those functions, which 
 the stack buffers would be used. This is a smart one. But its only 
 supported by GCC 4.9.x. Kees Cook shared a very good writing here: 

http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/ 

 
Check the symbols in an elf file:  
#readelf -s ./a.out | grep stack_chk_fail  
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (3)  
    52: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@@GLIBC_2  

*) RELRO  

RELocation Read-Only.  

Turn it on: -z norelro  
Turn it off: -z now  

Check elf header to find partial-RELRO:  
shawn@shawn-fortress ~ $ readelf -l a.out | grep GNU_RELRO  
  GNU_RELRO      0x0000000000000e28 0x0000000000600e28 0x0000000000600e28  

Check elf's dynamic sections to find fully-RELRO:  
shawn@shawn-fortress ~ $ readelf -d a.out | grep BIND_NOW  
 0x0000000000000018 (BIND_NOW) 

*) PIE 

PIE enforces every process's code segment is mmap()'d, it begins at a 
different base address at each execution of the application. 

Note: mmap()' is always used no matter what the type of the executable 
is (PIE vs. non-PIE).For non-PIE binaries the kernel uses an internal 
flag equivalent to MMAP_FIXED when mapping program headers. 

http://en.wikipedia.org/wiki/Position-independent_code  

GCC option: -pie, it only work for sec mitigation when kernel enables 
ASLR. 

no PIE:  
shawn@shawn-fortress ~ $ readelf -h a.out | grep "Type:[[:space:]]*EXEC"  
  Type:                              EXEC (Executable file)  

PIE:  
shawn@shawn-fortress ~ $ readelf -h a.out | grep "Type:[[:space:]]*DYN"  
  Type:                              DYN (Shared object file) 

 
These exploit mitigations provided by GCC will definitely increase the 
cost of attackers. We all did believed so...until shit happened( as 
always?). Hector Marco released a method: 

http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html 

that can bypass NX/ASLR/PIE/CANARY mitigations locally/remotely 
easily. After these years of debating and bragging about how secure of 
GNU/Linux is/was and we finally ended up in*One mem infoleak can rule 
the fuc*ing GNU/Linux*!!! Damn, PaX/Grsecurity will be our last hope 
again, like a decade ago........... 

 
----[ 2.2 0ld sch00l *nix file auditing 

There are a bunch of files that could be exploited by attackers in the 
specific scene. Fortunately, FOSS( Free & Open Source) community is 
providing a lot of methods for the security audit work. They should be 
a defender's daily bread, which being part of defense-in-depth model. 

WildCards is a powerful feature in UNIX-like platform, but it can be 
exploited by attackers: 

http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt 

-------------------------------------------------------------- 
find / -path /proc -prune  -name "-*" 
-------------------------------------------------------------- 

World-writable file audit 
-------------------------------------------------------------- 
find / -path /proc -prune -o -perm -2 ! -type l -ls 
-------------------------------------------------------------- 

World-readable file audit, correct permission: chmod 640 /var/log/ 
-------------------------------------------------------------- 
find /var/log -perm -o=r ! -type l 
-------------------------------------------------------------- 

Check if files were orphange 
-------------------------------------------------------------- 
find / -path /proc -prune -o -nouser -o -nogroup 
-------------------------------------------------------------- 

List avaiable users, be cautions about who's the "user" 
-------------------------------------------------------------- 
egrep -v '.*:\*|:\!' /etc/shadow | awk -F: '{print $1}' 
-------------------------------------------------------------- 

Check which files belong to whom. Then delete the user correctly: 
#userdel -r account 

-------------------------------------------------------------- 
find / -path /proc -prune -o -user account -ls 
-------------------------------------------------------------- 

List which users are unavailable 
-------------------------------------------------------------- 
grep -v ':x:' /etc/passwd 
-------------------------------------------------------------- 

List expired passwords 
-------------------------------------------------------------- 
cat /etc/shadow | cut -d: -f 1,2 | grep '!' 
-------------------------------------------------------------- 

The correct permission should be 644 at least. 600 would be better. 
-------------------------------------------------------------- 
ls -l /boot 
-------------------------------------------------------------- 

Files with suid or sgid flags 
-------------------------------------------------------------- 
find / -xdev -user root \( -perm -4000 -o -perm -2000 \) 
-------------------------------------------------------------- 

Check if some stupid mistakes has been made( Thanks to Tim Brown). 
-------------------------------------------------------------- 
objdump -x $i | grep -i path 
-------------------------------------------------------------- 

 
Note: The main stream GNU/Linux distro( Debian, Gentoo, OpenSUSE, 
CentOS) won't have big chance to do stupid things, but it's worth to 
look at GNU/Linux platform with 3-rd party applications. Some 
commercial applications may do something stuipid like this one: 

http://lists.openwall.net/bugtraq/2014/06/04/5 

 
----[ 2.3 GNU/Linux's auditd 

One particular scene is that some m41wares( or human attackers) might 
be interested in change some file's metadata for some *interesting* 
reasons and then change it back to the original. Let's show time: 

Install auditd and make sure its on boot startup: 
#apt-get install auditd 
#update-rc.d auditd enable 

 
Config file: 
/etc/audit/auditd.conf 

Store log file: 
log_file = /var/log/audit/audit.log 

Add one policy to /etc/audit/audit.rules: 
-w /home/shawn/change-test -p wa -k  identify 

Use this test program to change the permission： 

#include <stdio.h> 
#include <sys/stat.h> 
#include <stdlib.h> 

int main(int argc, char *argv[]) 
{ 
	struct stat sb; 

	if( stat(argv[1], &sb) == -1){ 
	    perror("stat"); 
		exit(EXIT_FAILURE); 
		} 

		if( chmod(argv[1], sb.st_mode) == -1) 
		{ 
			perror("stat"); 
				exit(EXIT_FAILURE); 
				} 
				return ; 
} 

shawn@shawn-fortress ~ $ gcc change.c 
shawn@shawn-fortress ~ $ touch change-test 
shawn@shawn-fortress ~ $ ./a.out change-test 

The date of  "Modify" and "Change" should be different: 
shawn@shawn-fortress ~ $ stat change-test 

Check *who* did it: 
shawn@shawn-fortress ~ $ ausearch -i -k identify 

 
----[ 2.4 T00ls 

NMAP/OpenVAS/lynis/rkhunter/chkrootkit/metasploit/volatality/etc 

 
--[ 3. Kernel security 

Anti-DoS related: 
-------------------------------------------------------------- 
** SYN cookies is a syn flood attack protection, the default is enable( 1)： 

net.ipv4.tcp_syncookies = 1 
/proc/sys/net/ipv4/tcp_syncookies 

(optional)，if your kernel support SYNPROXY： 
iptables -t raw -A PREROUTING -i eth0 -p tcp --dport 80 --syn -j NOTRACK 
iptables -A INPUT -i eth0 -p tcp --dport 80 -m state UNTRACKED,INVALID \ 
	 -j SYNPROXY --sack-perm --timestamp --mss 1480 --wscale 7 --ecn 

echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose 

Note: SYNPROXY has been added into vanilla kernel in 3.13. 

 
** TCP FIN-WAIT-2 status lifetime, it'd be an DoS attack risk if 
the value is too big. It'd be cause remote machine doesn't have enough 
time to close the connection if the value is too small. Default is 60( 
seconds). 15 is better, you think? Further reading: 
  
http://benohead.com/tcp-about-fin_wait_2-time_wait-and-close_wait/ 

net.ipv4.tcp_fin_timeout = 15 
/proc/sys/net/ipv4/tcp_fin_timeout 

 
** SYN queue length, the bigger value can handle more connections, the 
  default is 1024: 

net.ipv4.tcp_max_syn_backlog = 8192 
/proc/sys/net/ipv4/tcp_max_syn_backlog 

 
** Device queue length, this value should be bigger than syn queue? 
   The default is 1000 

net.core.netdev_max_backlog = 16384 
/proc/sys/net/core/netdev_max_backlog 

 
** listen()'s backlog, the default is 128: 

net.core.somaxconn = 4096 
/proc/sys/net/core/somaxconn 

 
** TIME_WAIT status TCP connections, the system will empty the 
   connection if the number is exceed the value,  

net.ipv4.tcp_max_tw_buckets = 65535 
/proc/sys/net/ipv4/tcp_max_tw_buckets 

 
** TIME-WAIT status can be reuse, the default is disable( 0): 

net.ipv4.tcp_tw_reuse = 1 
/proc/sys/net/ipv4/tcp_tw_reuse 

 
** fast recycle of TIME-WAIT status connection, the default is disable( 0):  

net.ipv4.tcp_tw_recycle = 1 
/proc/sys/net/ipv4/tcp_tw_recycle 

 
** TCP KEEPALIVE probe frequency,the default is 7,200 seconds: 

net.ipv4.tcp_keepalive_time = 300 
/proc/sys/net/ipv4/tcp_keepalive_time 

 
** TCP KEEPALIVE probe packets, the default is 9: 

net.ipv4.tcp_keepalive_probes = 3 
/proc/sys/net/ipv4/tcp_keepalive_probes 

 
** how many times of SYN and SYN+ACK can be re-transimit, the default is 5: 

net.ipv4.tcp_syn_retries = 3 
/proc/sys/net/ipv4/tcp_syn_retries 

net.ipv4.tcp_synack_retries = 3  
/proc/sys/net/ipv4/tcp_synack_retries 

 
** the bigger value of TCP ORPHAN would prevent simple DoS attack, 
   each ORPHAN cost 64KB memory, so 65535 is about 4GB: 

net.ipv4.tcp_max_orphans = 65536 
/proc/sys/net/ipv4/tcp_max_orphans 

 
** How many pages( 4KB each page in x86) can be used in TCP connection: 

net.ipv4.tcp_mem = 131072 196608 262144 
/proc/sys/net/ipv4/tcp_mem 

Be careful about this one, it'd be triggered OOM if the TCP connection 
consume all pages. 

 
** The maximum send and receive window, you can set 64MB for a 10G NIC: 

net.core.rmem_max = 67108864 
/proc/sys/net/core/rmem_max 

net.core.wmem_max = 67108864 
/proc/sys/net/core/wmem_max 

 
** Each TCP connection's read buffer( X bytes): 
net.ipv4.tcp_rmem = 4096 8192 16777216( 4096 87380 33554432) 
/proc/sys/net/ipv4/tcp_rmem 

net.ipv4.tcp_wmem = 4096 8192 16777216( 4096 65536 33554432) 
/proc/sys/net/ipv4/tcp_wmem 

If default paging 8kb * 2 = 16kb/connection, 4GB memory can be used for: 
(4 * 1024 * 1024) / 16 = 262144 

Oracle DB server's best practice： 
http://www.dba-oracle.com/t_linux_networking_kernel_parameters.htm 
-------------------------------------------------------------- 

 
Networking 
-------------------------------------------------------------  
Ref: 
https://www.suse.com/documentation/sles11/singlehtml/book_hardening/book_hardening.html 

** Source Routing is used to specify a path or route through the 
network from source to destination. This feature can be used by 
network people for diagnosing problems. However, if an intruder was 
able to send a source routed packet into the network, then he could 
intercept the replies and your server might not know that it's not 
communicating with a trusted server. 

 
net.ipv4.conf.all.accept_source_route = 0 
/proc/sys/net/ipv4/conf/all/accept_source_route 

 
** ICMP redirects are used by routers to tell the server that there is 
   a better path to other networks than the one chosen by the 
   server. However, an intruder could potentially use ICMP redirect 
   packets to alter the hosts's routing table by causing traffic to 
   use a path you didn't intend. 

net.ipv4.conf.all.accept_redirects = 0 
/proc/sys/net/ipv4/conf/all/accept_redirects 

 
** Turn it off if this is not a router： 

net.ipv4.conf.all.send_redirects = 0 
net.ipv4.conf.default.send_redirects = 0 

/proc/sys/net/ipv4/conf/all/send_redirects 
/proc/sys/net/ipv4/conf/default/send_redirects 

** IP spoofing protection, the default is disabled( 0)： 

net.ipv4.conf.all.rp_filter = 1 
/proc/sys/net/ipv4/conf/all/rp_filter 

 
** If you want to ignore all ICMP package, you can enable it. The 
   default is disabled( 0): 

net.ipv4.icmp_echo_ignore_all = 1 
/proc/sys/net/ipv4/icmp_echo_ignore_all 

 
** Ignore ICMP broadcast, the default is enabled( 1): 

net.ipv4.icmp_echo_ignore_broadcasts = 1 
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 

 
** To alert you about bad message, the default is disabled( 1): 

net.ipv4.icmp_ignore_bogus_error_responses = 1 
/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 

 
** To turn on logging for Spoofed Packets, Source Routed Packets, and 
   Redirect Packets, the default is disabled( 0): 

/proc/sys/net/ipv4/conf/all/log_martians 
net.ipv4.conf.all.log_martians = 1 

 
** To prevent side channel attack via CVE-2016-5696: TCP exploit: 
   challange ack information leak 

http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=75ff39ccc1bd5d3c455b6822ab09e533c551f758 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=083ae308280d13d187512b9babe3454342a7987e 

The 1st PoC for testing SSH serivce: 
https://github.com/violentshell/rover 

/proc/sys/net/ipv4/tcp_challenge_ack_limit 
net.ipv4.tcp_challenge_ack_limit = 65537 

 
Exploit mitigation 
-------------------------------------------------------------- 
** Randomize the memory area. 0: disable ASLR. 1: Randomize the stack, 
   VDSO page, shared memory regions. 2: (1) + also randomize the data 
   segment. 

kernel.randomize_va_space=2 
/proc/sys/kernel/randomize_va_space 

 
** Not allow the user to read kernel address symbol tables: 

kernel.kptr_restrict=1 
/proc/sys/kernel/kptr_restrict 

 
** the minimal memory map address, 65536 is good at least: 

vm.mmap_min_addr=65536 
/proc/sys/vm/mmap_min_addr 

 
** Now allow the debugger trace the process by ptrace. The current 
   Debian stable kernel doesn't have this feature. 0: All process can 
   be debugged. 1: Only one father process can be debugged. 2: Only 
   *root* can do debug( with CAP_SYS_PTRACE) 3: no process can be 
   debugged 

kernel.yama.ptrace_scope = 2 
/proc/sys/kernel/yama/ptrace_scope 

 
** Disable PERF_EVENT if you don't need it, e.g: profiling 

   *   0 - disallow raw tracepoint access for unpriv 
   *   1 - disallow cpu events for unpriv 
   *   2 - disallow kernel profiling for unpriv 
   *   3 - disallow all unpriv perf event use 

kernel.perf_event_paranoid = 3 
/proc/sys/kernel/perf_event_paranoid 

 
** BPF JIT hardening( v4.7) 
   * 0 - none 
   * 1 - hardened with blinding constants for unpriviledged users 
   * 2 - hardened with blinding for all users 

/proc/sys/net/core/bpf_jit_harden 
-------------------------------------------------------------- 

 
----[ 3.1 Apparmor 

Why Apparmor? It's easy to deploy. More importantly, it's easy to 
audit the polices. Everyone can write your own MAC/RBAC 
policy. Debian/OpenSuSE shipped with Apparmor by default. 

Install Apparmor and MAC polices from community: 
#apt-get install -y apparmor-profiles apparmor 

Check the status: 
#aa-status 

 
----[ 3.2 SELinux 

S0rry. I barely use SELinux for reasons. The 1st one is I don't trust 
NSA, even the source code is GPL'ed. NSA is professional about 
*implant* backdoors, which would be very hard to audit. People has 
been discussing it for years: 

https://www.schneier.com/blog/archives/2008/04/nsas_linux.html 

http://www.zerohedge.com/news/2013-07-09/nsa-has-inserted-its-code-android-os-bugging-three-quarters-all-smartphones 

http://www.eteknix.com/nsa-has-code-running-in-the-linux-kernel-and-android/ 

 
Sebastian Krahmer found a exploitable bug from SELinux recently: 

https://github.com/stealth/troubleshooter 

It looks like a backdoor more than a "vulnerablity", isn't it?;-) 

Another important reason people don't like SELinux because it's hard 
to use and cause other application troubles from time to time. "Stop 
disabling SELinux" movement won't work in the near future: 

http://stopdisablingselinux.com/ 

S0rry, Mr.Walsh. It's nothing personal:-) 

 
----[ 3.3 Mempo kernel 

""⌘ Mempo project aims to provide most secure and yet comfortable 
out-of-the-box Desktop and Server computer, for professionals, 
business, journalists, and every-day users avoiding PRISM-like 
spying. ⌘" 

https://wiki.debian.org/Mempo 

Mempo is a FLOSS project for protect user's digital freedom. Let the 
massive surveillance cry;-) 

The Debian Mempo repo is not working for the internet user now and 
it'll be back soon. So I'll write how to use PaX/Grsecurity from 
offical Mempo repository on Debian. 

 
----[ 3.3.1 PaX/Grsecurity 

PaX/Grsecurity is the cutting-edge kernel protection in past 14 
years. But they don't have the credit what they supposed to 
have. Almost every main stream OS kernel security mechanism has 
influenced by PaX/Grsecurity in past decade. Lionel tells a little 
story about PaX/Grsecurity better than myself: 

http://www.openwall.com/lists/oss-security/2014/12/06/14 

PaX/Grsecurity treat the kernel security as a whole. They've been 
inventing many innovations( SEGMEXEC, PAGEEXEC, MPROTECT, UDEREF, 
RANDSTRUCT*, etc), while hardening the kernel in source code level( 
make important *struct* read-only, etc). PaX/Grsecurity is one of most 
respected 0ld sch00l hacker community. The main contributor( Spender) 
was even been through a very badly economic situation back in 2004: 

http://developers.slashdot.org/story/04/05/31/1949241/end-of-development-for-grsecurity-announced 

Thanks to the G0d of techn0logy, PaX/Grsecurity is still alive.... I 
personally agree with some ideas: 

----------------------------------------------------------------------- 
"The "better than none" point of view is actually a nice way to false 
sense of security for those who don't know better. We got 
better-than-none apparmor, selinux, tomoyo, some poorly maintained and 
crippled ports of grsec features or alikes, namespaces and containers, 
rootkit-friendly LSM, the dumb and useless kernel version of SSP, 
etc. What's the sum of all this shit for end users? False sense of 
security..." 

"without Grsecurity/PaX, linux security is like monkey can never 
perform a regular masturbation cu'z lacking of giant pennis;-)" 
----------------------------------------------------------------------- 

Too many better-than-none product or solutions, which only makes you 
feel safe, maybe for a while. Feel safe is not equal to 
secure. Fuc*ing cargo cult shitty security only makes things worse. 

I'll show you how to install PaX/Grsecurity manually( still waiting 
Mempo back online): 

** Download kernel( Pick one)： 
https://www.kernel.org/pub/linux/kernel/v3.x/ 

** Download PaX/Grsecurity patch( you can download the latest version 
   from )： 

https://grsecurity.net/download.php 

** Decompress the kernel and patch the kernel with grsecurity: 

xz -d linux-*.tar.xz 
tar xvf linux-*.tar 
cd linux-*/ 
patch -p1 < ../grsecurity-*.patch 

 
** Do "make menuconfig" to customize your kernel, or you can use my test config: 

https://raw.githubusercontent.com/citypw/citypw-SCFE/master/security/apparmor_test/debian-7.4-linux-3.14.1-grsec.config 

 
** Compile 
make -j7 deb-pkg 

 
** Install the new kernel 
dpkg -i ../*.deb 
-------------------------------------------------------------- 

 
4. Crypto 

“Encryption works. Properly implemented strong crypto systems are one 
of the few things that you can rely on. Unfortunately, endpoint 
security is so terrifically weak that NSA can frequently find ways 
around it.”   --- Edward Snowden 

Damn, we should treat the crypto engineering very carefully. Because 
it may be the last outter-heaven we have;-) 

----[ 4.1 SSL/TLS Checklist 

Very good writing: 

http://www.exploresecurity.com/wp-content/uploads/custom/SSL_manual_cheatsheet.html 

 
SSL/TLS has been through BEAST/CRIME/LUCKY-13/HEARTBLEED/POODLE in 
past few years. and it's already become one of hottest topic in cyber 
security. There are a set of vulnerable protocols and ciphersuites are 
worth to do audit. There are a few open source tools would make your 
audit work easier. Try this one: 

#apt-get install sslscan 

 
SSLv2 should be disabled: 
-------------------------------------------------------------- 
openssl s_client -ssl2 -connect www.google.com:443 

OpenSSL 1.0 no longer support SSLv2. So you can use GnuTLS do the 
check: 

gnutls-cli -d 5 -p 443 --priority "NORMAL:-VERS-TLS1.2:-VERS-TLS1.1:-VERS-TLS1.0:-VERS-SSL3.0" www.google.com 
-------------------------------------------------------------- 

FREAK: 
-------------------------------------------------------------- 
openssl s_client -cipher EXPORT -connect www.google.com:443 

If succeed, it's risk to FREAK. 
-------------------------------------------------------------- 

----[ 4.2 OpenSSH 

Config file：/etc/ssh/ssh_config 

-------------------------------------------------------------- 
1, known_hosts stores server's signature, so hash the host name: 

HashKnownHosts yes 

2, SSH protocl version 1 is not secure: 

Protocol 2 

3, If you don't use X11 forwarding, plz disable it" 

X11Forwarding no 

4, Disable rhosts: 

IgnoreRhosts yes 

5, Not allow empty password: 

PermitEmptyPasswords no 

6, Maxisum tries: 

MaxAuthTries 5 

7, Now allow root login: 

PermitRootLogin no 
-------------------------------------------------------------- 

(Optional) 
-------------------------------------------------------------- 
1, disable password auth, enable pubkey auth: 

PubkeyAuthentication yes 

PasswordAuthentication no 

 
2，Allow or deny users/groups 

AllowGroups, AllowUsers, DenyUsers, DenyGroups 
-------------------------------------------------------------- 

 
------[ 4.2.1 OpenSSH in post-prism era 

Well, plz read this: 

https://stribika.github.io/2015/01/04/secure-secure-shell.html 

 
----[ 4.2 Ciphersuites in Apache2/Nginx 

The explanation is here: 
https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ 

Apache: 
SSLProtocol ALL -SSLv2 -SSLv3 
SSLHonorCipherOrder On 
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS 

Nginx: 
ssl_prefer_server_ciphers On; 
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS 

 
--[ 5. Web security 

You're not reading this article for learning pentest, are you? Let's 
just consider the fence of defender's;-) 

OWASP code review: 
https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf 
https://www.owasp.org/index.php/OWASP_Code_review_V2_Project 

OWASP testing guide: 
https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf 
https://www.owasp.org/index.php/OWASP_Guide_Project 

 
----[ 5.1 Web server( Apache/Nginx ?) 

* ServerRoot 

Web server's root path. Default is "/etc/httpd". It's import to keep 
track of its permission. Recommend: Do not allow none-root user has 
the permission to modify it. 

chown root:root /etc/httpd 
chmod 754 /etc/httpd 

 
*Timeout 

Lifetime per session. Default is 60 seconds. Set the lower value for 
mitigating DoS attack. Recommend: 15 <= X <= 30 

 
* KeepAlive 

Persistent session. Default is “Off”. Recommend: On 

 
* User 

Decide which user Apache work process running as. Recommend: nobody 

 
* Group 

Decide which group Apache work process running as. Recommend: nobody 

* Blacklist/whitelist IP/networks 

Order Deny,Allow  
Deny from all  
Allow from 176.16.0.0/16  

Or by IP:  

Order Deny,Allow  
Deny from all  
Allow from 127.0.0.1 

 
* Blacklist/whitelist web contents 

It can prevent malicious attack via web content. 

<Directory />  
Order Deny,Allow # Default is Allow 
Deny from all  # Deny all contents 
</Directory>  

 
* Options FollowSymLinks    

Do not list any other files if the visited file don't exit. 

 
* Hide info 

ServerSignature: 
* Off, do not provide any information 
* On, provide Apache infomation 

ServerTokens: 
* Full, exposure all information 
* Prod, only provide server name 

 
* Limit risky HTTP methods 

<Directory /> 
<LimitExcept GET POST> 
Deny from all 
</LimitExcept> 
</Directory> 

PUT/DELETE/etc methods won't be available. 

 
* MinSpareServers 

Minimal spare processes. Default is 5. Recommend: 32. 

 
* MaxSpareServers 

Maximum spare processes. Default is 20. Recommend: 64. 

 
* ServerLimit 

The number that MaxClients can't not exceed. 

 
* MaxClients 

The maximum number of working processes. Default is 256. Recommend: 
8192. 

MaxClients = (RAM available to Apache) / (RAM per Apache process) 

RAM per Apache process: 
#ps -ylC httpd --sort:rss 

Example: 
64GB physical memory * 0.8 = RAM available to Apache 
HTML <= 5MB per process, PHP <= 15MB per processe 
php: MaxClients = 65536MB / 15MB =4369 

 
* MaxRequestsPerChild 

Limit on the number of requests that an individual child server will 
handle during its life. Default is 4000. Recommend: 1500. 

 
----[ 5.2 WAF 

ModSecurity is an open source, cross-platform web application firewall 
(WAF) module. Known as the "Swiss Army Knife" of WAFs, it enables web 
application defenders to gain visibility into HTTP(S) traffic and 
provides a power rules language and API to implement advanced 
protections. The web malicious signatures( including OWASP Top 10) are 
maintained by ModSecurity community. You can deploy it on Debian: 

https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu 

 
Anti-DoS: mod_evasive 

https://www.linode.com/docs/websites/apache-tips-and-tricks/modevasive-on-apache 

About anti DoS solution, I personally don't get used to 
mod_evasive. Iptables would be much easier to maintain, eg: 

iptables -I INPUT -p tcp -m multiport --dports 80,443 -i eth0 -m state --state NEW -m recent --set 
iptables -I INPUT -p tcp -m multiport --dports 80,443 -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 5 -j DROP 

 
--[ 6. Security standard 

Well, there are a bunch of crazy security standards in the 
planet. Some are compliance in some contries. FIPS-140-2/3, CC( EAL 7? 
damn, it'd be an incarnation of the organge book;-)), PCI-DSS are very 
popular terms you might hear from your security consultant. But... due 
to lack of engineering implementation, these crazy( & creepy?) 
security standards are not our concerns here. 

----[ 6.1 STIGs for Debian 

Once there's history, there's story about offense & defense. Once 
we've heard fascinating stories from Mr.Sn0wden about how NSA fuck the 
world, there should be some open information about how BIG-BROTHER do 
the defense. STIGs is one of them. 

I think I'm not the right person to write this section.....plz check 
this out: 

http://hardenedlinux.org/jekyll/update/2015/06/19/STIG-4-Debian.html 

 
--[ 7. Reference 

[1] Back To The Future: Unix Wildcards Gone Wild 
    http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt 

[2] SYNPROXY 
    http://lwn.net/Articles/563151/ 

[3] DDoS protection Using Netfilter/iptables 
    http://people.netfilter.org/hawk/presentations/devconf2014/iptables-ddos-mitigation_JesperBrouer.pdf 

[4] INTERNET PROTOCOL 
    http://tools.ietf.org/html/rfc791 

[5] A simple TCP spoofing attack 
    http://www.citi.umich.edu/u/provos/papers/secnet-spoof.txt 

[6] ICMP Attacks Illustrated 
    http://www.sans.org/reading-room/whitepapers/threats/icmp-attacks-illustrated-477 

[7] SUSE Linux Enterprise Server 11 SP3 - Security and Hardening 
    https://www.suse.com/documentation/sles11/singlehtml/book_hardening/book_hardening.html 

[8] Securing Debian Manual  
    https://www.debian.org/doc/manuals/securing-debian-howto/ 

[9] A Brief Introduction to auditd 
    http://security.blogoverflow.com/2013/01/a-brief-introduction-to-auditd/ 

[10] Apparmor RBAC 
     http://wiki.apparmor.net/index.php/Pam_apparmor_example 

[11] Hardening PHP from php.ini 
     http://www.madirish.net/199 

[12] CVE-2014-0196 exploit 
     http://bugfuzz.com/stuff/cve-2014-0196-md.c 

[13] Secure Secure Shell 
     https://stribika.github.io/2015/01/04/secure-secure-shell.html 

[14] STIGs 
     http://iase.disa.mil/stigs/Pages/index.aspx 
     http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx 

begin-base64 644 test.tar.bz2 
QlpoOTFBWSZTWbxpxYUAEo7///n/2ez+f//3///f+f////7bhgAkAfANIAgx 
wjUxUAwJ4A8Ps2+zrXdBsDAKKNACgAaAAAAAACgAMkCmmTUxTzU01ANPUeoa 
aaepp6nqGnoj9UabUHqNqAA0BoANAAAA0A9IPSA0IGmiaR6lPIj1T1PUPU9Q 
aAZPU0ZNAaAAAA0aGIAANAYjQAAyNCDAEYJiNMmEZDEMIwmAEYRkMmmQ0ZGI 
NDATEwJiNGAjJkwIMARgmI0yYRkMQwjCYARhGQyaZDRkYg0MBMTAmI0YCMmT 
ANIqNAZAGjI0AGmjIYQ00AaAAyGQyDTQAyaGIaNAABo0bU0CRIIBNACGhGSZ 
GRpkp7VPJpPU9pRobSep5QaAB6gAeoDIAAA9QDyJmpfaeuxqs13S55CljJ5e 
QvAgOC8AwCcgIchImoQBjoDLYIp/DkjawQLizhzzcgK8xzS+P4ottfRF9+y/ 
kYYyYNrM4zJ8EiYCwNYBd3uADThanC4d3bxbj18vYY3cMgtpy3jF7CSiEoKM 
wEQsZ7aKPObLeaUMAEBJkIh1yAG7m4Vd9rWpXAVRWE6NZbHCKkolgA1JXKUp 
AxlBSi20l/y0liy5omSsulMbHQiVxdOJlJUkeYG3MVWYgQIlYrzygMSk5whC 
6vH7kr6iNkun3NC7Ikeq/pwNN7p7/WL/rLxp6x/Kwtv8YLlnQX1RXlWV6uFb 
WMVHVyHKmxte7/MX25TUyoYHLs4x5Mgh6SHCw53mbebSBj5kvIgRFBjy66oo 
OPahkLRPJBv1o9OyNzuAvQztMJyT2DvJg4qPtmx9j5DM3aNtmJqCh5jPgc7A 
qhQbnoFiiuitW40ehF2xiPbOKK1l28zN33NipUsu3mXMmx4vHJ/FbgWbT0TP 
xEixkI+nkcfus/IyFNdh9rHBJTAHAf/QDPDM7DO8IPQQtU9kZjM/EtggXthj 
UELmrFwXQEaAPEjHIaDMIxQEE/vxfN40WNBwLkiW5IRR0lANw8ShB7A0Fot0 
323MRglv2yZrF9+7wsD2/56TdV+5IaQ0Uwt9goJsimK26MYsqr6lu2S3G7CV 
EWOgwYhw20T5uXHsX+QixpS8UCWyJkgaa+mwgTPpIrL6k1bJHdkiEf71IkXd 
z1bKsBjD0XNkhgyw/FJC+nM3GiZ8vhLCvzJHbVG5OeUpf6QgqczEoFUfj85F 
iu+RSWvHXDmJH/A0ejbPOxxaZCXedpOY66BYk1QJWm0vdw2h8I6paefmy5Yl 
CckKOE5OMKr907Sq4V+r5ySXU1NF4RPPXvWI8dOW0tbnzdYbfWSqBNmT9GNg 
eEh5iVIxWdHbhVsgTVMzWKS2gGhbqYdJaYmhvB+cmNc4rGp4lDOt8rKvSnzm 
oDINkTygkRYGlMM9cNkiRMJ5+odiRC5TyZU32jNSQmRydyxaELNneHhb5ngB 
70EQMUJcRVXSwMOrrKNOwmMaxMB1MQ2vhOQgpauSAuDvGl3K2WMq1wMLWiBo 
JKyaqkAqwDTpMOe7MQJTIQllFWOuAQnxeA5E3OeNFRR68qSrgV1ZEWHl7pq5 
56G333QXyV7JIT8v5qQ2NA2xv7U5SGMhkNA2JOTgoEQBBETZIaXxlZyBBNJi 
IEj4nw575I47nlyjL2f0DyyGFpAWdXijiO7vHkPagPW9ztJJYgJG1pCPD3w2 
hIPOyyySJHhGuOdiL1PwCZ30jsJSSBh4BWnuzBIkjlQEiQkt6doJiFEkUSPY 
JyQmDSJC11DEJ0ytZjzD9A0V88XMYzSgGFyknAvN7DbQ2JRMGUSZfMUwQpB4 
hrBQhPMzMzOphwXacoBCLMm8n2rk017bL+NxtQXHoyHaBdHrU5v0ivn9fFfQ 
nCGBykEkNDAfDxy0uaNDBtA9vov7HjBUAxgIAxxifI0fMYza8zBg02mzR6Xy 
Ui7ANM1kDmY3HWS0SKMkBrJ5L8BjuxXqhVEyYmchDDTasIyIWMiGNPqoVCmZ 
M4agMa7ifA7+m8AIAEyx33JyrrK1nOmcn/2URqpgBjAfUuFdrnXIUsMmm8oY 
X43G1QG4rfbPpyskLK+zVoWIFlK3ninca2plrLVYaS7w6Mj2sTABL1/Idvk8 
3i9SJ4oKFSD+6qgSCJRhJEYHnGmWChZjCsWE0kn18TFOoJInCR8qQw94MF+E 
XCGHqqcGjUiwy2loj3G2JjoDR7nsS9w+Y0HttlQzRpSLjjhcKRrwT1kqtpg3 
rBqS7BWWZ0G6CDy3fYVjSMhg7trVt4w+h8aSJH2ffBRuqJKA4wbjkhC5SDpX 
VvNnMDoOgia61rR1t8SwQaQajT+6SwBzP7ma2Q0wGHEmLXKBiS6IgGZiDnOc 
QslYRQLUIvth7AxhyB7CszltSIEhSN5v+2INulIGMbQURUGb0y5veS1CFpmG 
aqj4K7OTihEt4ngtwa1cBe0irVQNrT3qrkgFmAdLQEA4UNZ2LQqYsJHy/Z/6 
uSRtMyBAa0WC+4edmAzyZ5Rkw04pE4EIArs396SRYFUDiBQqAYAYdcMFKEHc 
GHrnnIFrraWlp5galkGHwDqTVF9U0GAplSRIJLWGIZFTJgx/CXqTJUX0gLj4 
aZ1Jo6mMPeCiJfPfM3Bh5jThKpa5H4aR7eD46FYErV8C9vWgJG2w37rLXVGR 
I0hOhSYzIOJ77CSgwHiHd+5tLdFpvWIpHt39Vgg3D3Lc7dkDIxeIugReCmJa 
2zKPq7gsMX9HoqyOefWkDJWEcBcIUhs5EkSFjz4k1PvYcKtsax9ZiNyL4Y4W 
BuBVn/nNaf6PTobCIIYFRoX5JbgwDaQBfAkrNXdHudWxlEbkCV9xcqmxBAgn 
KDdKNdYoMG25xA2REBbSQcqBtHYyDAjddJXJXRgYkXATWp2CU16ly+ir9BCd 
pmLXUJ2510Ex9ceA1hqETM5BJVmPoXPMDqTpD6icWEzaDkVi7sghEQSYMCQb 
/hAT6ChQWgXZXEqNSgDMhSmBGhBAvHCgi0ewZv6DC3KglIZJYeraSxpDq5E3 
4dMxLtC+YVETSLF+DTNDbQpl/M9jLNk0WvKe1hdhtMS5jEWsxzB0BaYeRo3Q 
FzT93V+MMFuJqh3N+O2TB7B4MblSmyXROClmvM1KjJE7MAmS0BeCS2vvjXk3 
42hYItCqvmXBiKA5O6cGjJT6HtSvDzAzwrrIOw7EouYJYdIjSvQu0FVksrog 
Ly5IwSJrQMTaLJVJLvOrIoaHaDG0NiTBJsxtqYKRpSY6aFzK0+3uytHFwaZV 
okMmriuV0Fp0RBlChoO0cJI3s9x6plisUzlHaVSCZxGuLGc/clYBUOIWFvXA 
HSmDtgtXQGC4NaohEwyBLI9EwcKBeaEuwkWESC6wI6ruFsdFxz92wnYadk7r 
sMZTmtOSTdvtzBLme33SvFJ8U45iSQLu4iTsqbFZ56q/UaUjmaRvaLXVpmqv 
IYcUjWqmIJFKs68Yk2w5BnT2X3mQ4aoJZgw2jRzgdtGjSsd8pDfPDnJC7YFN 
uTGMbTBrYkMw6TA6zfcQGTCGBOzaKmtIgA64CrNArWs2hHpsyoVXYFwJbCeG 
pQ7EGGWIiENaMerM57ZItMkK1pNMRB1FNj5aFyOg5VlIVSiMcNJnROltqGY5 
xYUDp0ixL7ioJdJZM3GmEr+mmW0FyYX6XqwLAkHdQYBCbDxtvYWxMbTGENxu 
ZUdZyonMJgzFLxyKK2dLjXXFTPu0MkpGFjIZCGTuBq67FJezPsDW2x7un3tm 
Va6HhKG2WuG23DhtttttttttwqzYwMkdKYJYJA2LMazwwoibigRYcAYrAqlN 
FGkxiiwsYiJulEE0VnHDsVObrJhbzZV7wdfisJXHFK9T6M1c0yYeAaSXeNsT 
DHv3oO4a5rwuUhpbkYjbbDa1m50TAD3eqwvmFUlMiiCwkpBSVdwLEXhaDvVI 
22iyB8VPATSpG8qLjbvclY7stmwWvmLUeRlWcAye/VuxFrBgp4ElEow4bxVi 
yQIqkTExVRE8AiRCmSJEAdAxGZoSm7wu5doLhSfGIBhZPwYzvNzNQsdBekeW 
wO5XIllg4uBS1M2IXhOZKSQLWdtbLWZgy4BvawgaYsiFvDqNJUJsViUNjMYA 
k+e8mJah1JKQh8Ejadz0p0MtBAFgb6RpvLDrAYSJTzzBzSVQmqoNHbsJ6sli 
iWIa0+bFZI0CmvE5yzaUpVYHNzA3qbeEceELg6C32yY0DJEQ2Jk0XDXXKE5z 
vmbyj53kWTld13pXVJy0WKdHBZFawZvWOgWxkc+7QkaL63J8de+2z0oMnMMy 
6VjDpKW6Ca3o+0H9lSlFcy+ZCOhGZBqgUD255BqRKdzC8LEGlBbcpULiFhUw 
FIYzYNucOD77bnc8EjIwJB2JT0oYKBkHkHYjQWwsrkDkGJiyitUFIKqnQwTM 
xgMjmCSuSEmFpDMTBK8D4WHOKtQ7zEDhX60g0oDYCJmYjBNA1qIsbuhrRRjG 
at58fteTlcrcXjKRmhDZczN4Y8Ex5rnDCWwMA3t7oCLHIE5Uukg58ErrYNv6 
+BgXUvqaQmIZg22gk3BJuUKDEUB6BzhVZiuosjENQEG3r7xttLY+IuVDhI8R 
pEXJau/VU8MHq+nGp+kmlwPNoRM1GvdZ84Mr0JQuho9pnqbL9D+8LQBMagwM 
Vb0BNIk9zC7o9eVi4O86BaRUXlKYHbHIF1Wh1z7dSRUC9obYBZwUoGWmJ0F5 
6TETEqQg7RzZaWXo9kQbe53RBCEe+0HzsBI//F3JFOFCQvGnFhQ= 
====