topic Re: SSH in Security Containment in Operating System - HP-UX

SSH in Security Containment

Felipo Soranz UX — Mon, 26 Jun 2006 14:42:34 GMT

I'm trying to set up SSHD in a server with Security Containment installed, but it doens't seem to work.

Ok, now some command outputs:

--- Client ---

#ssh root@192.168.0.80
(nothing happens)

--- Server ---

# ps -ef | grep sshd
root 822 1 0 08:45:08 ? 0:00 /opt/ssh/sbin/sshd
root 3208 1547 0 17:37:18 console 0:00 grep sshd

# netstat -an | grep 22
tcp 0 0 *.22 *.* LISTEN
tcp 0 1 192.168.0.80.22 192.168.0.134.41846 SYN_RCVD
tcp 0 0 *.22 *.* LISTEN

--- Rules in /etc/cmpt/ concerning this problem ---

compartment INIT {
/* ... */
grant server tcp port 22 in_iface /* SSH daemon */
/* ... */
}

compartment in_iface {
interface lan0
}

-------

Any suggestions for trying to solve this problem will be appreciated, thanks in advance.

Re: SSH in Security Containment

Steven E. Protter — Mon, 26 Jun 2006 14:52:01 GMT

Shalom,

Secure shell is pretty secure (check name). Its a properly named product.

Try ssh -vvv root@192.168.0.80

At least you'll be sure its this other security product.

Try turning off the other security product and see if it works.

Good Luck,

SEP

Re: SSH in Security Containment

Felipo Soranz UX — Mon, 26 Jun 2006 16:01:09 GMT

From 2 different hosts:

felipo@uxso33:~$ ssh -vvv root@192.168.0.80
OpenSSH_4.1p1 Debian-7ubuntu4.1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.80 [192.168.0.80] port 22.

# ssh -vvv root@192.168.0.80
OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005
HP-UX Secure Shell-A.04.30.000, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: Seeding PRNG from /opt/ssh/libexec/ssh-rand-helper
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.80 [192.168.0.80] port 22.

If I disable the other products the SSH will work fine, but I need IPFilter and Security Containment because I'm going to run a secure web server environment on that server, but first I need to get SSH access to it.

Anyway, thanks for your help so far.

Re: SSH in Security Containment

ratan nalumasu — Tue, 27 Jun 2006 11:30:42 GMT

Hi

It is not clear from the description if you were able to narrow it down to Security Containment setup as the culprit, or if you believe if the IPFilter setup is a culprit too. Supposing that it is Containment, it is possible that sshd is trying to map the IP addresses back to hostnames via DNS and is experiencing problems. Add the following line/lines to INIT compartment and see if it solves the problem:

grant bidir udp peer port 53 in_iface /* permit DNS lookup */

Additionally (depending on configuration, I *think* you may need the following too):

grant bidir udp port 53 in_face /* DNS transfers for local caching server */

Re: SSH in Security Containment

Felipo Soranz UX — Tue, 27 Jun 2006 13:11:15 GMT

ratan, I also tried this with IPFilter rules disabled and Compartments enabled using the following line:

ipfstat -io | ipf -rf -

So I think the problem is really with compartments, since when I disable compartments (cmpt_tune -d) it works even with IPFilter rules loaded. I tried adding the rules for DNS that you posted and it still doesn't work. Also tried to add the hostnames to /etc/hosts but I really don't think it has to do with hostnames.

I'd like to add that when I try ssh root@192.168.0.80 I see the following in netstat -an:

--- Client ---

felipo@uxso33:~$ netstat -an | grep 22
tcp 0 1 192.168.0.134:42130 192.168.0.80:22 SYN_SENT

--- Server ---

# netstat -an | grep 22
tcp 0 1 192.168.0.80.22 192.168.0.134.42134 SYN_RCVD

------

I'm not an expert in networking but it seems that "some" communication is working but no connection.

Then I also tried to put sshd in debug mode:

# /sbin/init.d/secsh stop
HP-UX Secure Shell stopped
# ps -ef | grep sshd
root 4748 1547 1 15:52:07 console 0:00 grep sshd
# /opt/ssh/sbin/sshd -ddd
debug2: load_server_config: filename /opt/ssh/etc/sshd_config
debug2: load_server_config: done config len = 240
debug2: parse_server_config: config /opt/ssh/etc/sshd_config len 240
debug1: sshd version OpenSSH_3.9 [ HP-UX Secure Shell-A.03.91.009 ]
debug3: Not a RSA1 key file /opt/ssh/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /opt/ssh/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/opt/ssh/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
(nothing happens!)

But nothing happens when I try to connect from client machines.

For those reasons I think that the problem is with the compartment rules, but I don't know what I could be doing wrong, is there anything else I should be checking?

Re: SSH in Security Containment

Hrishikesh Talgery — Tue, 27 Jun 2006 15:28:52 GMT

Hi Felipo,

Looks like the server is not responding or
something is preventing it from responding.
So its still in SYN_RCVD state and looks
it has not sent the ACK.

Can you provide the IPFilter rules you are
using? Are you sure that the routing is not
modified when you enable compartments.

Thanks
Hrishikesh

Re: SSH in Security Containment

ratan nalumasu — Tue, 27 Jun 2006 17:11:57 GMT

Felipo:

I was unable to reproduce the problem on my box, so now we are going to go fishing.

Make sure that sshd is not running in a different cmpt ("getfilexsec /opt/ssh/sbin/sshd" should result in an error message; if not, do a "setfilexsec -d /opt/ssh/sbin/sshd" and try it again). Also make sure that you are not invoking the sshd from non-init cmpt either ("getprocxsec $$").

Assuming that it was not the problem, let us turn on a few debugs:
a) ndd -set /dev/tcp tcp_debug 1
b)run "adb -o -w /stand/vmunix /dev/kmem"
at the prompt, do "tcp_safer_debug_flag/W 1"
and "ucmdebug/W 5" and "lcmdebug/W 5" (all without quotes, of course)
c) strace > /tmp/strace.out &

Now run the "sshd -dddd" and try connecting.
After a second or two, interrupt and set the variables back to 0 to avoid excessive output into syslog. ("adb....", "lcmdebug/W 0" etc).
Then we have to take a look at /var/adm/syslog/syslog.log and /tmp/strace.out to see what we can figureout.

Re: SSH in Security Containment

Felipo Soranz UX — Wed, 28 Jun 2006 08:57:46 GMT

Hrishikesh Talgery,

I'm making most tests with IPFilter disabled just to be sure. When I turn compartments on I can access SSH even with IPFilter on, so it's not a problem with it or with SSH configuration.

I was skeptical about the problem being with routing but I tried to disable the second network interface and the routing for it and surprisingly it worked!

Now I have to check what was wrong with my old NIC/Routing configuration.

ratan,

I checked the security properties for SSHD. SSHD is being started in the INIT compartment, both in /sbin/init.d/secsh and from command line.

# getfilexsec /opt/ssh/sbin/sshd
getfilexsec: File "/opt/ssh/sbin/sshd" is not a privileged application
# getprocxsec $$
effective= BASIC
permitted= BASIC
retained= BASIC
cmpt= init
euid= zero

But as you can see above, the problem wasn't with compartment rules itself, but something about routing.

Anyway I have SSH access now and I am going to check what was wrong with routing.

That's it, thank you very much. Your help was indeed valuable.

Re: SSH in Security Containment

ratan nalumasu — Wed, 28 Jun 2006 10:08:57 GMT

That sounds good. Routing tables can be setup such that packets intended for one interface are actually delivered to another interface. Presumably the packet for lan0 is coming off of a different interface. You can set ndd tunable ip_strong_es_model to 1 to disable that feature (but your routers also need to be smart enough to deliver it to the right interface) or put the interfaces in different subnets so that packets do not go to an unexpected interface or put related interfaces in the same compartment.