How to disable SSH Timeout?

OpenSSH ClientAliveInterval
(SEE http://www.brandonhutchinson.com/OpenSSH_ClientAliveInterval.html)

Using an OpenSSH server's ClientAliveInterval, it is possible for the ssh server to send periodic "keep alive" messages to the ssh client, keeping the connection open indefinitely. This is useful when a firewall or other packet filtering device drops idle connections after a certain period of time. Note that this is different from the KeepAlive directive in ssh_config.

From the sshd_config manpage:

ClientAliveInterval
Sets a timeout interval in seconds after which if no data has
been received from the client, sshd will send a message through
the encrypted channel to request a response from the client. The
default is 0, indicating that these messages will not be sent to
the client. This option applies to protocol version 2 only.

Example (send "keep alive" messages every 5 minutes) on Red Hat Linux:

1. Add ClientAliveInterval 300 to /etc/ssh/sshd_config

2. Reload the sshd server configuration with /sbin/service sshd reload

Note: you may want to configure the ClientAliveCountMax value in sshd_config to set the number of times that "keep alive" messages are sent. If ClientAliveCountMax number of "keep alive" messages are not acknowledged by the ssh client, the connection is terminated by the ssh server. The default value of 3 should be sufficient for most users.

Note: you may want to configure TCPKeepAlive to "yes"

Maintaining FreeBSD

Wow, almost a couple of years have passed since I used FreeBSD last time. After turning into a Mac OS X, there is no need to install FreeBSD, though. This post will incrementally record some steps that I easily forget when maintaining a FreeBSD server. This time I installed FreeBSD 7.2. Probably, I will install apache, mysql, postgresql, tomcat, etc.

1] add myself to the group of wheel because UNIX has a stronger security policy, i.e. the principle of separation of privileges, than Linux and use "su" instead of "sudo" in Linux

# login as root
# pw usermod USER -G wheel
# groups USER
# logout as root and login as USER

2] update "ports" and upgrade the ports

$ login as USER
$ su
$ vi .cshrc
ADD "/usr/local/sbin" to PATH
SEE http://www.freebsd.org/doc/en/books/handbook/ports-using.html

3] set bash to user's default shell and csh to root's default shell, and set proper environment variables for them

$ bash
$ su
# cd /usr/ports/shells/bash
# make install clean
# exit
$ chsh -s /path/to/bash USER
$ grep ^USER /etc/passwd
$ cd; cp .profile .bash_profile
$ vi .bash_profile
ADD the following lines into the file:
# set prompt: ``username@hostname:/directory $ ''
PS1="[\u@\h:\w] "
case `id -u` in
0) PS1="${PS1}# ";;
*) PS1="${PS1}$ ";;
esac
$ source .bash_profile
$ su
# cd
$ vi .cshrc
CHANGE the line setting prompt as follows:
#set prompt = "%{\033[31m%}[root@`/bin/hostname -s`:%/]# "
set prompt = "[root@`/bin/hostname -s`:%/]# "
CHANGE the value of history and savehist to 10000

4] set a boot timer to a smaller value

$ su
# vi /boot/loader.conf
ADD the following line into the file:
autoboot_delay="NUMBER"

5] install tor and nmap

6] Mmm... What did I do next?

Escaping the censorship Part II

I finished solutions of the censorship both in in-order and out-of-order (i.e. reverse order) TCP out-of-delivery, i.e. we call TCP fragmentation in this Lab. There are several caveats in this Lab. First, TCP handshake with Scapy will trigger TCP RST by the kernel of the server side because it seems like those packets generated by Scapy bypass the correct initialization of TCP handshake. So, we should use socket programming to initiate TCP handshake. Second, no FIN packet will trigger the interrupt handler in the server to signal alarm so that the connection will be discarded and "Too Slow" message will be observed. Third, "Tha" seems to have a bug related to "sudo", which seems a common problem in latest Fedora distribution. Hence, such a problem should be taken into account when coding because OS scheduling is so slow that we can't predict some synchronization between processes if there exists multiple Python codes running at the same time and feeding one's output to another's input. Last but not least, a real IDS should be installed on "Ta" for future Lab. Otherwise, there are many ways to escape "iptables" rules.

This should be the last blog for me since there's nothing to do for the censorship Lab, though.

Escaping the censorship Part I

For this Lab, I installed all those required packages at Ta and made a simple solution to defeat the censorship, through which no TCP out-of-delivery is required at all. A trick is to send a line and pause a second before sending the next message, assuming that each line is parsed from "message.txt" so that no line will trigger TCP RST at all. I'm still working on TCP fragmentation with Scapy these days.

Port Scanning using nmap

I ran nmap from ba in order to find all boxes residing in a new subnet. Since the packet loss rate is high, I used a heuristic algorithm that might overcome such a downside. My heuristic algorithm is to use as many as scanning algorithms with multiple of iterations. I used 8 different scanning algorithms: default scanning (TCP scanning), SYN stealth, FIN stealth, indent scanning, null scanning, UDP scanning, Xmas scanning, and ping scanning (almost useless though). Each scanning algorithm was repeated 20 times and some random time interval was injected between scanning. With this heuristic algorithm, I thought that the probability that nmap can miss a box is negligible because of the number of iterations and the different scanning algorithms. Below are my answers to the questions posted in the Lab 3 handout:

Answer to "What are the IP addresses on the subnet? How many are there?"
> I found 4 boxes in total: 192.168.33.2 (FreeBSD), 192.168.33.22 (it's hard to tell OS for this box because many features are matched by multiple OSes, but I guess this is running a Linux because port 22, 80 and 111 are used by Linux applications most of time, even though Windows applications may also listen on those ports.), 192.168.33.40 (Windows box, probably Windows XP), 192.168.33.80 (Fedora box, probably Fedora Core 8).

Answer to "What kind of BSD distribution? What version?"
> 192.168.33.2 is running a FreeBSD, but it's hard to tell the exact version because there are many features matched by multiple versions by 5.4/5.5/6.1/6.2. However, since the latest version of FreeBSD is 7.1 and the version 6.4 is still up on the homepage, I personally believe that the version might be FreeBSD 7.1 with high probability, even though nmap may not have enough information about the latest version so that it didn't properly report. It's a sort of an educated guess. ;-)

Answer to "What other ports than port 80 is the web server listening on? What else can you tell about it?"
> 192.168.33.22, running a web server, is also listening on port 22 (ssh) and 111 (rpcbind) other than port 80. This means that 192.168.33.22 is also a SSH server. Besides, 192.168.33.80 is also running an Apache web server, which is also listening on port 22 (ssh) and port 631 (ipp). However, 192.168.33.2 is running a squid (web proxy) so that all HTTP requests will go to 192.168.33.2 first and then to 192.168.33.22 and/or 192.168.33.80 in case no cached data is found.

Answer to "Are there any other machines? What can you tell about those boxes/firewall rules? Is it a server or a client?"
> As mentioned above, there are two other boxes: 192.168.33.2 and 192.168.33.40. 192.168.33.40 seems a client, but all the rest boxes seem a server, because 192.168.33.40 opens 3 different ports (135, 139 and 445) that are not used for any server application, but the remaining boxes are running at least one well-known server application because of open ports, especially 192.168.33.2, along with SSH, SQUID and PRINT servers, is listening on at least 15 open ports. Besides, most packets to port 80 of 192.168.33.22 and/or 192.168.33.80 seem forwarded since 192.168.33.2 is working as the proxy server for 192.168.33.22 and/or 192.168.33.80 so that the firewall rules seem to protect 192.168.33.22 and/or 192.168.33.80 from being directly accessed from outside. The firewall rules should forward all HTTP packets for 192.168.33.22 and/or 192.168.33.80 to 192.168.33.2 first, though. Last but not least, a lot of packets to 192.168.33.2 and 192.168.33.80 are dropped by the firewall, especially more packet drops towards 192.68.33.80, because scanning towards those two boxes returns inconsistent reports frequently. This indicates there should exist some firewall rules to do so.

It was fun to find these boxes because port scanning is widely used by hackers when they collect information about the target to attack. Besides, nmap is powerful enough to scan those boxes and open ports, even though nmap seems confused when there are too much information in determining operating system and its version, or when there are not enough ports open.

Find the username of "joumon" in sudoers

As the title stated, please find "joumon" in the sudoers file. Period.

Integer Buffer Overflow

Due to some other stuff, I started Tuesday evening, but I couldn't finish it due to alef down. However, I could finish on Wednesday after struggling several hours. Initially, I thought SizeOfData was a local variable. It is my fault, though, because I was a little bit careless when analyzing the server code. With SizeOfData being a local variable, I was trying to find a way to overwrite the return address partially. For example, I found that the address space randomization of stack is skewed by 0xffffff and tried to find a proper stack address regardless of the randomization, but it turned out to be fruitless. And then, I also tried to find any binary of "ffe4" stored in the library, using GDB, but it turned out to be unsuccessful, too.

Anyway, it was easy to solve this problem after I found SizeOfData is really a global variable. What I have to do is to overwrite the return address with the address of SizeOfData. Then, when RET is executed, the control flow will jump to the address of SizeOfData and execute whatever is stored there. What I did was to place at the address of SizeOfData the corresponding binary to "jmp esp" and then the control flow will jump to the address pointed by the esp that contains the string that we passed to overflow the buffer. After then, it was automatic. The other minor issue was to make a proper order of the given strings, but it could be easily done by placing nopsleds, setting uid to zero, breaking chroot() jail and executing the shell. The other minor issue was that I placed 10 nopsleds strings before setuid() and 10 other nopsleds strings after execve() in case the jmpback doesn't have a precise offset, but actually I didn't have to do so because the given offset turned out to be precise. Anyway, thhis turned out to be inefficient and I removed them, though.

By the way, this was a great opportunity to learn a simple technique of integer buffer overflow, though. Unfortunately, however, this will still be harder for me if SizeOfData is a local variable, though. A couple years ago, I tried a buffer overflow over the network in RH9, but I didn't make it because of random padding between local variables and return address in the stack. Hence, I tried with RH7 instead. It'd be much better if I am given another shot to try on such a platform, though.