Colocation to Virtualization » Security

Linux, Networking, Security: Get Remote SSL Certificate From Command Line

Kevin Goodman — Wed, 03 Mar 2010 20:31:00 +0000

Easy way to get the SSL certificate of a server from the command line in Linux. The nice thing about it is that you get the full certificate chain. Nice for troubleshooting issues. After the “-connect”, specify the host and port you want to connect to. TCP port 443 is the default https port.

[user1@testserver ~]$ openssl s_client -connect mail.google.com:443

CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDIjCCAougAwIBAgIQHxn23jXdY6FCkYrVLMCrEjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRgw
FgYDVQQDFA9tYWlsLmdvb2dsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBANknyBHye+RFyUa2Y3WDsXd+F0GJgDjxRSegPNnoqABL2QfQut7t9CymrNwn
E+wMwaaZF0LmjSfSgRSwS4L6ssXQuyBZYiijlrVh9nbBbUbS/brGDz3RyXeaWDP2
BnYyrVFfKV9u+BKLrebFCDmzQ0OpW5Ed1+PPUd91WY6NgKtTAgMBAAGjgecwgeQw
DAYDVR0TAQH/BAIwADA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnRoYXd0
ZS5jb20vVGhhd3RlU0dDQ0EuY3JsMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggrBgEF
BQcDAgYJYIZIAYb4QgQBMHIGCCsGAQUFBwEBBGYwZDAiBggrBgEFBQcwAYYWaHR0
cDovL29jc3AudGhhd3RlLmNvbTA+BggrBgEFBQcwAoYyaHR0cDovL3d3dy50aGF3
dGUuY29tL3JlcG9zaXRvcnkvVGhhd3RlX1NHQ19DQS5jcnQwDQYJKoZIhvcNAQEF
BQADgYEAicju7fexy+yRP2drx57Tcqo+BElR1CiHNZ1nhPmS9QSZaudDA8jy25IP
VWvjEgaq13Hro0Hg32ZNVK53qcXwjWtnCAReojvNwj6/x1Ciq5B6D7E6eiYDSfXJ
8/a2vR5IbgY89nq+wuHaA6vspH6vNR848xO3z1PQ7BrIjnYQ1A0=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1778 bytes and written 316 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: DEB23CF699255054E08F69181B2342E9F6D6DF0D02B399C36034E0D8BE18AC0C
    Session-ID-ctx:
    Master-Key: D696A99CEC2FDD9535FE2EC936531AD129FD97E56441E37AE7A143C40304E395EA7DA039797B948B009B42DA5377E668
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1267560715
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
HTTP/1.0 400 Bad Request
Content-Type: text/html; charset=UTF-8
Content-Length: 1350
Date: Tue, 02 Mar 2010 20:11:57 GMT
Server: GFE/2.0
X-XSS-Protection: 0

Filed under: Linux, Middle Ware, Networking, Security

Linux, Security, LDAP: Local Authentication Fallback

Kevin Goodman — Wed, 16 Dec 2009 17:49:33 +0000

I have been setting up and integrating an LDAP authentication system into our infrastructure over the past few days. This is just one small “got-cha” that I ran into. The default setting in the OpenLDAP configuration (/etc/ldap.conf) is to continuously try reconnecting to the LDAP server on failure. This is definitely not what I want to happen if we loose LDAP. In this scenario, when connecting to the server via SSH, the session will hang and eventually timeout. This even removes the ability to login with a local system account.
Example of the timeout when LDAP server is down:

testuser@workstation4-l:~$ ssh test123@ldapclientsrv
Connection closed by 172.16.0.192

To begin, lets look at a typical error that you would get on the system if LDAP communication was down.

Dec 13 12:52:58 ldapServer sshd[15965]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.16: Can't contact LDAP server
Dec 13 12:52:58 ldapServer sshd[15965]: nss_ldap: reconnecting to LDAP server (sleeping 4 seconds)...
Dec 13 12:53:02 ldapServer sshd[15965]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.16: Can't contact LDAP server
Dec 13 12:53:02 ldapServer sshd[15965]: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)...
Dec 13 12:53:10 ldapServer sshd[15965]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.16: Can't contact LDAP server
Dec 13 12:53:10 ldapServer sshd[15965]: nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...

As noted before, I was unable to login with a local account. Turns out that the problem was with the default “bind_policy” in /etc/ldap.conf. Per the document:

# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
#bind_policy hard

This was changed to:

bind_policy soft

Once this was changed, I brought up the firewall on the LDAP server and refused connections. Ability to login via LDAP was gone, but the server did fail back to local system authentication

Note(s): When failing back to local authentication, there is no error sent back to the client trying to login, only errors go to /var/log/secure file. The server will just keep rejecting the users login until LDAP is back up. At least this gives you the ability to get in with a local system account in an emergency.

Example error to /var/log/secure when LDAP server is down and local authentication is rejecting the LDAP user received from the client:

Dec 13 12:59:59 ldapServer sshd[2588]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.0.22

Posted in Linux, Networking, Security

Linux / Security: User Account Expiration Management

Kevin Goodman — Tue, 20 Oct 2009 09:00:33 +0000

I am a firm believer in regular password rotation/change and Linux has a built in mechanism that makes it easy. The following is a brief overview of password and account ageing for Linux based systems.

The program that enables listing and modification on the expiration parameters is ‘chage’. Each individual user can view their account settings as shown below.
testuser@testServer:~$ chage -l testuser

Last password change					: Aug 07, 2009
Password expires					: Nov 05, 2009
Password inactive					: never
Account expires						: Aug 05, 1992
Minimum number of days between password change		: 90
Maximum number of days between password change		: 90
Number of days of warning before password expires	: 7

As you can see above, the last password change date is listed, as well as the expiration date for the current password. When executed from a non-privileged account, the user can only view their own account.

testuser@testServer:~$ chage -l root
chage: Permission denied.

Also, the non-privileged account can not change their settings either.

testuser@testServer:~$ chage -M 99 testuser
chage: Permission denied.

From the root account, you have to ability to modify all the settings for individual users.

root@testServer:~# chage
Usage: chage [options] [LOGIN]

Options:
  -d, --lastday LAST_DAY        set last password change to LAST_DAY
  -E, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -h, --help                    display this help message and exit
  -I, --inactive INACTIVE       set password inactive after expiration
                                to INACTIVE
  -l, --list                    show account aging information
  -m, --mindays MIN_DAYS        set minimum number of days before password
                                change to MIN_DAYS
  -M, --maxdays MAX_DAYS        set maximim number of days before password
                                change to MAX_DAYS
  -W, --warndays WARN_DAYS      set expiration warning days to WARN_DAYS

Before modification, I am going to turn off all expiration settings on the ‘testuser’ account. This is disabling password expiration on that individual account.

root@testServer:~# chage -E -1 -I -1 -m 0 -M 99999 testuser

No lets configure password aging for the test user. The first example below runs change in interactive mode.

root@testServer:~# chage testuser
Changing the aging information for testuser
Enter the new value, or press ENTER for the default

	Minimum Password Age [0]:
	Maximum Password Age [99999]: 90
	Last Password Change (YYYY-MM-DD) [2009-10-16]:
	Password Expiration Warning [7]:
	Password Inactive [-1]:
	Account Expiration Date (YYYY-MM-DD) [1969-12-31]: 2012-12-31

Verify that the settings took.

root@testServer:~# chage -l testuser
Last password change					: Oct 16, 2009
Password expires					: Jan 14, 2010
Password inactive					: never
Account expires						: Dec 31, 2012
Minimum number of days between password change		: 0
Maximum number of days between password change		: 90
Number of days of warning before password expires	: 7

The same can be accomplished using the command line, non-interactively.

root@testServer:~# chage -E 2012-12-31 -I -1 -m 0 -M 90 -W 7 testuser

With the above settings in place, the user should be warned 7 days before the password expires on their account. If the password is not changed before expiration day, on the next login the user will be forced to change their password.

Posted in Linux, Security

Linux / Security: Encrypted External Drive Part 1 – Urandom

Kevin Goodman — Fri, 04 Sep 2009 08:34:40 +0000

So I am re-doing my external RAID 1 drive enclosure. I love this little thing. It has two 2.5 inch 160gig SATA drives in it. The enclosure is connected via USB 2.0 but it does have an eSATA interface as well. I will be configuring this to have a 10 gig non-encrypted partition. The remaining ~150 gigs will be an encrypted (LUKS) filesystem to be used on my linux machine.

All of this will not be detailed here but will be split up in 3 blogs. Below just shows the time it takes to use Linux to overwrite the disk device using /dev/urandom. This is done to make it just that much harder for a would be hacker to try and brute force the key on the encrypted partition. If this is not done, the un-used space would just show up as empty, allowing for a more targeted attack against the pseudo random filesystem. Being pseudo-random means that it is not truly random. This being the case, with a lot of time and computing power, an attacker might be able to either brute force or find a pattern in the encryption.

So why not use /dev/random? For me, this would take forever! I do not have any special hardware or scripts pulling information from the environment and adding to the entropy pool. The data on this drive not being national security grade, /dev/random will do the job.

I know that the drive is under /dev/sdb. With that information, it is as simple as using “dd” (built in Linux utility) to overwrite all blocks on the drive with pseudo-random data.

root@tstbox:~# dd if=/dev/urandom of=/dev/sdb
dd: writing to `/dev/sdb': No space left on device
312581810+0 records in
312581809+0 records out
160041886208 bytes (160 GB) copied, 40284.5 s, 4.0 MB/s

From above, it tool 40,284.5 seconds to overwrite the drive with urandom data. This equals ~11 hours and 19 minutes. Definitely still a long time, but a lot faster than if /dev/random was used.

This workstation is not an impressive computer. It is a single CPU dual core machine with 2 gigs of ram. Below is the info on one of the cores.

root@tstbox:~# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
stepping	: 2
cpu MHz		: 1867.000
cache size	: 2048 KB
physical id	: 0
siblings	: 2

Notes: I wish I could use /dev/random and probably will eventually when I can sit a drive out for a week. Setting up external drives in this fashion is really geared towards data protection. Not only are the drives in a mirrored RAID (one can fail and everything would still run fine), important data is encrypted using a strong key. So who cares is the external enclosure walks away at a conference? I would be out ~190$ but the data will be safe.

Posted in Linux, Security

Linux / Security: Sudo ‘sudo su -’ vs ‘sudo -s’

Kevin Goodman — Tue, 18 Aug 2009 19:34:18 +0000

I always use ‘sudo su -’ when I need to get to a root shell. I have seen a few people before, and a new co-worker recently use ‘sudo -s’. Since I could not remember off hand the actual differences between the two, I had to check. The following will run through the actual limitations.

The big difference when using ‘-s’ are listed below

This option reads the environment or password file for the shell to be executed. Does not execute root shell!

All environment variables are passed over from the current account to the root accountPer the Linux man page for sudo
-s The -s (shell) option runs the shell specified by the SHELL environment variable if it is set or the shell as specified inpasswd(5).

Below is the typical sudo command when going to root
$ sudo su -

Now that we are root, check the current environment variables. Here we see that we are in the bash shell, which is different from the Korn (ksh) shell that the user was in. Also note, the home directory is ‘/root’, and the ‘PATH’ locations.

[root@testServ01 ~]# printenv
HOSTNAME=testServ01.testDomain.com
SHELL=/bin/bash
TERM=xterm
HISTSIZE=1000
USER=root
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
INPUTRC=/etc/inputrc
PWD=/root
LANG=en_US.UTF-8
SHLVL=1
HOME=/root
LOGNAME=root
CVS_RSH=ssh
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=localhost:10.0
G_BROKEN_FILENAMES=1
_=/usr/bin/printenv

When ‘sudo su -’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, we are now in the root user home directory (/root)
[root@testServ01 ~]# pwd
/root

Now that we have seen what ‘sudo su -’ does, lets check out ‘sudo -s’.
$ sudo -s

Time to check the current environment variables again. Main things to note here are the home directory, PATH definition, and the SUDO_* variables. This is definitely different then what was listed before.
# printenv
_=/usr/bin/printenv

DISPLAY=localhost:10.0
HISTSIZE=1000
HOME=/home/testuser01
HOSTNAME=testServ01.testDomain.com
INPUTRC=/etc/inputrc
LANG=en_US.UTF-8
LOGNAME=root
MAIL=/var/spool/mail/testuser01
PATH=/usr/bin:/bin
PWD=/home/testuser01
SHELL=/bin/ksh
SUDO_COMMAND=/bin/ksh
SUDO_GID=500
SUDO_UID=500
SUDO_USER=testuser01
TERM=xterm
USER=root
USERNAME=root

When ‘sudo -s’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, you can see that we are still in the same directory.
# pwd
/home/testact

Since the ‘PATH’ variable was passed from the testuers01 shell to the sudo environment, the administrative tools directories (/sbin, /usr/sbin) are not listed. This is not a huge issue, just more of a hassle if there were not passed from the user account.

Since this was the case for the test, I tried to issue ‘iptables’ without the absolute path. Per below, it failed.

# iptables -L
/bin/ksh: iptables: not found [No such file or directory]

Since I do actually have root level access, when I issue the command with the absolute path it works fine

# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

To conclude ‘sudo -s’:

does NOT change the shell

‘PATH’ does not change since root shell is not executed

carries over all environment variables from the non-privileged user

Notes: So to be safe, I will still use ‘sudo su -’ when needing root level access. Seems that the ‘sudo -s’ option would be a little more safe for some users. Mainly due to the sbin locations not being in the ‘PATH’. This would make the user execute most administrative commands using the full path to the executable, unless sbin(s) were exported.

The big difference when using ‘-s’ are listed below

This option reads the environment or password file for the shell to be executed. Does not execute root shell!

All environment variables are passed over from the current account to the root account

Per the Linux man page for sudo

-s  The -s (shell) option runs the shell specified by the SHELL environment variable if it is set or the shell as specified in

passwd(5).

Below is the typical sudo command when going to root

$ sudo su -

[root@testServ01 ~]# printenv

HOSTNAME=testServ01.testDomain.com

SHELL=/bin/bash

TERM=xterm

HISTSIZE=1000

USER=root

PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

INPUTRC=/etc/inputrc

PWD=/root

LANG=en_US.UTF-8

SHLVL=1

HOME=/root

LOGNAME=root

CVS_RSH=ssh

LESSOPEN=|/usr/bin/lesspipe.sh %s

DISPLAY=localhost:10.0

G_BROKEN_FILENAMES=1

_=/usr/bin/printenv

When ‘sudo su -’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, we are now in the root user home directory (/root)

[root@testServ01 ~]# pwd

/root

Now that we have seen what ‘sudo su -’ does, lets check out ‘sudo -s’.

$ sudo -s

# printenv

_=/usr/bin/printenv

DISPLAY=localhost:10.0

HISTSIZE=1000

HOME=/home/testuser01

HOSTNAME=testServ01.testDomain.com

INPUTRC=/etc/inputrc

LANG=en_US.UTF-8

LOGNAME=root

MAIL=/var/spool/mail/testuser01

PATH=/usr/bin:/bin

PWD=/home/testuser01

SHELL=/bin/ksh

SUDO_COMMAND=/bin/ksh

SUDO_GID=500

SUDO_UID=500

SUDO_USER=testuser01

TERM=xterm

USER=root

USERNAME=root

When ‘sudo -s’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, you can see that we are still in the same directory.

# pwd

/home/testact

Since this was the case for the test, I tried to issue ‘iptables’ without the absolute path. Per below, it failed.

# iptables -L

/bin/ksh: iptables: not found [No such file or directory]

Since I do actually have root level access, when I issue the command with the absolute path it works fine

# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all – anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all – anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

To conclude ‘sudo -s’:

does NOT change the shell

’PATH’ does not change since root shell is not executed

carries over all environment variables from the non-privileged user

Posted in Linux, Security

Linux / Security: Iptables CLI – List Rules Without DNS Resolution

Kevin Goodman — Tue, 02 Jun 2009 13:13:12 +0000

This is quick and a little basic, but most people do not actually read the “man pages” or documentation. The majority of the time, requests for access comes in specifying IP address instead of hostnames (FQDN). I actually prefer this, but when doing a typical “iptables -L”, the reverse DNS is automatically checked for all IPs.

Most of the time I do not actually know the hostname that is associated and makes it hard to confirm the rule without doing a dns lookup on my own. Below is the typical output of the command.
[root@testserver ~]# iptables -L

Chain Firewall-INPUT
(2 references)
target     prot opt source               destination
ACCEPT     tcp  --  mail.asdf.com        anywhere            tcp dpt:ssh
ACCEPT     tcp  --  static.123.net       anywhere            tcp dpt:ssh
ACCEPT     tcp  --  private.9z.com       anywhere            tcp dpts:ftp-data:ftp
ACCEPT     tcp  --  nto.ntpgr.com        anywhere            tcp dpts:ftp-data:ftp

Iptables has a built in option to disable DNS resolution. This is done by passing “-n” in conjunction with “-L” and shown below.

[root@testserver ~]# iptables -L -n
Chain Firewall-INPUT
(2 references)
target     prot opt source               destination
ACCEPT     tcp  --  10.1.129.119         0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  172.168.22.87        0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  172.33.100.2         0.0.0.0/0           tcp dpts:ftp-data:ftp
ACCEPT     tcp  --  10.90.15.104         0.0.0.0/0           tcp dpts:ftp-data:ftp

Above you can see how easy it would be to verify the rules now without knowing the hostname or performing a lookup on your own.

Notes: The iptables output was edited to remove non-relevant information and all IPs/hostnames were changed.

Posted in Linux, Networking, Security

Linux/Networking/Security: TFTP Deamon Setup and Cisco Configuration Backup

Kevin Goodman — Tue, 31 Mar 2009 13:50:13 +0000

This is just a quick walk-through on setting up TFTP service on a RedHat, Centos, or Fedora system. In general, this process should transfer over to other Linux (not BSD!) derived distributions.

[root@tftpsrv ~]# yum install tftp
Resolving Dependencies
--> Running transaction check
---> Package tftp-server.i386 0:0.42-3.1.el5.centos set to be updated
--> Processing Dependency: xinetd for package: tftp-server
--> Running transaction check
---> Package xinetd.i386 2:2.3.14-10.el5 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 tftp-server             i386       0.42-3.1.el5.centos  base               27 k
Installing for dependencies:
 xinetd                  i386       2:2.3.14-10.el5  base              124 k

Transaction Summary
=============================================================================
Install      2 Package(s)
Update       0 Package(s)
Remove       0 Package(s)         

Total download size: 151 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): tftp-server-0.42-3 100% |=========================|  27 kB    00:00
(2/2): xinetd-2.3.14-10.e 100% |=========================| 124 kB    00:00
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: xinetd                       ######################### [1/2]
  Installing: tftp-server                  ######################### [2/2]

Installed: tftp-server.i386 0:0.42-3.1.el5.centos
Dependency Installed: xinetd.i386 2:2.3.14-10.el5
Complete!

Edit configuration to enable tftp

[root@tftpsrv ~]# vi /etc/xinetd.d/tftp
# default: off
# description: The tftp server serves files using the trivial file transfer \
#       protocol.  The tftp protocol is often used to boot diskless \
#       workstations, download configuration files to network-aware printers, \
#       and to start the installation process for some operating systems.
service tftp
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /tftpboot        -> some directory (/tftpfiles)
        disable                 = yes            -> no
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

Create directory specified in tftp configuration file

[root@tftpsrv xinetd.d]# mkdir /tftpfiles

Start up xinetd. This is used to call tftp

[root@tftpsrv ~]# /etc/init.d/xinetd start
Starting xinetd:                                           [  OK  ]

[root@tftpsrv xinetd.d]# iptables-save > /etc/init.d/iptables
[root@tftpsrv xinetd.d]# iptables -F

Below, the tftp put will fail. This is due to the file needing to be created on the TFTP server before the client can write to it. This is the only real security there is to TFTP. You at least need to know the filename before the file can be written or read.

C9124SW5# copy running-config tftp:CISCSCOCFG1
Enter hostname for the tftp server: 172.16.100.6
Trying to connect to tftp server......

TFTP put operation failed:Undefined error code (2)

Create the file to be saved from switch and change the permissions

[root@tftpsrv ~]# touch /tftpfiles/CISCSCOCFG1
[root@tftpsrv ~]# chmod 777 /tftpfiles/CISCSCOCFG1

Tell the switch to save the file

C9124SW5# copy running-config tftp:CISCSCOCFG1
Enter hostname for the tftp server: 172.16.100.6
Trying to connect to tftp server......
|
TFTP put operation was successful

Check the services file to find the TFTP port and protocol information

[root@tftpsrv]# cat /etc/services | grep tftp
tftp        69/tcp
tftp        69/udp

Bring the firewall back up so we can insert rules to allow TFTP in

[root@tftpsrv]# /etc/init.d/iptables restart

On my test server, the firewall chain is “RH-Firewall-1-INPUT”. I always prefer inserting new firewall rules as the first rule. Most servers keep a few custom reject rules and most are explicit allow with the default deny at the end. Inserting the new rule as the first will normally bypass those that might reject before it ever gets to the tftp rule.

[root@tftpsrv]# iptables -I RH-Firewall-1-INPUT 1 -s 172.16.100.98 -p tcp --dport 69 -j ACCEPT
[root@tftpsrv]# iptables -I RH-Firewall-1-INPUT 1 -s 172.16.100.98 -p udp --dport 69 -j ACCEPT

The above statements tell iptables to insert “-I” the new rule into the chain “RH-Firewall-1-INPUT” as rule number “1″. The -s is specifying the source, -p the protocol –dport the destination port and -j allows the connection to establish by jumping over to ACCEPT.

Verify the rules are there

[root@tftpsrv]# iptables -L
Chain RH-Firewall-1-INPUT
target     prot opt source               destination
ACCEPT     udp  --  172.16.100.98        anywhere            udp dpt:tftp
ACCEPT     tcp  --  172.16.100.98        anywhere            tcp dpt:tftp

Save the rules in sysconfig so they will be persistent through reboots

[root@tftpsrv]# iptables-save > /etc/sysconfig/iptables

Notes: Never flush your iptables rules “iptables -F” on production systems that are not protected by a firewall or are on are public IP. Always be sure to backup/save your iptables configuration when testing. Also, if you are not familiar with security, or there is someone else responsible for security in the company, as them before or have them modify the local iptables rules. Another good rule for servers running TFTP, FTP, Telnet, DNS, and mail is to have servers dedicated for each. These are some of the most exploited servers out there.

Posted in Linux, Networking, SAN (Storage Area Network), Security

Linux/Security: Scponly SFTP Fix For RedHat and Centos 5.x (and possibly Fedora)

Kevin Goodman — Tue, 17 Mar 2009 14:50:12 +0000

The current scponly release does not function correctly out of the box for 5.x Redhat and Centos distributions. I was unable to test Fedora, but I expect the same problems there. Accounts created with scponly will fail to connect via scp or sftp without a /dev/null device inside the users chroot (jail). The bad thing is that enabling debugging and checking the logs will show now issue. The logs showed ssh authenticate the username and password and drop the session to the sftp subsystem. After that, it would just show a disconnect. Below is the fixed I used to get scponly working.

Using scponly “make jail” command to setup the initial user. I removed most of the generic output from the command.

[root@testserver01 scponly-4.8]# make jail
/usr/bin/install -c -d /usr/local/bin
/usr/bin/install -c -d /usr/local/man/man8
/usr/bin/install -c -d /usr/local/etc/scponly
/usr/bin/install -c -o 0 -g 0 scponly /usr/local/bin/scponly
/usr/bin/install -c -o 0 -g 0 -m 0644 scponly.8 /usr/local/man/man8/scponly.8
/usr/bin/install -c -o 0 -g 0 -m 0644 debuglevel /usr/local/etc/scponly/debuglevel
if test "xscponlyc" != "x"; then
		/usr/bin/install -c -d /usr/local/sbin;
		rm -f /usr/local/sbin/scponlyc;
		cp scponly scponlyc;
		/usr/bin/install -c -o 0 -g 0 -m 4755 scponlyc /usr/local/sbin/scponlyc;
	fi
chmod u+x ./setup_chroot.sh
./setup_chroot.sh

Username to install [scponly]newact
home directory you wish to set for this user [/home/newact]
name of the writeable subdirectory [incoming]

creating  /home/newact/incoming directory for uploading files

Your platform (Linux) does not have a platform specific setup script.
This install script will attempt a best guess.
If you perform customizations, please consider sending me your changes.
Look to the templates in build_extras/arch.
 - joe at sublimation dot org

please set the password for newact:
Changing password for user newact.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Now that the user is created, lets test the sftp session from a different system

user1@workstation03:~/.ssh$ sftp newact@10.1.3.43
Connecting to 10.1.3.43...
newact@10.1.3.43's password:
Connection closed

So we see that the connection failed. The reason here is that there is no /dev/null device within the users chrooted home (jail). Scponly does not auto-create this needed device.

[root@testserver01 scponly-4.8]# mkdir -p /home/newact/dev/
[root@testserver01 scponly-4.8]# cp -a /dev/null /home/newact/dev/

After re-testing the connection, you can see that everything is now functioning fine. I was able to push a file to the incoming folder in the working chrooted (jailed) environment.

user1@workstation03:~/.ssh$ sftp newact@10.1.3.43
Connecting to 10.1.3.43...
newact@10.1.3.43's password:
sftp> ls
dev       etc       incoming  lib       usr
sftp> cd incoming
sftp> put testfile
Uploading testfile to /incoming/testfile
testfile                                                                                                100%  885     0.9KB/s   00:00
sftp> exit

Notes: For each user account that you create with scponly chrooting scripts, you will need to create the dev directory, as well as the null device under the users home directory. This is definitely something that can be manually added to the setup_chroot.sh easily.

Posted in Linux, Security

Linux/Security: Gathering Filesystem,Device, and Port Process Details With fuser

Kevin Goodman — Thu, 05 Mar 2009 15:13:10 +0000

When troubleshooting a *nix box, working knowledge of file system, network, and process utilities are a necessity. The main ones for me are mount, lsof, dd, ps, fsck, netstat, tcpdump, and fuser. All of these tools are very basic, but most admins seem to not know about or utilise fuser. All of fusers functionality can be accomplished by using any of the above commands together. In the below examples, the same end results can be archived by using kill and lsof together, but why not just use one tool?

To begin, we will be passing fuser the -m switch to specify both a device and file(system).

       -m     name specifies a file on a mounted file system or a block device
              that is mounted. All processes accessing files on that file sys-
              tem  are  listed.  If a directory file is specified, it is auto-
              matically changed to name/. to use any file system that might be
              mounted on that directory

In it’s basic form, fuser will provide only the process id(s) (PID) that are currently utilising the specified file/device

root@testbox:~# fuser -m /media/disk/
/dev/sdb1:            5535c  5589c

The above example showed that process 5355 is currently utilizing something on the /media/disk file system. Below is the same example, but specifying the actual device that is mounted on /media/disk.

root@testbox:~# fuser -m /dev/sdb1
/dev/sdb1:            5535c  5589c
From there, we can use 'ps' to reveal what's going on

root@testbox:~# ps -axc | grep 5589
 5589 pts/1    S+     0:00 vi
root@testbox:~# ps -axc | grep 5535
 5535 pts/1    Ss     0:00 bash

Fuser also gives us the ability to terminate the any processes that are utilizing the filesystem/device. The following commands utilises -k to initiate the kill, -m to set the target, -i to prompt the user for verification, and -TERM to send the term signal to the process(es).

root@testbox:~# fuser -kmi -TERM /dev/sdb1
/dev/sdb1:            5535c  5589c
Kill process 5535 ? (y/N) y
Kill process 5589 ? (y/N) y

This is what it looks like from there users end when the process is killed

user01@testbox:/media/disk$
vi File.txt
Vim: Caught deadly signal TERM
Vim: Finished.
Terminated

Here we will be adding the -u and -v options to obtain more details from fuser.
Direct from the help output:

    -u        display user IDs
    -v        verbose output

Doing so displays the username, process id (PID), type of access, and the running command. In this case, we are looking at the actual device.

root@testbox:~# fuser -muv /dev/sdb1
                     USER        PID ACCESS COMMAND
/dev/sdb1:           user01   6457 F.... (user01)vi

When trying to unmount a device while a process is currently utilizing a file, the unmount will fail.

Below will kill all the processes running on the sdb1 device and allow it to be unmounted.

root@testbox:~# fuser -km -TERM /dev/sdb1
/dev/sdb1:            6403

Passing the -TERM parameter causes fuser to perform the same as doing “kill -9 6403″. Below is the list of signals that fuser can send when -k is used

root@testbox:~# fuser -l
HUP INT QUIT ILL TRAP ABRT IOT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM
STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH IO PWR SYS
UNUSED

For the last examples, fuser will be used to see what command is bound to TCP port 22.

root@testbox:~# fuser -uv 22/tcp
                     USER        PID ACCESS COMMAND
22/tcp:              user01   7288 F.... (root)sshd

The same can be accomplished as follows

root@testbox:~# fuser -nuv tcp 22
                     USER        PID ACCESS COMMAND
22/tcp:              root       2267 F.... (root)sshd

Full help output

Usage: fuser [ -a | -s | -c ] [ -n SPACE ] [ -SIGNAL ] [ -kimuv ] NAME...
             [ - ] [ -n SPACE ] [ -SIGNAL ] [ -kimuv ] NAME...
       fuser -l
       fuser -V
Show which processes use the named files, sockets, or filesystems.

    -a        display unused files too
    -c        mounted FS
    -f        silently ignored (for POSIX compatibility)
    -i        ask before killing (ignored without -k)
    -k        kill processes accessing the named file
    -l        list available signal names
    -m        show all processes using the named filesystems
    -n SPACE  search in this name space (file, udp, or tcp)
    -s        silent operation
    -SIGNAL   send this signal instead of SIGKILL
    -u        display user IDs
    -v        verbose output
    -V        display version information
    -4        search IPv4 sockets only
    -6        search IPv6 sockets only
    -         reset options

  udp/tcp names: [local_port][,[rmt_host][,[rmt_port]]]

Notes: As you can see, fuser can be used in many different ways and features overlap in some areas with ‘ps’ and ‘lsof’. The main use for me is the ability to look in on what is currently running on filesystems and devices.

Posted in Linux, Security

Linux: Generating Strong Passwords Using random/urandom

Kevin Goodman — Wed, 07 Jan 2009 22:36:06 +0000

Occasionally, I find myself logged into a system that does not have a random password application installed and do not want to go to the trouble of downloading one. Below is the easiest processes that I have found to generate a pretty random password from any Linux variant.

To begin, strait from the Linux man page:

/dev/random
When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

/dev/urandom
A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your appli‐cation, use /dev/random instead.

So basically, using /dev/random results in the strongest and most random characters. Only downfall is the wait needed unless you have a lot of noise or specific hardware to accelerate the process.

* I tested a cut and paste from this page and some of the lines did not work correctly due to either the CSS or WordPress doing something weird with the ‘ and ` symbols. So if one of the strings do not work for you, try deleting the ‘ and adding it back in.

Creating random passwords which contains no special characters, is 10 characters long and displays 4

$ cat /dev/urandom| tr -dc 'a-zA-Z0-9' | fold -w 10| head -n 4
z4w7RENNIn
ZOYg80cuQx
Kgm6IrS5wc
F741uiEXl6

Creating passwords which DO contain special characters, and is 12 characters long. The grep at the end might seem a little redundant, but depending on how short your character length is (using fold), urandom will result in stings with no special characters. Grep keeps that from happening here.

$ cat /dev/urandom| tr -dc 'a-zA-Z0-9-_!@#$%^&*()_+{}|:<>?='|fold -w 12| head -n 4| grep -i '[!@#$%^&*()_+{}|:<>?=]'
a(PYY5oid#2Z
>s#e)C5Kl=kc
63r)WBt9Y)^J
2_a5RLJV

Below shows just how quick it is to use ‘urandom’
$ time cat /dev/urandom| tr -dc 'a-zA-Z0-9-_!@#$%^&*()_+{}|:<>?='|fold -w 12| head -n 4| grep -i '[!@#$%^&*()_+{}|:<>?=]'
GiTG=JUu?OEN
UOAzoyQ:p>TQ
fQVa8@&wytnQ
$PaMT*70z|fh

real    0m0.158s
user    0m0.028s
sys    0m0.048s
Now for better randomness we will use /dev/random.  This takes a lot longer on anything thats not server grade, or has special hardware.
$ time cat /dev/random| tr -dc 'a-zA-Z0-9-_!@#$%^&*()_+{}|:<>?=' |fold -w 10| head -n 1| grep -i '[!@#$%^&*()_+{}|:<>?=]'

}>71Bw_DjN

real    25m47.473s
user    0m0.032s
sys    0m0.172s
I tested this with /dev/random while writing the blog.  On this old laptop hardware, I was able to generate one 10 character string about every 20-30 minutes.



Now these stats were collected from a crappy laptop running Ubuntu.  Specs as follows:
# cat /proc/cpuinfo
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 9
model name    : Intel(R) Pentium(R) M processor 1500MHz
and 2 gigs of ram.
If you haven’t caught on to the command string, the following can be modified to meet your standards:
- “tr -dc ‘a-zA-Z0-9-_!@#$%^&*()_+{}|:<>?=’” any range or character can be removed.  I know some auth systems are not compatible with some characters

- “fold -w 10” this is the length cut off point of the string to be generated.  Increase or decrease for more or less characters.

- “head -n 4” just pulls four results.  If more or less is needed, modify this number.

Notes:    Yes, I know this is pseudo-random.  For the majority of people, using urandom will work just fine.  If not, /dev/random is a lot better.  To reach the best level, you can try using feeds from external sources.  People have used anything from external antennas, webcams, to nuclear decay



Wikipedia article
random.org

Posted in Linux, Security

Splunk: Port is already bound

Kevin Goodman — Tue, 18 Nov 2008 15:55:16 +0000

After installing a new license key for Splunk, the next step is to restart the Splunk service. I did so from the web interface for Splunk and it eventually timed out.

I tried to stop the service via splunk command line, but that failed.
[user@splunk ~]# /opt/splunk/bin/splunk stop
splunkweb is not running. [FAILED]
Stopping splunkd. This can take a few minutes. Please be patient…
… still shutting down …
… still shutting down …

I used ctrl+c to cancel the “splunk stop” since it was not getting anywhere. A ps reveals that splunk is still currently running
[user@splunk ~]# ps -auxc | grep splunk
user      9409 75.9 30.0 386256 154812 ?       Sl   10:09   0:55 splunkd
user      9410 0.3 0.2 15172 1464 ?        Ss   10:09   0:00 splunkd
user      9429 0.0 0.1 15172   576 ?        S    10:09   0:00 splunkd
user      9604 13.2 3.1 63188 16184 ?        RNs 10:09   0:06 splunk-optimize
user      9873 11.0 4.9 30552 25668 ?        RNs 10:10   0:03 splunk-optimize
user      9963 9.3 5.9 56124 30804 ?        RNs 10:10   0:00 splunk-optimize

Killed the process using -9
[user@splunk ~]# kill -9 9409

Went to restart Splunk and it failed
[user@splunk ~]# /opt/splunk/bin/splunk start
splunkd 9409 was not running.
Stopping splunk helpers. This can take a few minutes. Plea[ OK ]tient…
Stopped helpers.
Removing stale pid file… done.
Checking prerequisites…
Checking http port [8000]: already bound
ERROR: The http port [8000] is already bound. Splunk needs to use this port.
Would you like to change ports? [y/n]:

Ok, so something still currently has the port bound. Lets find out. I used lsof to do so
[user@splunk ~]# lsof -i TCP:8000
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
python 9521 user 15u IPv4 1867658 TCP *:irdmi (LISTEN)

So it looks like splunk stats a python listener to grab the incoming HTTP requests. Time to kill that also
[user@splunk ~]# kill -9 9521

This time the restart works and the system is back online with the new license.
[user@splunk ~]# /opt/splunk/bin/splunk start
Checking prerequisites…
Checking http port [8000]: open
Checking mgmt port [8089]: open
Verifying configuration. This may take a while…
Finished verifying configuration.
Checking index directory…
Verifying databases…
Verified databases: _audit, _blocksignature, _internal, _thefishbucket, history, mail, main, sampledata, splunklogger, summary

Checking for SELinux.
Checking index files
All index checks passed.
All preliminary checks passed.
Starting splunkd… [ OK ]
PID 9521 was not running. removing stale pid file… done.
Starting splunkweb… [ OK ]
Splunk Server started.

The Splunk web interface is at https://splunk.x.com:8000
If you get stuck, we’re here to help. Feel free to email us at ‘support@splunk.com’.

Note: I love lsof to locate what process is bound to a port. I will be doing a blog just on troubleshooting with lsof soon.

Posted in Linux, Security

Linux/NetApp: NFS (NetApp) Fstab Mount

Kevin Goodman — Wed, 12 Nov 2008 11:13:43 +0000

The following details how to map an NFS point, this case to a Netapp, using fstab

Edit the fstab file. In this example, 192.168.1.100 is the NFS, the NFS export to be mounted is /vol/dir1, and local directory to be mapped to is /dir1. Next is the mount point type. For details on the rest of the options, use ‘man nfs’ from the command line.
# vi /etc/fstab
192.1.1.100:/vol/dir1 /dir1 nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,nfsvers=3,timeo=600,actimeo=0 0 0

Create the local directory
# mkdir /dir1/

Mount always searches /etc/fstab if just a label (/dir1) is passed to it. Here, it found the entry in fstab and mounted it.
# mount /dir1/

Using df to verify that mount did connect the NFS point
# df -h | grep dir
192.1.1.100:/vol/dir1
32G 96K 32G 1% /dir1

Move into the mount point
# cd /dir1

In this example, the local group luser needs to have full access to the share. Below shows the changing of ownership from root to luser.
# chgrp luser .

Switch to the user luser1, who is also in the luser group
# su – luser1

Move into the new NFS mount point
[luser1@x ~]$ cd /dir1/

Create an empty file to test write access
[luser1@x dir1]$ touch asdf

Use ls to make sure the file exists.
[luser1@x dir1]$ ls
asdf

Logout of luser since testing is done.
[luser1@x /]$ exit
logout

Note: The title of this is NFS (NetApp) Fstab Mount because technically this should work for any NFS mount point, not just a NetApp one.

Posted in Linux, NAS, Security

Linux Awk, Sort, and Uniq Log Searching

Kevin Goodman — Tue, 11 Nov 2008 19:03:29 +0000

I have used awk to aide in log parsing for a few years now. A few years back, I managed HIGH traffic DNS and mail spooling servers at a telecom. This made it very difficult for a home grown network IDS box to keep track of everything, due to high throughput. Occasionally, something would get through that would cause latency on the cluster. Normally this was someones DNS forwarding server that hung and blasted 5k queries a second to the DNS pool. So, this meant command line troubleshooting. The following is just an example of using the command strings to check an Apache log.

Move to the log directory
# cd /IBM/HTTPServer/logs/

This server does a decent amount of traffic. The following pulls out all the hits from Nov 11 (about 4 hours worth from system clock) and dumps them to novaccess file.
# cat access_log | grep “11/Nov/2008″ > novacces

Now we look into novaccess. The following views the file using cat, passes the data over to awk. Awk prints off only the first data of the file using “print $1″, which is the connecting IP address. From there, its handed over to uniq to count the number of occurrences for each IP and prefix the resulting number to each IP address. That information is handed over to sort using -g to compare according to general numerical value, and “r” to reverse the order. Reversing is used to display the IPs with the highest count first, as not to scroll 100 pages. Besides, who cares about the one hitters?

# cat novacces| awk ‘{print $1}’ | uniq -c | sort -gr | more
170 217.x.x.90
142 172.x.x.124
120 172.x.x.124
92 172.x.x.124
89 172.x.x.124
88 172.x.x.124
87 172.x.x.124
85 217.x.x.90
85 172.x.x.124
82 172.x.x.124
81 51.x.x.186

I clipped off after this since I am only concerned with the higher numbers. This query actually resulted in about 700 uniq lines.

Here is an example of what the file actually contained
# more novacces
127.x.x.92 – - [11/Nov/2008:00:00:03 +0000] “POST /servlet/heartbeat HTTP/1.1″ 200 76
255.x.x.109 – - [11/Nov/2008:00:00:05 +0000] “POST /servlet/heartbeat HTTP/1.1″ 200 76
255.x.x.189 – - [11/Nov/2008:00:00:15 +0000] “POST /servlet/heartbeat HTTP/1.1″ 200 76

Note: In awk, print $ can be incremented up to see other fields from the file. Also, remember all IPs are always changed/modified in my posts. So this means I do know that 255.x.x.x is not a valid IP address. Awk,uniq,more, and sort are all standard utilities provided by most *nix installations.

Posted in Linux, Security

VMWare and Sudo

Kevin Goodman — Mon, 03 Nov 2008 17:23:06 +0000

Below is how to setup sudo access for users on VMWare ESX servers. This is standard for any Linux distribution. Just for reference, VMWare ESX v* runs on top of Redhat Linux.

[___ @vm]# cat /etc/redhat-release
Red Hat Enterprise Linux ES release 3 (Taroon)

First, su to root
[user@vm03 user]$ su -
Password:

Next, edit /etc/sudoers
[___ @vm]# vi /etc/sudoers

For an individual user, add the following
user ALL=(ALL) ALL

Or you can setup a group and all users within will inherit sudo rights
%admins ALL=(ALL) ALL

Save the configuration with vi hit escape then type “:wq!” and enter.

Test
[user@vm03 user]$ sudo su -
Password:
[vm]# whoami
root

Note: This will allow the user to become or execute commands as root without needing to know the root password. Still, the user will be prompted for their password when they use sudo. More granular access is possible allowing users to execute only specific commands. If you want to bypass all password authentication (not a good idea) for sudo access, you can use NOPASSWD.

user ALL=(ALL) NOPASSWD: ALL

Posted in Linux, Security, VMWare

Restricting SFTP (jail/chroot)

Kevin Goodman — Fri, 24 Oct 2008 05:19:14 +0000

This is an installation reference for setting up jailed (chroot) sftp accounts.

Two common options exist for creating a chrooted environment to restrict SFTP users from traversing outside of their home directories. The first is compiling Open ssh from scratch and replacing the SFTP and one other executable with third party software. This would be a nightmare for patching/upgrading the ssh distribution. The second method, and the one this will be referencing from now on is Scponly. This script acts as a replacement shell that is executed after the standard SSH daemon authenticates the users account, avoiding any custom scripting of the OpenSSH distribution. Since scponly is a replacement shell, it is not a global change to all accounts. This allows the system administrator to pick and choose what with be chrooted.

Installation
Log into the system as root and follow these directions:

# mkdir /build
# cd /build
# wget http://internap.dl.sourceforge.net/sourceforge/scponly/scponly-4.8.tgz
# gunzip -d scponly-4.8.tgz
# tar -xvf scponly-4.8.tar
# cd cd scponly-4.8
# ./configure --enable-chrooted-binary --disable-scp-compat --disable-winscp-compat --disable-wildcards
# make ; make install
# echo /usr/local/sbin/scponlyc >> /etc/shells
# either type 'make jail' or execute './setup_chroot.sh'

The two commands ‘make jail’ and ‘./setup_chroot.sh’ with walk you through creating a jailed user account. The script will automatically create the users home directory and copy over all required libraries. After the script finishes, the following directories will be present:

/usr
/lib
/incoming
/etc

The only writable (where users will put data) directory is the /incoming folder (by default). The other directories including the chrooted ‘/’ (root) directory are all in the users chroot environment and are not writable by the individual user. Incoming directory will not show up if the “writable sub directory” option was changed from the default when running ‘make jail’ or ‘./setup_chroot.sh’

Note: Again, this is done in a way that ssh can be upgraded and or patched without affecting the sftp jail. Definitely want to avoid the headache of manual patching of systems and keeping track of the “one off” configurations.

Posted in Linux, Security