I know that bash environment guides and tutorials are a dime a dozen, but I decided to make a to-the-point post about a few tips most of you newer guys should learn from the start, and throw in a few tricks some of you novice guys might not know yet. I'll try to keep this as brief as possible, but it's going to be fairly lengthy.
First of all, if you're operating a terminal as a regular user you might be jealous because root gets fancy colour coded output. This one's a quick and easy fix. All you have to do is edit your
PS1 (system prompt) env variable:
export PS1=`echo -ne "\033[0;34m\u@\h:\033[0;36m\w\033[0;34m\$\033[0;37m "`
I wrapped the escape sequences in bold (\u -- username, \w -- working directory), the rest are ANSI escape sequences interpreted as colour codes. For the sake of brevity I'm not going to explain everything here, but here's a guide to the various colour codes here:
http://www.linuxgazette.com/issue65/padala.html. Mess around with it to get the colour scheme you want.
Many people know that the
PATH env variable stores the various directories to be scanned for scripts/executables to be executed, and
MANPATH for man files, etc. Many people, however, overlook the
CDPATH env variable. Try:
export CDPATH=.:~
Now whenever you do a
cd <directory> it'll automatically search your home directory, so you don't have to prefix with
~/. Fool around with this a bit. You can add as many directories as you want, just delimit them with
:. Note that as
root you should be weary of editing your
PATH env variable. If you add a directory writable to other users, they can add binaries that will be mistaken by you as typical programs and executed inadvertently as root.
We all know that
~/.bash_history stores everything interpreted by your bash shell. So you need to be careful if you're ever using shells to log into other services. If you enter some sensitive data (password) accidentally on the command line without realizing it before carriage returning it's possible the evil admin (or perhaps some other user!) will stumble upon your precious password when checking out your
.bash_history, you'll probably want to erase it. Well,
.bash_history is written everytime you log out, so doing
rm .bash_history now isn't going to work. What you can do is this:
export HISTSIZE=0
This will completely clear your
.bash_history file, and will write an empty file when you log out. Note: You could have logged out, logged back in, and
rm .bash_history, but this trick is more convenient and the other way still leaves an
rm command in your
.bash_history and you might not want your admin to know you're deleting logs.
A system admin will typically use the
w command (or some alternate method) in order to see who is logged into the server. Sometimes people will remotely login, execute a few commands, then just forget about their terminal, leaving it idle. Or perhaps they're using the system to run their irc client. If the person has gone out for the day and their client has terminated for whatever reason their connection will also idle. If you, as the admin, don't like hosting all of these idle users try this:
export TMOUT=600
This will make it so that bash automatically logs out any user who hasn't produced input for 10 minutes. Adjust the time (in seconds) as necessary.
Let's say you're logged into an X session and you want to run a binary with
root priviliges that outputs to a GUI. Let's also say it's unsafe to
suid the program, and you don't want to add support for
sudo on the system for security reasons. Try this series of commands:
sh-3.00$ set | grep DISPLAY
DISPLAY=:0.0
sh-3.00$ xhost +
access control disabled, clients can connect from any host
sh-3.00$ su -
Password:
root@tmp:~# export DISPLAY=:0.0
root@tmp:~# ethereal
Anything that uses
xlib to draw to an X session that is executed as
root on that command line will be drawn to display :0.0. Note that there are security issues inherent in this as well.
xhost is used to control the ACLs that filter access to your X server. If you disable them, anyone able to connect to your X server will be able to output to your display. You may want to research how to limit acess to your X server via
xhost.
Typically
ps aux is more practical than regular old
ps. Or maybe
ls -a is preferred to
ls. Getting tired of typing
ps aux every time ? Set an alias:
sh-3.00$ cat << EOF > ~/.bashrc
> alias ps='ps aux'
> EOF
sh-3.00$ bash -ic ps | grep xterm
tmp 2659 0.0 0.8 5736 2304 tty1 S Jul15 0:00 xterm -title Terminal
tmp 3909 0.0 1.3 5972 3464 tty1 S 02:22 0:00 xterm -title Terminal
tmp 3978 0.0 0.2 1688 600 pts/3 S+ 02:28 0:00 grep xterm
Another use of environment variables is storing shellcode. Perhaps you've found a buffer overflow, but there isn't enough room in the buffer for your NOP sled and the lengthy bind shellcode you picked up off of metasploit. Pack a NOP sled and your shellcode into your env variable then use the address of the env variable to overwrite the return address on the stack instead of all of your shellcode:
export SHELLCODE=`perl -e 'print "\x90"x200;'``cat shellcode`
Here's a quick little program in C that'll output the address of the env variable holding the shellcode:
#include <stdlib.h>
int main(int argc, char *argv[]) {
char *addr = getenv(argv[1]);
printf("\n%p\n", addr);
return 0;
}
Find the address of our shellcode and overwrite the stack's return address with our SHELLCODE env variable:
sh-3.00$ getenv SHELLCODE
SHELLCODE is located at 0xbffff892
sh-3.00$ ./vulnprog `perl -e 'print "\x92\xf8\xff\xbf"x10;'`
That's enough for now.
bash when run as a login shell reads from
/etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile in that order (assuming they exist). For any other kind of shell it reads from
~/.bashrc. So, if you want to make any of these env variables permanent, set them in the appropriate file for your shell.
