Primary blog moved to cipherdyne.org

All current blog posts are located at cipherdyne.org.

Thwarting Distributed SSH Brute Force Attempts

The SANS Internet Storm Center has an interesting diary entry that discusses a set of distributed brute force attempts against SSHD originating from a specific Class C subnet 58.147.10.0/24. According to the diary entry, a random selection of IP addresses within this subnet (which is owned by an organization in Thailand) are probing for listening SSH daemons on the open Internet, but each IP address is limiting the number of probes to two. Presumably this is to fly beneath the radar of any threshold-based detection mechanisms that might automatically block the attempts to communicate with SSHD.

     After rummaging around in my iptables logfiles, I noticed the following two log entries that show exactly two SYN packets from the IP 58.147.10.209 and destined for one of my systems:

Jun  3 14:55:06 minastirith kernel: DROP IN=eth0 OUT= \
MAC=00:13:d3:38:b6:e4:00:90:1a:a0:1c:ec:08:00 SRC=58.147.10.209 \
DST=71.N.N.N LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=11651 DF \
PROTO=TCP SPT=57473 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT \
(020405780402080A7CCF5BC50000000001030302)
Jun  3 14:55:09 minastirith kernel: DROP IN=eth0 OUT= \
MAC=00:13:d3:38:b6:e4:00:90:1a:a0:1c:ec:08:00 SRC=58.147.10.209 \
DST=71.N.N.N LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=11653 DF \
PROTO=TCP SPT=57473 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT \
(020405780402080A7CCF677D0000000001030302)

These two packets date back to June of last year, so the 58.147.10.0/24 network has apparently been active for quite some time. So, beyond the whois information mentioned in the ISC diary entry, can we tell anything more about our friend at 58.147.10.209? Because I always use the --log-tcp-options command line argument when building my iptables LOG rules, we have nice hex dumps included in the log messages above that represent the options portion of the TCP header. Having this information is necessary in order to passively fingerprint the remote TCP stack with p0f. The psad project re-implements the p0f algorithm over iptables log messages - p0f requires raw packet data acquired via libpcap - so what does psad have to say about the remote TCP stack?

[minastirith]# psad -A -m /var/log/messages --restrict-ip 58.147.10.209
[+] p0f(): 58.147.10.209 len: 60, frag_bit: 1, ttl: 44, win: 5840
[+] MSS: 1400, SACK, Timestamp: 2093964229, NOP, Win Scale: 2,
    Could not match 58.147.10.209 against any p0f signature.

Oh well, that is unfortunate. So, p0f does not seem to have a fingerprint that can characterize the remote TCP stack. I also looked through the passive OS fingerprinting database included with the ettercap project, but no luck there either. This was a manual process though because psad does not yet support the format of the fingerprints in ettercap, but this will be supported in the next release.

     In the meantime, the discussion in the diary entry advocates limiting the set of IP addresses that are allowed to talk to the SSH daemon, but ends with a comment stating that this is not always possible. I agree with this comment, and this is highlighted whenever you administer a system and you need access to SSHD from unpredictable source addresses (such as when travel is involved). A robust solution is to deploy Single Packet Authorization with a default-drop packet filter. Why let arbitrary source IP addresses communicate with your SSH daemon?

Article on psad at Linuxsecurity.com

Eckie Silapaswang has written an article on psad entitled "Meet the Anti-Nmap: PSAD" at linuxsecurity.com. This article focuses on installing and using psad on the EnGarde secure linux distribution. Topics covered include disabling SELinux, installation of psad via the Guardian Digital Secure Network (GDSN), psad configuration, and psad alerting. Eckie also covers the concept of active response with psad, and illustrates how psad responds to an attacker with the dynamic instantiation of iptables blocking rules.

gpgdir-1.7 released

The 1.7 release of gpgdir is ready for download. This release fixes a bug that was introduced in gpgdir-1.6 that caused previously encrypted directories to not be decrypted in --decrypt mode. This bug was reported by Per Ronny Westin, and the result is the addition of a new test suite so that bugs of this type don't creep back into the gpgdir development process. Here is some sample output of the new test suite in action:

[+] ==> Running gpgdir test suite <==

(Setup) gpgdir program compilation..................................pass (0)
(Setup) Command line argument processing............................pass (1)
(Test mode) gpgdir basic test mode..................................pass (2)
(Encrypt dir) gpgdir directory encryption...........................pass (3)
(Encrypt dir) Files recursively encrypted...........................pass (4)
(Encrypt dir) Excluded hidden files/dirs............................pass (5)
(Decrypt dir) gpgdir directory decryption...........................pass (6)
(Decrypt dir) Files recursively decrypted...........................pass (7)
(MD5 digest) match across encrypt/decrypt cycle.....................pass (8)
(Ascii-armor dir) gpgdir directory encryption.......................pass (9)
(Ascii-armor dir) Files recursively encrypted.......................pass (10)
(Ascii-armor dir) Excluded hidden files/dirs........................pass (11)
(Decrypt dir) gpgdir directory decryption...........................pass (12)
(Decrypt dir) Files recursively decrypted...........................pass (13)
(MD5 digest) match across encrypt/decrypt cycle.....................pass (14)

[+] ==> Passed 15/15 tests against gpgdir. <==
[+] This console output has been stored in: test.log

Here is the complete ChangeLog: for the 1.7 release:

• Bugfix to ensure that encrypted directories can actually be decrypted. This bug was reported by Per Ronny Westin.


• Updated to use the ".asc" extension for encrypted files in --Plain-ascii mode.


• Added gpgdir test suite. All future gpgdir releases (and including this 1.7 release) require that all gpgdir tests pass on the systems where gpgdir is developed.

Interfacing VIM with GnuPG Encrypted Files

Over the years the editor I have become the most familiar with is vim. It provides features that allow the software development process to go smoothly, such as split screens, syntax highlighting, integration with cscope tags, function folding, and more. By applying configuration directives to your ~/.vimrc file, you can instruct vim to perform some nice preprocessing functions against files. This blog post illustrates a ~/.vimrc tweak (originally from Wouter Hanegraaff) that allows vim to leverage GnuPG to decrypt a previously encrypted file, allow edits to be made, and then re-encrypted before it is written back to disk. Here is the section of the .vimrc file to allow such transparent encryption and editing:

" Transparent editing of gpg encrypted files.
" By Wouter Hanegraaff <wouter@blub.net>
augroup encrypted
au!
" First make sure nothing is written to ~/.viminfo while editing
" an encrypted file.
autocmd BufReadPre,FileReadPre *.gpg set viminfo=
" We don't want a swap file, as it writes unencrypted data to disk
autocmd BufReadPre,FileReadPre *.gpg set noswapfile
" Switch to binary mode to read the encrypted file
autocmd BufReadPre,FileReadPre *.gpg set bin
autocmd BufReadPre,FileReadPre *.gpg let ch_save = &ch|set ch=2
autocmd BufReadPost,FileReadPost *.gpg '[,']!gpg --decrypt 2> /dev/null
" Switch to normal mode for editing
autocmd BufReadPost,FileReadPost *.gpg set nobin
autocmd BufReadPost,FileReadPost *.gpg let &ch = ch_save|unlet ch_save
autocmd BufReadPost,FileReadPost *.gpg execute ":doautocmd BufReadPost " . expand("%:r")
" Convert all text to encrypted text before writing
autocmd BufWritePre,FileWritePre *.gpg '[,']!gpg --default-recipient-self -ae 2>/dev/null
" Undo the encryption so we are back in the normal text, directly
" after the file has been written.
autocmd BufWritePost,FileWritePost *.gpg u

You can combine this vim tweak with gpgdir to maintain recursively encrypted directories, and just edit the files directly. For example, the following sequence of commands shows the creation of an encrypted file and how vim then interfaces with GnuPG to allow transparent editing:

$ cat > somefile
private data
more private data
$ gpg -e somefile
$ wipe somefile
Okay to WIPE 1 regular file ? (Yes/No) yes
Operation finished.
1 file wiped and 0 special files ignored in 0 directories, 0 symlinks removed \
but not followed, 0 errors occured.
$ ls -l somefile.gpg
-rw-r--r-- 1 mbr mbr 618 2008-02-17 01:52 somefile.gpg
$ vim somefile.gpg
"somefile.gpg" [noeol] 3L, 618C

You need a passphrase to unlock the secret key for
user: "Michael Rash <mbr@cipherdyne.org>"
2048-bit ELG-E key, ID 1234ABCD, created 2007-05-01 (main key ID ABCD1234)

Enter passphrase:

<apply edits now, and hit :wq >

$ ls -l somefile.gpg
-rw-r--r-- 1 mbr mbr 932 2008-02-17 01:55 somefile.gpg

As you can see from the output above, the file was modified (and the original file somefile was deleted using wipe).

Finally, the 1.6 release of gpgdir is ready for download. This is a bugfix release that restores the exclusion of previously encrypted files from the file selection process, and includes a few minor install.pl enhancements as well. Here is the ChangeLog:

• Bugfix to not include previously encrypted files (i.e. those with a .gpg extension) in the encryption/decryption file list. This bug was introduced in gpgdir-1.5 when a change was made to ignore ascii-armored files.


• Added added LC_ALL=C locale setting for the install.pl script (this should help to ensure gpgdir is properly installed on most systems). Two new command line arguments --LC_ALL and --no-LC_ALL also allow the locale setting to be changed or not used at all.


• Added --Exclude-mod-regex option to the install.pl script so that it is possible to force the exclusion of perl modules that gpgdir would normally install. This is useful for ensuring that gpgdir references perl modules that are already installed in the system perl library tree instead of using those that are installed in /usr/lib/gpgdir.


• Updated to display command line usage warnings without automatically displaying the entire usage() page (which is quite long).