Wednesday, October 29, 2008

Exporting vm's from ESX to VMWare Server 2.0

Well, I hate to say it, but VMWare Server 2.0 is a little clunky. I don't get a lot of confidence using Internet Explorer to admin my vm's, but I can live with it. I also don't like how the vm admin service runs as a network service. It seems like it should be an optional install, in case IT policy allows remote administration of virtual environments. It just seems like its just one more thing to manage and watch for, an unnecessary increase in network attack surface with an application that may be very easily subverted.

What I can't live with is the mouse control, or lack of it, at the console of a windows OS running in VMWare Server 2.0...and it's running on a system with 4GB ram, a decent proc and win2k3 Std R2. Using the vm over RDP is reasonable and works well.

I was able to successfully import a ESX 3.5 image with Converter 3.0.3 to a VMWare Workstation 5.x compatiable image into VMWare Server 2.0. It didn't work with a VMWare Workstation 6.x compatiable image.

I wonder if VMWare has a security group that tries to crack its own apps?

Atlas Global Risk Index

Wondering what network attack signatures you may want to watch for?

http://atlas.arbor.net/risk/

Tuesday, October 28, 2008

Screen

Screen is probably my favorite application. It's a perfect example of the unix philosophy.

It's simply a window manager for terminal sessions, a great tool for developers, engineers and researchers that use multiple ssh sessions to perform their work.

Install it:

# pkg-add -r screen

The way I use it is by (re)connecting to a server where screen is installed, usually in a openbsd or freebsd vm that I run on a desktop or server machine. During the time I was disconnected (travelling to/from work, etc) screen maintained my many ssh sessions for me, and when reconnect I execute the following command:

# screen -d -r

-d : any existing screen processes are detached
-r : screen then reattaches the detached screen session and attaches it to your current tty/ssh session.

Most useful commands while using screen:
Crtl - A, Shift - C : Create a new tty session
Crtl - A, Shift - A : Edit the name for display in session manager
Crtl - A, Crtl - " : invokes the session manager, use arrow keys
Ctrl -A, Ctrl -A : Toggle between two tty sessions

See the manpage for lots more on commands and customization.

Friday, October 24, 2008

carp configuration on openbsd/pf

Typically, when a service provider gives you your IP's (say, for a T1 service) they give you both a WAN and LAN range. This can be confusing, because typically a LAN-range would imply private (RFC1918) IP addressing, however telcos dont think of it that way. The WAN range is typically a /30, which is appropriate for a point-to-point topology. Its implied that this IP be used on the CPE, which has been traditionally a router. The LAN range is typically a /27, and these IP's could be used for services that may be exposed through the router/firewall, but it could be done the same with the WAN IP and use port redirection to anything we place in the dmz in the future. This latter design approach is the one I chose. The less IP's the smaller the attack surface and therefore less to manage. The important part to note about this configuration is that the CARP IP address and the real ip of the physical NIC do not need to be in the same subnet or related in any way. Another thought I had was that instead of using the LAN IP's as the real IP's on the public facing interfaces of the firewall, you could instead use RFC1918 addressing and it would ensure that any mistake (unlikely) in routing traffic outside of the interface would be dropped at the next hop.

The specific service I contracted was through XO, its a 10Mb pipe to the Internet with an Ethernet hand-off. They gave me a Hatteras 408-CPi. I decided that we didn't need an extra hop on our side, so I eliminated the router and plugged the XO service straight into my firewall (basically) The blue cable coming into the switch is from the Hatteras unit. The yellow cables goto the outside nic's on each firewall. The grey goto the firewall's dmz nic's. The single yellow cable on the second switch goes to a ethernet port on a router that figures out what network the traffic is truly destined for. The orange, as you probably guessed, is a crossover cable, all pfsync data is transmitted on this interface.

In this implementation I used two DL360's, one more powerful than the other, both with 2GB ram. I also used two Cisco 2960G-24TS switches.


Configuration steps for both hosts for CARP with pf

Edit /etc/sysctl.conf

Permit forward routing of IP packets
net.inet.ip.forwarding=1

Allow CARP to function
net.inet.carp.allow=1
net.inet.carp.log=1


If one interface fails, then failover to second host
net.inet.carp.preempt=1

Kernel will not respond to incoming connections to unbound network ports
net.inet.tcp.blackhole=2 # Drop incoming packets to unbound tcp ports
net.inet.udp.blackhole=1 # Drop incoming packets to unbound udp ports


Force a reboot if the kernel panics
ddb.panic=0


Individual Host Configuration for CARP with pf

REXFW01 - Primary
-------------------------
bge0: [private_ip]
bge1: 222.222.222.221 + multicast
bge2: 10.10.2.2

#> ifconfig pfsync0 syncdev bge1
#> ifconfig pfsync0 up
#> ifconfig carp0 create
#> ifconfig carp0 vhid 1 pass xxx carpdev bge0 [carp_ip] netmask 255.255.255.252
#> ifconfig carp1 create
#> ifconfig carp1 vhid 2 pass xxx carpdev bge2 10.10.2.1 netmask 255.255.255.0


Create the permanent config files

#> create /etc/hostname.pfsync0 up syncdev bge1
#> create /etc/hostname.carp0 inet [carp_ip] 255.255.255.252 [gateway] vhid 1 pass xxx carpdev bge0
#> create /etc/hostname.carp1 inet 10.10.2.1 255.255.255.0 10.10.2.255 vhid 2 pass xxx carpdev bge2


REXFW02 - Secondary
-------------------------
bge0: [private_ip]
bge1: 222.222.222.222 + multicast
bge2: 10.10.2.3

#> ifconfig pfsync0 syncdev pcn1
#> ifconfig pfsync0 up
#> ifconfig carp0 create
#> ifconfig carp0 vhid 1 pass xxx advskew 100 carpdev bge0 [carp_ip] netmask 255.255.255.252
#> ifconfig carp1 create
#> ifconfig carp1 vhid 2 pass xxx advskew 100 carpdev bge2 10.10.2.1 netmask 255.255.255.0


Create the permanent config files

#> create /etc/hostname.pfsync0 up syncdev bge1
#> create /etc/hostname.carp0 inet [carp_ip] 255.255.255.252 [gateway] vhid 1 advskew 100 pass xxx carpdev bge0
#> create /etc/hostname.carp1 inet 10.10.2.1 255.255.255.0 10.10.2.255 vhid 2 advskew 100 pass xxx carpdev bge2

-------------------------
pf.conf - for both primary and secondard firewalls

-------------------------
# $OpenBSD: pf.conf,v 1.34 2007/02/24 19:30:59 millert Exp $
#
# See pf.conf(5) and /usr/share/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.

#Interface Macros
loopback="lo0"
ext_if="bge0"
int_if="bge2"
pfsync_if="bge1"
ext_carp="carp0"
int_carp="carp1"

# Allowed incoming ICMP types
icmp_types = "{ echorep, echoreq, timex, paramprob, unreach code needfrag }"

# Private networks (RFC 1918)
priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

# Internal Networks
our_nets = "{ 10.10.2.0/24, 10.10.1.0/24 }"

#DNS Servers
dns_srv = "{ x.x.x.x, x.x.x.x }"

#table <spamd-white> persist
#set skip on lo

scrub in all

#NAT outgoing traffic
nat on $ext_if from $our_nets to any -> ($ext_carp)

#nat on $ext_if from $int_if:network to any -> ($ext_carp)
rdr pass log on $ext_if inet proto tcp from any to $ext_carp port 44 -> $int_if port 22

# Block all incoming traffic from external interface
block log all
block drop in on $ext_if all
block drop in quick from urpf-failed

# Block incoming traffic from private networks on external interface
block drop in quick on $ext_if from $priv_nets to any

# Block outgoing traffic to private networks on external interface
block drop out quick on $ext_if from any to $priv_nets

#Allow CARP and pfsync protocols
pass quick on $pfsync_if proto pfsync
pass quick proto carp

pass quick on $loopback inet proto tcp from $loopback to $loopback port smtp keep state

#Allow outgoing traffic
pass in on $int_if from $our_nets to any
pass out on $int_if from any to $our_nets
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { icmp, udp } all keep state

# Allow ICMP echos
pass in on $int_if inet proto icmp icmp-type 8 code 0 keep state
pass out on $int_if inet proto icmp icmp-type 8 code 0 keep state

#Allow DNS lookups
pass in on $ext_if proto udp from $our_nets to any port 53 keep state
pass out on $ext_if proto udp from $our_nets to any port 53 keep state

#Allow SNMP
pass quick on $int_if proto udp from $our_nets to $int_if port 161 keep state
antispoof log quick for $int_if
antispoof log quick for lo

Thursday, October 23, 2008

VMWare Server 2.0 installation error

Today I built a new Windows Server 2003 R2 (@patch-level) production server and attempted to install VMWare Server 2.0 and I ran into the following error.



I found a few discussions on the web that lead me to this patch:
http://support.microsoft.com/kb/925336

I installed it, rebooted and completed my work.

Wednesday, October 22, 2008

Using passwords that are good only once (OTP)

Using One Time Password (OTP) is a good idea these days. Luckily, its very easy to set up.

make sure /etc/skey directory exists

jack:/jack:37# sudo skeyinit -E
jack:/jack:38#skeyinit

in the output of the second command is a command that's been generated for you similar to:

otp-md5 100 bdsd523700

execute that command, adding the -n switch such that a list of passwords are generated that you can take with you.

jack:/jack:39# otp-md5 -n 50 100 bdsd523700
Reminder - Do not use this program while logged in via telnet.
Enter secret passphrase:
51: JILT YARD DARE WORM LARK CASE
52: GOOD VOTE NAN ITCH PUP DAM
53: BETH WAKE LACK MIT HANS DARE
54: MORT MAIL BANE LAP RODE YANG
[...snip...]

when you attempt to log in, use the following command structure.

ssh -l jack:skey [ip.ad.dr.ess]

a special prompt will also appear when the server recognizes that your user has a skey configuration. it will tell you which password to enter, counting down from 100.

jack/jack:45#> ssh -l jack:skey 10.200.1.254
otp-md5 97 bdsd29579
S/Key Password:

its asking for the password on line 97.

i don't quite understand the method of he counting, but it doesn't really matter much.

I got all this info from here
I wonder if I can restrict sshd to only accept skey authentication?

Tuesday, October 21, 2008

How to configure a iSCSI Volume using ZFS on opensolaris

This is just too easy. for example:

> mkfile 1000m /disk1 /disk2 /disk3
> zpool create zfs01 /disk1 /disk2 /disk3

> iscsitadm modify admin -d /zfs01/
> iscsitadm create target -z 1000m iscsizfs01

> /usr/sbin/iscsitgtd restart

I now have a 1 gig volume available over the network. Cool!
iscsi works well for applications requiring 400Mb/sec or less.

Other helpful commands:
> zpool list
> zpool status -v
> zpool upgrade #shows version info
> iscsitadm list target -v
> iscsitadm show admin

Monday, October 20, 2008

Cart of Confidential Files left on corner in SF Financial District


Today, I went to get some coffee, and I came across these carts full of sensitive files owned by a financial company which I wont name. The carts were left right out in the open on the main corner of the San Francisco Financial District, 101 California & Davis St., San Francisco, CA.

What a dream for an identity thief!

Friday, October 17, 2008

Double-Hop SSH


Sometimes I need to access a server that's behind two or more firewalls. I use SSH tunneling to accomplish this, and in this example I show port specifics for MySQL.

First, I establish a ssh session with a local tunnel to 'Server A' that's NAT'd through a firewall. 'Server A' sits in a DMZ.

Second, I establish another ssh session with a local tunnel from 'Server A' to 'Server B' that's NAT'd through another firewall. 'Server B' sits on the INSIDE network. The local port of the tunnel in the first session on 'Server A' corresponds to the referenced port on 'Server B' in the second session. A "plumbing" of sorts has been configured.

Session 1 - Client to 'Server A'
> ssh -L 44444:localhost:9999 user@serverA

Session 2 - 'Server A' to 'Server B'
> ssh -L 9999:ServerC:3306 user@serverB

As you can see, to get to 'Server C', the client application would connect to localhost:44444, sshd would bitpump traffic from TCP:44444 on the client to TCP:9999 on 'Server A'. Then through the second ssh tunnel between 'Server A' and 'Server B', sshd would bitpump traffic arriving at port TCP:9999 on 'Server A' and bitpump traffic to TCP:3306 on 'Server C' through 'Server B'.

Be responsible, make good choices. Have fun and don't kill anybody.

Wednesday, October 15, 2008

OpenIDS 1.9 released!

This project is simply awesome, I highly recommend it.
The new 1.9 version is based on OpenBSD 4.3

http://prowling.nu