SecureSlash.com

In some situations a program could terminate without even showing an error message. In such cases, the best tool to use and check the problem is

strace

If you dont have it pre-installed, then install it by yum, or using rpms

Yum Command to install strace
yum install strace

This command will install in most redhat based distros.

Install strace using RPM
wget ftp://rpmfind.net/linux/fedora/core/development/i386/os/Fedora/strace-4.5.15-1.fc7.i386.rpm

How to use strace command?

strace [command that crashes here]

For getting help,

# strace --help

usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] … [-o file]
[-p pid] … [-s strsize] [-u username] [-E var=val] …
[command [arg ...]]
or: strace -c [-e expr] … [-O overhead] [-S sortby] [-E var=val] …
[command [arg ...]]
-c — count time, calls, and errors for each syscall and report summary
-f — follow forks, -ff — with output into separate files
-F — attempt to follow vforks, -h — print help message
-i — print instruction pointer at time of syscall
-q — suppress messages about attaching, detaching, etc.
-r — print relative timestamp, -t — absolute timestamp, -tt — with usecs
-T — print time spent in each syscall, -V — print version
-v — verbose mode: print unabbreviated argv, stat, termio[s], etc. args
-x — print non-ascii strings in hex, -xx — print all strings in hex
-a column — alignment COLUMN for printing syscall results (default 40)
-e expr — a qualifying expression: option=[!]all or
option=[!]val1[,val2]…
options: trace, abbrev, verbose, raw, signal, read, or write
-o file — send trace output to FILE instead of stderr
-O overhead — set overhead for tracing syscalls to OVERHEAD usecs
-p pid — trace process with process id PID, may be repeated
-s strsize — limit length of print strings to STRSIZE chars (default 32)
-S sortby — sort syscall counts by: time, calls, name, nothing (default
time)
-u username — run command as username handling setuid and/or setgid
-E var=val — put var=val in the environment for command
-E var — remove var from the environment for command

In rare cases , the command may be a script , And it might internally call other command or program and then it could get mixed up somewhere. So, Simple strace might not help much in this situation.

In those cases

strace -f [command]
will help

It will follow the forks and show detailed strace output for even the internal calls,etc.

you can suppress some unwanted info (for sys admins) like attaching & detaching by using,

strace -q -f [command]

Advanced programmers might look for this as well.

Go through man pages of strace and know more options.
man strace

Port access related problems will occur, During the fresh installation or reinstallation of programs such as Apache/MySQL. When you are starting a service in linux/unix and it says Address already in use or similar error..

It is common in Apache and solution is,

Case 1: You dont know which service is blocking that port
in this case.

fuser -k [portnumber]/[protocol]

Examples:

fuser -k 80/tcp
fuser -k 443/tcp
fuser -k 576/udp

fuser man page

Case 2: You know the name of program.

killall -9 programname

Examples

killall -9 httpd

killall -9 exim

once done.. restart the service now and remember this to handle port
blocks with “Ease in breadth”.

Make Sure To Read All Of This Post Before Doing Anything, If You Don’t Understand It ALL, Do Not Continue

Install NTFS Support
yum -y install fuse fuse-libs ntfs-3g ntfsprogs ntfsprogs-gnomevfs

Check Your Partitions
Use fdisk to list partitions. Most ATA hard drives will be /dev/hda. Drives may also show up as /dev/hdb or /dev/sda depending on your configuration.
fdisk -l
(find all NTFS labels, using the partitions you want below)

Create Mount Points
For every partition in step 2 that you wish to access, you will need a “mount point”. A mount point is just a directory. Common directories are: /media/ and /mnt/. Use whichever, but be consistent.
cd /media/
mkdir c d e
(no spaces for the mount name, put a space between each “folder” you want to make)

Mount Partitions(first time)
Using NTFS-3G, we mount the NTFS partition using read-write.
mount /dev/hda1 /media/c -t ntfs-3g -rw -o umask=0000,force
mount /dev/hda2 /media/d -t ntfs-3g -rw -o umask=0000,force
mount /dev/hda3 /media/e -t ntfs-3g -rw -o umask=0000,force
(remember to only mount NTFS partitions this way, never leave out “force” else fedora may cause partition errors)

Install gedit Editor(including the stars)
yum -y install *gedit*

Fedora Boot Mounting
gedit /etc/fstab

Add mount lines to the END of the file you just opened in gedit
/dev/hda1 /media/c ntfs-3g rw,defaults,umask=0000,force 0 0
/dev/hda2 /media/d ntfs-3g rw,defaults,umask=0000,force 0 0
/dev/hda3 /media/e ntfs-3g rw,defaults,umask=0000,force 0 0

Hints:
hda# should be changed to your drive numbers, delete the extra commands…
c,d,e should be changed to whatever you want JUST NO SPACES IN THE NAMES

Deviating from this tutorial might damage your ntfs, this is proven to work over 9 months

Installing Apache binary
There are no special steps needed to build the Apache binary in order to install it in a chroot jail. The following steps apply equally to a precompiled binary (such as an RPM) or one you have compiled yourself. Starting with a working binary helps with debugging later, if necessary. Just make sure that you are using the latest patched version of the server, install Apache normally, and ensure that it is working as expected.

Finally, make sure you configure Apache to run with its own user and group IDs. Create a user and group with the commands:

# groupadd apache
# useradd -c “Apache Server” -d /dev/null -g apache -s /bin/false apache
These commands create the regular user apache and the apache group. Apache runs as nobody by default. User nobody may be used by many processes, and if it is compromised an intruder will gain access to all processes on your system running under that UID.
Creating the chroot tree
Our chroot jail is a mini-version of the Linux filesystem. I prefer to use a seperate partition mounted as /chroot, with Apache under a directory named httpd on my chroot partition.

 

# mkdir /chroot/httpd

# mkdir /chroot/httpd/dev

# mkdir /chroot/httpd/lib

# mkdir /chroot/httpd/etc

# mkdir -p /chroot/httpd/usr/sbin

# mkdir /chroot/httpd/usr/lib

# mkdir /chroot/httpd/usr/libexec

# mkdir -p /chroot/httpd/var/run

# mkdir -p /chroot/httpd/var/log/apache

# mkdir -p /chroot/httpd/home/httpd

Now set the permissions on your directory structure:

 

# chown -R root /chroot/httpd

# chmod -R 0755 /chroot/httpd

# chmod 750 /chroot/httpd/var/log/apache/

Your exact structure may vary slightly depending upon what features of Apache you are using and where the nescessary libraries live on your main file system.
Once you have created the nescessary directories you need to create the null device.

 

# mknod  /chroot/httpd/dev/null c 1 3

# chown root.sys /chroot/httpd/dev/null

# chmod 666 /chroot/httpd/dev/null

You need the null device and /chroot/httpd/var/log/httpd/ because, when run in chroot jail, Apache sees the /chroot/httpd directory as the equivalent of /. This means that it cannot access /dev/null or /var/log on the normal filesystem.
Copying the nescessary files
Now shut down Apache, run killall httpd, and you’re ready to start copying across the necessary files. Note that some directory names may be different in your case depending upon how you originally installed Apache. First, copy your configuration files:
# cp -r /etc/apache /chroot/httpd/etc/
Next, copy your Apache DocumentRoot and CGI scripts:
# cp -r /home/httpd/html /chroot/httpd/home/httpd/
# cp -r /home/httpd/cgi-bin /chroot/httpd/home/httpd/
Now copy your httpd binary (and, if you use them, the Apache scripts) from /usr/sbin:
# cp /usr/sbin/httpd /chroot/usr/sbin/
# cp /usr/sbin/apache* /chroot/usr/sbin/
If you use mod_ssl you need to copy the /etc/ssl directory and its contents too:
# cp -a /etc/ssl /chroot/httpd/etc/
You should also copy any modules from your original install:
cp -r /usr/libexec/apache /chroot/httpd/usr/libexec/
Once you have copied Apache itself (and ssl if needed) you need to copy all of the shared libraries Apache relies on to run. To find out which libraries you need, execute # ldd /chroot/httpd/usr/sbin/httpd. This should give output something like:

 

/lib/libsafe.so.2 => /lib/libsafe.so.2 (0x40017000)

libm.so.6 => /lib/libm.so.6 (0x40037000)

libcrypt.so.1 => /lib/libcrypt.so.1 (0x40059000)

libdb.so.2 => /lib/libdb.so.2 (0x40086000)

libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40096000)

libdl.so.2 => /lib/libdl.so.2 (0x400b6000)

libc.so.6 => /lib/libc.so.6 (0x400b9000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

The exact output will depend upon how your httpd binary was built in the first place. Copy the required files to their respective directories in your chroot:

 

# cp /lib/libsafe* /chroot/httpd/lib/

# cp /lib/libm* /chroot/httpd/lib/

# cp /lib/libcrypt* /chroot/httpd/lib/

# cp /lib/libdb* /chroot/httpd/lib/

# cp /usr/lib/libexpat* /chroot/httpd/usr/lib/

# cp /lib/libdl* /chroot/httpd/lib/

# cp /lib/libc* /chroot/httpd/lib/

# cp /lib/ld-* /chroot/httpd/lib/

You need certain libraries for some standard networking functionality:

 

# cp /lib/libnss_compat* /chroot/httpd/lib/

# cp /lib/libnss_dns* /chroot/httpd/lib/

# cp /lib/libnss_files* /chroot/httpd/lib/

# cp /lib/libnsl* /chroot/httpd/lib/

The /chroot/httpd/etc configuration files
For Apache to function properly you also need several configuration files from /etc. First, edit the /etc/passwd and /etc/group files. These should contain only entries for the Apache user and group you created earlier. For example:

 

/etc/passwd:

apache:x:12347:12348:Apache Server:/dev/null:/bin/false

/etc/group:

apache:x:12347:

You also need several network configuration files:

 

# cp /etc/hosts /chroot/httpd/etc/

# cp /etc/host.conf /chroot/httpd/etc/

# cp /etc/resolv.conf /chroot/httpd/etc/

# cp /etc/nsswitch.conf /chroot/httpd/etc/

For extra security you can set the immutable bit on these configuration files. When the immutable bit is set, root has to specifically unset it before a file can be modified, making it much harder for an intruder to tamper with the files:

 

# chattr +i /chroot/httpd/etc/hosts

# chattr +i /chroot/httpd/etc/host.conf

# chattr +i /chroot/httpd/etc/resolv.conf

# chattr +i /chroot/httpd/etc/nsswitch.conf

# chattr +i /chroot/httpd/etc/passwd

# chattr +i /chroot/httpd/etc/group

In order that the log files be written with the correct time, you need to check /etc/localtime. localtime is a symlink to a file in /usr/share/zoneinfo. To find out which file, run ls -l /etc/localtime and copy the appropriate file to /chroot/httpd/etc/localtime.
By default, syslogd monitors log files only in /var/log. The chrooted httpd daemon will write its logs to /chroot/httpd/var/log, however, so you need to tell syslogd to monitor this directory too. To change this you need to edit the appropriate startup script, /etc/rc.d/rc.syslog or /etc/rc.d/init.d/syslog, depending upon your distro.
For /etc/rc.d/rc.syslog change daemon syslogd -m 0 to daemon syslogd -m 0 -a /chroot/httpd/dev/log.
For /etc/rc.d/rc.syslog change:

 

    echo -n " /usr/sbin/syslogd"

    /usr/sbin/syslogd

to:

 

    echo -n " /usr/sbin/syslogd"

    /usr/sbin/syslogd -m 0 -a /chroot/httpd/dev/log

It is a good idea to create the nescessary log files and set the appendable bit on them too.

 

# touch /chroot/httpd/var/log/apache/access_log

# touch /chroot/httpd/var/log/apache/error_log

# chmod 600 /chroot/httpd/var/log/apache/*

# chattr +a /chroot/httpd/var/log/apache/*

Finally, you need to change the httpd startup script to run the chrooted httpd. Depending on your distro, open up /etc/rc.d/rc.httpd or /etc/rc.d/init.d/httpd and change the command that starts the httpd daemon to read /usr/sbin/chroot /chroot/httpd/ /usr/sbin/httpd.
Testing the server
If you have not already done so you should shut down the httpd daemon now. Next, restart the syslog daemon: /etc/rc.d/rc.syslog restart (or /etc/rc.d/init.d/syslog restart accordingly). Now start the chrooted version of Apache with /etc/rc.d/rc.httpd start (or /etc/rc.d/init.d/httpd start).
If there are no errors, check the daemon is running with the command ps -aux | grep httpd. You should see several entries indicating a running httpd process. Taking the process number from the output of ps and running ls -l /proc/PROC_NUMBER/root/ should show the structure of your /chroot/httpd rather than your server’s / filesystem.
If something has gone wrong, you should try running your chrooted httpd with strace. The command # strace chroot /chroot/httpd /usr/sbin/httpd 2> httpd.strace redirects the output of strace to a file named httpd.strace which should give you an idea where the problem lies.
Once everything is running you can remove your original Apache install.
Summary

Although chroot can be used to help create a more secure environment, it is not perfect. You still need to keep your Web server patched up to date and monitor your logs. Your chroot environment should help to contain a potential breakin and protect your system’s main filesystem from unseen vulnerabilities in your Web server.

Fedora is the thought and action leader in many cutting-edge Linux security
initiatives. The following security features were developed by Fedora engineers.
In line with the Fedora policy, these security features have been pushed
upstream and they are available to all Linux distributions who choose
to take advantage of them.

SELinux

Fedora is the first mainstream operating system to provide MAC (Mandatory Access Control) based security using SELinux enabled by default. SELinux was developed in partnership with the NSA (National Security Agency) – A US based goverment security organisation and Red Hat with developers from projects such as Gentoo and Debian. Security Enhanced Linux protects users and processes by watching all actions on the system, from opening a file to using a socket. Users may write their own SELinux security policies according to their risk tolerance. By default, Fedora runs a targeted security policy that protects network daemons that have a higher chance of being attacked. If compromised, these programs are extremely limited in the damage they can do, even if the root account is cracked.

For example, Apache is protected in four different ways. The executable for Apache, httpd, is protected at compile time by PIE and Exec-Shield. The executable binary file on the system is protected by ELF hardening. Finally, SELinux policies are in place so that if httpd is cracked, it can only append to the Apache logs and mangle content in specific directories; it cannot roam around home directories or otherwise interact with the rest of the system.

References:

http://fedoraproject.org/wiki/SELinux

Exec-Shield

No eXecute (NX)

Modern processors support a feature called NX which allows a system to control the execution of various portions of memory. Data memory is flagged as non-executable and program memory is flagged as non-writeable. This help prevent certain types of buffer overflow exploits from working as expected.

Since not all processors support the NX feature, attemptes have been made to support this feature via segment limits. A segment limit will prevent certain portions of memory from being executed. This provides very similar functionality to NX technology.

Position Independent Executables (PIE)

PIE is an Exec-Shield technology that allows a programmer to make the executable load at a different memory address each time it starts. Attackers cannot predict where the application will start, making it very hard to exploit. Not all packages are compiled as PIE executables in Fedora Core. Using PIE causes a fair amount of processing overhead, so only select packages are compiled as PIE executables.

Applications that are not compiled as PIE, still have a small amount of added protection. The usage of prelink does place binaries and libraries at known locations. Fedora Core contains a feature which runs prelink every two weeks at which time the memory locations of binaries and libraries is randomized. Applications that are compiled as PIE do not use prelink, all memory addresses are randomized with each execution.

Compile Time Buffer Checks (FORTIFY_SOURCE)

GCC compiler and GLIBC C library from Fedora Core 4 onwards has gained a feature called “FORTIFY_SOURCE” that will detect and prevent a subset of the buffer overflows before they can do damage. The idea behind FORTIFY_SOURCE is relatively simple: there are cases where the compiler can know the size of a buffer (if it’s a fixed sized buffer on the stack, as in the example, or if the buffer just came from a malloc() function call). With a known buffer size, functions that operate on the buffer can make sure the buffer will not overflow.

References:

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

ELF (Executable and Linkable Format) Data Hardening

These are changes to the file components that protect the structure of the file itself.

References:

http://people.redhat.com/drepper/nonselsec.pdf

Restricted Kernel Memory access

Fedora restricts how the kernel memory (/dev/mem) can be overwritten. This prevents several rootkits from functioning resulting in a safer and more secure system.

References:

http://lwn.net/Articles/160380/

Stack Smash Protection, Buffer Overflow Detection and Variable Reordering

For this release, all of the software in the Fedora Core and Fedora Extras software repositories is compiled using a security feature called fstack-protector. fstack-protector puts a canary value on the stack of key functions. Just before the return address and just before returning from that value, that canary value is verified. If there was a buffer overflow, the canary no longer matches and the program aborts. The canary value is random for each time the application is started and makes it impossible to guess remotely. This is a security feature that has been backported from GCC 4.1 to the version of the GCC compiler used in Fedora Core 5 test1. This feature

[http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01193.html) has been written by Red Hat developers and provides similar functionality to the IBM propolice/ssp patches.

This is in addition to using FORTIFY_SOURCE from Fedora Core 4 onwards.

References:

http://gcc.gnu.org/gcc-4.1/changes.html

Sysinternals : An extensive collection of powerful windows utilities

Sysinternals provides many small windows utilities that are quite useful for low-level windows hacking. Some are free of cost and/or include source code, while others are proprietary. Survey respondents were most enamored with:

• ProcessExplorer for keeping an eye on the files and directories open by any process (like LSoF on UNIX).
• PsTools for managing (executing, suspending, killing, detailing) local and remote processes.
• Autoruns for discovering what executables are set to run during system boot up or login.
• RootkitRevealer for detecting registry and file system API discrepancies that may indicate the presence of a user-mode or kernel-mode rootkit.
• TCPView, for viewing TCP and UDP traffic endpoints used by each process (like Netstat on UNIX).

Update: Microsoft acquired Sysinternals in July 2006, promising that “Customers will be able to continue building on Sysinternals’ advanced utilities, technical information and source code”. Less than four months later, Microsoft removed most of that source code. Future product direction is uncertain.

Tripwire : The grand-daddy of file integrity checkers
A file and directory integrity checker. Tripwire is a tool that aids system administrators and users in monitoring a designated set of files for any changes. Used with system files on a regular (e.g., daily) basis, Tripwire can notify system administrators of corrupted or tampered files, so damage control measures can be taken in a timely manner. An open source Linux version is freely available at Tripwire.Org. UNIX users may also want to consider AIDE, which has been designed to be a free Tripwire replacement. Or you may wish to investigate Radmind, RKHunter, or chkrootkit. Windows users may like RootkitRevealer from Sysinternals.

RKHunter : An Unix Rootkit Detector
RKHunter is scanning tool that checks for signs of various pieces of nasty software on your system like rootkits, backdoors and local exploits. It runs many tests, including MD5 hash comparisons, default filenames used by rootkits, wrong file permissions for binaries, and suspicious strings in LKM and KLD modules.

chkrootkit : Locally checks for signs of a rootkit
chkrootkit is a flexible, portable tool that can check for many signs of rootkit intrusion on Unix-based systems. Its features include detecting binary modification, utmp/wtmp/lastlog modifications, promiscuous interfaces, and malicious kernel modules.

P0f : A versatile passive OS fingerprinting tool

P0f is able to identify the operating system of a target host simply by examining captured packets even when the device in question is behind an overzealous packet firewall. P0f does not generate ANY additional network traffic, direct or indirect. No name lookups, no mysterious probes, no ARIN queries, nothing. In the hands of advanced users, P0f can detect firewall presence, NAT use, existence of load balancers, and more!

Xprobe2 : Active OS fingerprinting tool
XProbe is a tool for determining the operating system of a remote host. They do this using some of the same techniques as Nmap as well as some of their own ideas. Xprobe has always emphasized the ICMP protocol in its fingerprinting approach.