Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC VT100 terminal and, in addition, several control functions from the ISO 6429 (ECMA 48, ANSI X3.64) and ISO 2022 stan-dards (e.g. insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows moving text regions between windows. - man screen

Screen is a very useful program the same way any GUI Windows Managers like KDE/Gnome/Fluxbox are for multi-tasking between programs. Here is a quick list of functions and key combination’s.

Starting screen:
screen -e^Ja # This starts screen with escape command as Control-J-j. This is not the default way for screen but Ja is the secondary return key which is one of the few commands rarely used by programs as a shortcut key combination.

We’re going to refer to Control-J-j as C-J-j.


C-J-j-c = makes new windows
C-J-j-" = to come to graphical view of what windows you have
C-J-j-:title title_of_window = change title_of_window to what ever you wish the window to be called on the menu list.
C-J-j-:kill = this will kill frozen windows (this does happen from time to time
C-J-j-d = this detach the session for you to come back to later (for example over SSH on a stable server)
C-J-j-j = this will go to last window you where on
C-J-j-n = this will go to the next window on the list
C-J-j-p = this will go to the previous window on the list


Reattaching screen when detached
screen -x

To List all backgrounded sessions
screen -list

Attaching to a session when there is more than one
screen -x pid

Thanks,
Ash Palmer
Network Security Logistics

Posted under Ash

When a brute force scanner is trying to push its way in to your server you need to firewall the offending IP.
The offending server attacking you maybe more powerful than you think, leading to your server to become stressed due to the high number of connections continuing to try connecting to your server after you have added a DROP or REJECT rule in to iptables for the offending IP address, for example

iptables -I INPUT -s evil.hacker.org -p tcp --dport 22 -j DROP

Why is this bad? In UNIX “Everything is a File” so even these “starting” connections that you’ve dropped before they turn in to fully established sockets is using system memory and CPU cycles. We can reduce the amount of system resources these broken connections consume.

iptables -I PREROUTING -t mangle -s evil.hacker.org -p tcp --dport 22 -j DROP

This places the DROP rule in the first aspects of the Flow chart like firewalling diagram reducing the amount of resources required to next to nothing.

For more information on Linux Routing and Firewalling check:
Linux Advanced Routing & Traffic Control
Iptables Tutorial 1.2.2

Thanks,
Ash Palmer
Network Security Logistics

Posted under Ash

Keeping logs of user activity is sometimes important. Here is a method of locking down ways of escaping from command line logging in bash. This can be done in a few simple steps as followed:

add the following to the bottom of your /etc/profile script.

readonly HISTFILE

next you need to remove the suid bit of “chsh” this stops users from changing their shell type to one with different ways to escape from logging. To do this do the following as root:

chmod -s $( which chsh )

now we remove all the unwanted shell types. /etc/shells should only contain

/bin/bash

bash-3.1$ cat /etc/shells
/bin/bash


Check users in /etc/passwd and change all users who are using alternative shell types to /bin/bash. i suggest using the chsh command to do this. for example:

chsh -s /bin/bash user

we need to a fairly boring manual task depending on your scripting ability. every user who uses bash produces a .bash_history file in their user folder. users who have been using alternative shells will not have this file already.

The following commands are to secure a .bash_history file for one user, scripting a loop of some kind to deal with large amounts of users shouldn’t be too much work. modifying the ‘adduser’ command to automatically do these commands when you add a user or a daily contrab script to enforce permissions. as root:


touch /home/user/.bash_history
chown user:root /home/user/.bash_history
chmod 600 /home/user/.bash_history
chattr +a /home/user/.bash_history


What have we done? Well, we’ve;
1) made a blank file called .bash_history
2) made it owned by the user who will log to it
3) change permissions to read/write for user “user”
4) only allowed appending changes to .bash_history
5) in /etc/profile we’ve disabled the ability to unset the log file.

Thanks,
Ash Palmer
Network Security Logistics

Posted under Ash