We are a group of free software enthusiasts, anarchists, cyber security researchers. Long live anarchy! Long live 0ld sch00l!!! A small step in security hardening --> A giant leap in Free & Open source software!!!

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.

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.

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

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;-)

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

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

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.

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.

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

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 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:

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:

** 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:

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:

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

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

** 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

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:

Sebastian Krahmer found a exploitable bug from SELinux recently. 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:

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:

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

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):

** Do “make menuconfig” to customize your kernel, or you can use my test 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;-)

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:

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.

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.

–[ 7. Reference

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