In my own words...

Instant messaging (IM) increases productivity with the
advantages of instant feedback and reduced communication costs. However, the
problems IM creates in a business environment are those of liability and
responsible use. This is particularly true in the Financial Services sector and
other regulated environments. The Financial Services Authority and similar
regulatory bodies are of the opinion that IM is no different than e-mail,
therefore the same requirements for record keeping exist. I think many users of
IM (including myself) see the conversations as ephemeral, vanishing into the
ether of time and space. Not so. All IM clients have logging facilities and
there are also packages available for network administrators which enable
logging of all conversations passing through the network. If any type of
dispute arises involving information given via an IM conversation, your
organization needs to know exactly what has been said. The same can apply
internally if disputes arise within the company due to improper use. Another
issue which must be addressed is that of increased vulnerability to security
threats. Virus writers and scammers are turning their attention to users of IM;
new Trojans, worms, and phishing attacks are discovered daily.

For a business--and more specifically--its IT department,
the control of IM poses a problem. Firstly, do you have a policy on the use of IM?
If so, how do you enforce this policy and how do you ensure that you are
fulfilling the regulatory obligations imposed? If you do not have the processes
in place to log and archive records in a tamper proof and accessible format;
messaging should be stopped. But how?

Two methods which I come across frequently are port and IP
blocking.

Port blocking: This is very simple; find out what ports are
used by the IM clients and then block them on your firewall. The problem with
this is that the clients try to use many different ranges of ports, and these
tend to increase with every new release. "Well," you say, "my
firewall blocks all outgoing connections unless I specifically ask it to pass
them." That's good, but do you allow port 80 (http)? Most of today's IM
clients can now work perfectly well through port 80, and if you allow your
users to surf the net then they can probably IM too. I recently read that the
latest clients embed traffic data within an HTTP request, meaning that even
with advanced protocol analysis, they will be very difficult to stop! Smells
like guerilla tactics...

IP blocking: Again, very simple in theory, but with its own
problems. Using netstat along with googled resources, you can find the IP
addresses which an IM client will connect to. Block all outgoing connections to
this IP (or subnet) and eventually, once all servers have been found, the IM
client will be unable to go online. This looks like a better method than
blocking individual port ranges as it still leaves http open for web access. This
method still has limitations; in the amount of time it takes for the software
company in question to make a DNS or client update, a new server is added which
needs to be blocked. Because this can be hard to keep on top of, I keep the
major IM clients running on my desktop. In the rare event that one actually
manages to go online, a simple netstat can track down the new server, which can
be added to the block list. One of the major IM providers has started to have
their client program connect to IPs which also host their web services. This
means that if you block their IM client, you also lose access to these services.
Not much of a loss, until you realize that you can't run Windows Update! Looks
like we're heading for an all out Guerilla war!

Lets consider that we have blocked IM (don't forget to hunt
down and block services like http://www.e-messenger.net--if
you don't, then your 'users' will use them).

The powers that be have decided that they now want to allow one
of the messenger services. Reversing the measures taken to stop that particular
IM service won't be difficult, but you have to find a way to log and archive
communications. There are many companies offering software to log IM traffic;
examples would be IMlogic
and Akonix.
One of the previously mentioned products runs on a Windows platform, one is a
plug and play appliance. If you run on Unix/Linux/BSD then take a look in to
the dsniff set of tools.
This set of tools can log IM conversations, unencrypted password transactions,
url requests, and more.

Our company has decided that public IM services should not
be used; however for internal communication, IM can be a very useful tool,
especially when you have offices spread across a large geographical area. Running
your own internal IM server is easier than you might think. Jabberd is an
implementation of the common messaging protocol, now known as XMPP (Extensible
Messaging and Presence Protocol). There are server implementations available
for various platforms including Windows and Linux; this is also true of client
applications (I personally use PSI).
The best thing about this implementation of an internal IM server is that it's
free, and there are no complex licensing schemes regardless of how many users you
want to have on the system. Logs can be archived in files or SQL format, whichever
you feel more comfortable with. If the configuration seems too complex or you
would rather use a commercial solution, take a look at Jabber Inc.

IM in the financial services sector is a very hot topic at
the moment and promises to continue as new regulations put IT policies to the
test. Google is just starting to release its IM service, while Microsoft is
trying to push the use of MSN Messenger within a business environment--the firewall-bypassing efforts made by its
application backup this policy. New problems for IT departments to solve
will follow...

I would be interested to hear reader's comments on this
topic; do you know other methods for blocking or logging IM conversations? Let
me know?

While surfing the net I found an interesting little program
called ?GMail Drive?.  This nifty little Windows shell extension
will allow you to use your 2GB gmail account to be used as storage.  Files are basically added to your account in
the form of an email with the file attached; you can access the files as you
would with any other network drive, it integrates the storage with windows
explorer.  The web address is http://www.viksoe.dk/code/gmail.htm

Actually it reminded me of a similar project I saw a while back
called GMailFS, this allowed you to mount your gmail account as a linux filesystem.  After a quick google search I found this
projects homepage
and it seems that it is still being actively maintained.

I?m sure neither are very secure, reliable or practical;
still they are a novel use of the free storage being offered to users.

Reading through this weeks edition of Computer
Weekly I
notice that there are frequent references to the use of Linux in the
enterprise. Kevin Hughes, a nautical equipment
manufacturer has moved over to 64-bit Linux running Oracle on HP
Itanium machines. I think Linux offers a considerable advantage
over Windows when it comes to running on a 64-bit base (the 64-bit
versions of Windows
that I have tried didn?t seem too stable). I?m not quite sure why the
article said that they are leading the way,
our company (of a similar size) has been running Oracle based
applications on a
64-bit hardware and software base for quite some time. I guess it just
fills some space in the
magazine! Other mentions included Stirling university who have improved performance
three-fold and lowered costs. How? Oh that?s interesting, by moving over to HP
Itanium based servers running Linux; I?m not making accusations here but it?s
interesting that both of these articles were written by the same author. I wonder if he also works for HP, no surely
not... Last but not least, I see that Dell are now offering a desktop system
with NO Windows pre-installation. This
saves money for enterprises using Linux on the desktop as they would usually
have to buy a PC pre-loaded with Windows and then wipe it out, which is a bit
of a waste of a llicence.

As our company runs all of our core services and systems on
a Linux base I find it very interesting to see how other companies are
approaching it?s use. It seems even to companies
who would traditionally run with Windows; Linux is offering a real
alternative
when it comes to high performance 64-bit processing. I?m rather
surprised that people are choosing
to go with the Itanium based systems, we have both Itanium and AMD
Opteron
64-bit systems. Both run SUSE Enterprise
server with Oracle 10g. The Opteron
systems have out performed the Itanium by such large margins that the
Itaniums
have actually been put on the shelf as it were. The Opteron based
systems were also much cheaper than the Itaniums (Truly a fraction of
the price). I guess the big three providers (IBM, HP,
SGI) are hoping that people don?t notice the reduced cost and increased
performance of the Opteron systems so that they can continue to sell
their
overpriced, underperforming Itanium based hardware!

Wireless networking is fast becoming a service expected by
most enterprises. Being able to undock a laptop, walk around the office (for
meetings, impromptu brainstorms, etc.) and still have instant access to files
and data sources is seen as vital. For an IT department, the implementation of
wireless networking is relatively simple and inexpensive. The transfer speed
offered by wireless hardware is constantly increasing, making it a viable alternative
to wired LAN in some situations such as small offices with solid floors and
ceilings.

This all sound great, but there has to be a catch doesn?t
there? Well yes, the catch is security.

We go to great lengths to protect our wired networks from the
outside world. What would you think if you started working for a company and
found that they had no firewall protecting their internet facing services? Well,
the same should apply to wireless services as these face the outside world and
are more vulnerable than you may think. A report put together by RSA Security in 2004 gives some horrific figures on the use of unencrypted wireless networks;
this was as high as 72% in Milan! A newer report
shows that the situation is still not under control--26% of access points in London were found to have
the factory default settings. I decided to take my own survey and drove around
a local town for 20 minutes. I picked up 372 individual access points! A
massive 39% of these were open, 47% WEP encrypted, and 14% WPA protected. Most
of these were obviously home broadband networks, however a notable number were
clearly advertising their location, including some businesses.

There are, of course, simple measures which can be taken to
protect your network. 128-bit WEP encryption is available on almost all wifi
equipment. This is as simple as generating a suitable encryption key (there are
many utilities on the internet like this one)
and then entering it in your AP's web interface. This will be enough to stop
the guy in a coffee shop next-door from connecting to the Internet via your
network (rather than paying for the local hotspot access--who doesn?t like a
free lunch?). That?s all very well but will it protect your network from more
shady characters? No is the simple answer; WEP encryption is easily crackable for
those in the know. Hackers will be less interested in simply gaining free Internet
access; they could have much more sinister intentions. First, don't advertise
your network to the world. Hide your network SSID (some hardware offers this
feature), and failing that you should at least use a random SSID rather than
?MyCompany.? I know that sounds silly, but you would be amazed how often this
is the case.

If possible, use WPA encryption. While this is still not
impregnable, it is a vast improvement over WEP, and most new equipment will
allow the use of WPA. Another precaution you can take is to separate your
wireless and wired networks on to different subnets, placing a firewall between
them (much as you would with your Internet connection).

One thing which all network administrators should do on a
regular basis is check the strength of their own networks. Scan your firewall
and systems for the latest vulnerabilities or exploits, because you can be sure
that someone else is doing this for you! The same applies for your wireless
network--do you know how easy or difficult someone would find it to penetrate? A
set of tools I have found very useful are those put together by the security group
remote-exploit.org.
You can boot from the Auditor LiveCD without the need for installation. You
don?t need a dedicated notebook--just pick one with compatible hardware, pop in
the CD, and you're off (I use my IBM ThinkPad). It seems this set of tools is
so complete that even the FBI uses it!

Explaining the theory behind testing WEP encryption is
beyond the scope of this blog; however, here are several references which will
explain things. Note that most of them refer to the Auditor LiveCD previously
mentioned:

• 
  This article from Tom?s Networking describes how FBI agents demonstrated WEP-cracking
  techniques using the Auditor distribution. There are also some suggestions for
  strengthening your wireless configuration.

• 
  This column from SecurityFocus goes more in-depth on the subject of WEP
  cracking with some interesting background information on the tools used in the
  cracking process.

• Finally, this video shows how shockingly easy it actually is to hack into a
  WEP-encrypted network. I followed this tutorial and audited my own home
  network; needless to say, I have now moved over to WPA encryption!

If you don't already follow security-related press and learn
about so called 'underground' techniques being used by hackers today, I can
only urge you to do so. The only way to keep your networks secure is to fully
understand the threats being faced and techniques used.

I have been doing a little research on the subject of WPA
wireless protection. A good description
of WPA along with its relative Pros and Cons can be found here, courtesy of Netgear.

As confirmed in this article on Wi-Fi Net News,
WPA has been broken. This refers to the preshared-key
implementation of WPA (WPA-PSK), however it doesn?t seem that certificate based
WPA (802.1x RADIUS authentication) is vulnerable to this attack. Having not used RADIUS authentication
previously, I was interested to see how much work would be required to get this
up and running. I stumbled upon a great
three part article from Linux Journal. The link provided is for the third instalment,
I would suggest reading this part first, just to get an idea of what is
involved and how it all works.

RADIUS authentication is an interesting prospect, with the
possibility of using it for other purposes such as PPTP (VPN) connection auth
and Windows login. The
server can be set
up so that it logs to an SQL database, making reporting quite
simple. It would be interesting to hear from anyone who has this
type of system in place.

High-Speed Downlink Packet Access (HSDPA) is approaching launch
in Europe. 
HSDPA is a third generation (3G) high-speed data service, with a maximum
bandwidth of 14Mbps!  O2,
the UK based telecoms company
have announced that they will be launching the service for the Isle of Man on the 1st of November.  Another high-speed technology which is just
starting to emerge is WiMax.  This wireless broadband service is now being
offered in the South East of England?currently offering services up to 10Mbps.  One potential problem for WiMax is the limited
amount of licensed radio bandwidth available. 
It is possible for the service to run on unlicensed public frequencies,
but this raises quality of service issues. 
HSDPA runs on current cellular infrastructure which bypasses this issue
and should make rollout faster and less expensive.  There is much debate over which of these two
technologies will gain the upper hand, I guess only time can really tell.  Still, both technologies are offering
exciting new prospects in all areas from mobile business solutions to in-car
entertainment.

Virtual Private Networks (VPNs) seem to be
a hot topic lately--a week doesn't go by without a new article or white paper being
released on the subject. For many business users, having instant access to data
while on the move is now seen as a necessity rather than a luxury. Gone are the
days of slow and troublesome dial-up connections; we're now in the age of
broadband! These days high-speed internet access is cheap and offers speeds
which could only have been dreamt of ten years ago; Wi-Fi hotspots offer access
from most coffee shops, city centers and airports! Another form of VPN is that
which connects two private networks, using public networks as a bridge. A
gateway on each of the private networks faces the Internet, data is then transferred
between the two gateways via this low-cost public infrastructure. This allows
branch offices to effectively share data and work together without the
horrendous costs involved in hiring private lines.

The advantages of allowing data access via
public networks are clear: high-speed and low cost. Where's the catch? Well, as
per usual the issue is that of security. It's all very well utilizing public
networks, but they are just that--public, and since anyone could be viewing the
data you transmit, we have to assume that they are. Let's take a look at two
protocols developed to address security in this area.

Point-to-Point-Tunnelling
Protocol (PPTP) was developed by Microsoft to enable remote users to securely
access corporate networks. It was first introduced in Windows NT 4 and the
source code was made available so that other third parties could develop
compatible software. Here's a full description of PPTP,
the key point being "PPTP encapsulates the
encrypted and compressed PPP packets into IP datagrams for transmission over
the Internet." One thing
which makes PPTP a good choice for remote or roaming users is that all versions
of Windows (NT4 to XP) have an inbuilt client program, meaning there is no need
for additional software installation. Windows Server can be used; however, for those
not already using Windows Server, a better solution may be Poptop. Poptop is an open source PPTP server which
can be hosted on a Linux platform, Cyberguard
even use Poptop in their embedded VPN solutions.

IP Security (IPSec)
is a standard for authenticating and encrypting IP packets; working on the
network layer to create a secure tunnel between two nodes, via a public
network. The two main parts of the IPSec standard are the Encapsulating
Security Payload (ESP) protocol and Internet Key
Exchange (IKE) protocol. ESP takes care of data encryption and integrity, while
IKE uses public key or pre-shared secret techniques to authenticate each host
and set up a secure session. Giants such as Microsoft
and Cisco
have adopted IPSec and support its use.

In a small to medium enterprise, cost is
normally a big consideration. I personally use OpenBSD to provide for our
company's VPN needs--OpenBSD takes a paranoid approach with proactive security
and integrated cryptography, and best of all, it's free! All of the tools
needed for creating point-to-point VPN connections are included as default; Poptop
is also available in the OpenBSD ports (selection of linux/unix packages ported
to the BSD platform). The system manual pages give full
instructions on setting up your VPN; this can look a little in-depth and
over complex but once you have an understanding of what's happening, it's
really quite simple. The inbuilt firewall, Packet Filter, is a very simple but
powerful, making OpenBSD a good multipurpose platform; DHCP, DNS, FTP, VPN,
PPTP can all be run with proven reliability and security. The configuration of
Poptop is a little more difficult; it took me 3-4 days of reading mailing list
archives and manuals to actually get it working, but now that I know how, it
doesn't take long to set up a new server.

As you can see from a quick Google search,
there are many companies offering different VPN solutions, all based around the
same underlying technology. Most of them don't come cheap and that's not even
taking in to account consultancy fees, etc. I hope I've shown here that
implementing a secure VPN solution (whether it be for remote/roaming users or
interoffice communication) doesn't have to be expensive or particularly
difficult.

If there's any interest in the topic, I
would consider writing a tutorial on setting up an OpenBSD network gateway with
VPN and PPTP. Please post your comments and let me know?

I?m sure every systems administrator has their own set of
tools which they use daily and just couldn?t get by without.  I thought I would spend a little time to let
people know what I keep in my toolbox, the programs and utilities which I guess
most administrators in a Unix/Linux environment would find useful.

#1 Putty
- The single most useful and most used tool in my box.  If I want to do anything on one of our
servers then I need putty, due to the lack of an SSH client in Windows of
course (and running a Linux desktop just isn?t practical).  It?s free and easy to use, what more can you
ask for!

#2 WinSCP
- Again this one is a must, it makes transferring files to and from a Unix/Linux
server a doodle.  The clutter is minimal,
you want to get the files, edit them and put them back.  Norton Commander or Explorer-like interfaces
can be chosen from, drag and drop really saves some time.

#3 UltraEdit-32
- The best text editor I have used to date. 
Throw away notepad, this will allow you to work with unix line
terminators, highlight code syntax and it automatically creates a .bak file
once you save changes (can be handy).

These are my top three tools, all in constant use!

A tool which I find absolutely vital when setting up or
testing any new system is VMware.
 For those of you who have not used
VMware for systems testing or development, I suggest that you give it a
go.  While the GSX and ESX application
server platforms are powerful tools, we are interested in VMware
Workstation.  In a nutshell VM
Workstation allows you to run multiple virtual PC?s on your desktop, full networking
support is included allowing you to play through test scenarios quickly taking
snapshots before making major changes, allowing you to roll back without
re-installation.  You can also cone
machines, if you need to test interaction between two Windows XP machines,
simply install once, clone and then change the machine name / IP details.  Many more features exist and the best way to
discover them is to have a play with the 30-day evaluation.  You will probably notice later on that I test
most of my projects and new implementations in VMware; realistically you need
to allow 1GB of RAM and ~30GB+ disk space, but with hardware being cheap these
days it?s well worth the expense.

A tool which I find absolutely vital when setting up or
testing any new system is VMware.
 For those of you who have not used
VMware for systems testing or development, I suggest that you give it a
go.  While the GSX and ESX application
server platforms are powerful tools, we are interested in VMware
Workstation.  In a nutshell VM
Workstation allows you to run multiple virtual PC?s on your desktop, full networking
support is included allowing you to play through test scenarios quickly taking
snapshots before making major changes, allowing you to roll back without
re-installation.  You can also cone
machines, if you need to test interaction between two Windows XP machines,
simply install once, clone and then change the machine name / IP details.  Many more features exist and the best way to
discover them is to have a play with the 30-day evaluation.  You will probably notice later on that I test
most of my projects and new implementations in VMware; realistically you need
to allow 1GB of RAM and around 30GB disk space, but with hardware being cheap these
days it?s well worth the expense.

I have been experiencing some problems with our Video Conferencing
(VC) equipment. Making calls from unit to unit within the organisation is no
problem--our sites are all inter-linked by IPSec tunnels so all traffic is
internal. The problem arises when trying to make a call from one site to
another, via external IP addresses. The call is made on unit A, and unit B
rings. When the call is picked up on unit B, the session is not created, no
audio/video link is created, and unit A does not recognise that the call has
been accepted. I looked into my firewall configuration, and I had allowed all
of the port ranges mentioned in the manuals. I also redirected those ports to
the conferencing unit so that incoming attempts would be delivered directly.

This all seemed ok, so I also checked the firewall logs while
attempting to make a call; nothing was being blocked. While this wouldn't have
been a problem 3 weeks ago (because all of the VC traffic was internal), people
now want to receive VC calls from external companies. Doh!

After a lot of googling and reading mailing list archives, I
found references to issues with the H.323 set of protocols and firewalls. It
seems this is also the protocol set used by Microsoft Netmeeting, so there was
quite a bit of information on the subject. I checked the manuals of our VC
units and, sure enough, they do use H.323--great :/  There is a sliver lining; as I mentioned
before, this is a very popular standard. It actually means that VC systems made
by different manufacturers can still speak to each other. I called one of our
Sony units from Netmeeting on my laptop and it worked quite well (type conf.exe
in your 'Run' box).

A bit more googling and I found two open source solutions;
both are basically proxies which sit between both end points and deal with
incoming / outgoing connectivity. OpenGatekeeper H.323 Proxy is
one of these, NMproxy is
the other. Because of it's simplicity and BSD compatibility, I have chosen to
take a closer look at nmproxy.

I don't want to modify our existing gateway/firewall
machines with un-tested software, so I'll create a lab environment using VMware Workstation as I mentioned in my
previous blog.

The Plan:

 Set up a test environment to emulate a Video Conference call
between two firewalled networks.

• Build
  two firewalls (OpenBSD)
• Compile
  and configure nmproxy
• Build
  two internal clients (Windows XP)
• Netmeeting
  + Webcams (one on each client) can be used for testing the H.323 proxy

Thanks to the 'clone' feature on VMware, I don't actually
need to build 4 separate machines from scratch. I'll install OpenBSD (to show
people how simple this OS is to install and configure), compile nmproxy, then
clone it to create a replica and simply edit the machine configuration (IP
details, hostname etc). As I use VMware frequently for testing, I already have
a 'virgin' Windows XP image ready to use/clone; I assume everyone reading knows
how to install Windows.

I know this may sound a bit drawn out, but if you want to be
serious about security then you need to test new configurations in a secure
environment, not just give it a go on live systems and hope for the best!

Tune in again on Wednesday and we'll install OpenBSD...

Let's do it:
Building an OpenBSD firewall

Ok, first step is to build one OpenBSD firewall. I promised
before that I would write a tutorial on creating an OpenBSD gateway/VPN server
if there was any interest. Since there were a few people interested in the
idea, this can be counted as the initial instalment. While the purpose of this
article is not to set up a VPN gateway, it will show you how to install OpenBSD
and therefore, this can be considered a general reference for initial OpenBSD
installation. I'll give as much detail as I think is needed, if you haven't
installed this before, it can be quite daunting. If there's anything which is
unclear and isn't mentioned in the official FAQ, let me know and
I'll cover the area again later on.

I'm installing from a CD of version 3.7; 3.8 will be out on
the 1st November but the install procedure won't change.

Setting up the VMware virtual machine:

In VMware Workstation, start the new machine wizard with File > New > Virtual Machine. Select
the typical configuration, Guest Operating System is Other and version is also Other.
Give the machine a name--'OpenBSD A' in my case--then set the location for
storing the virtual machine files (any place you have space). For network type
I'm selecting 'Do not use a network connection'; I'll explain why later. The
default disk size of 4GB will be ok; tick the box 'Split disk into 2GB files' as this will stop
any problems with large files on a FAT filesystem (in case you want to copy the
image to a FAT formatted disk at some point). As I noted previously, VMware
will require a lot of disk space and quite a bit of RAM; this test lab will use
about 16GB of disk space and 320MB of RAM while running, but with a 250GB SATA
hard disk costing me ?65 (approx. $115) and 1GB of RAM ?50 (approx. $90), this
doesn't really bother me. Click finish and you will be presented with your VM
overview.

As you can see, this defaults to allocate 256MB of RAM, and that's
way too much. We can run OpenBSD on 32MB of RAM without problems. If you click
on 'Edit virtual machine settings' then you can change the memory allocation to
32MB. We can also now add our network support, the reason I didn't set this up
earlier is that we want two network adaptors on different physical networks
(for all intents and purposes this represents the 'Internet' and 'Internal'
networks). Still in the virtual machine settings, click on 'Add' and the add
hardware wizard will start. Select Ethernet
Adaptor, then Custom: VMnet5.

Do this again to add the second adaptor, but this time
select VMnet6.

Your virtual machine will now look like this:

Pop in your CD, power on the virtual machine, and we're
ready to go.

At the boot> prompt
just hit enter.

When prompted, just type
I for Install, accept the default terminal type (just hit enter). Select
your keyboard map, or stick with the default, then type yes when asked if you want to proceed with the install. We now come
to setting up the hard disk, not as straightforward as a Windows installation,
but easy once you know how. The default disk will be shown as wd0; accept this
as the root disk. When asked if you want to use the whole disk for OpenBSD, say
yes. We will now be dropped in to
the partition editor where we can decide how to allocate the disk space.

Simple commands:

• p ?
  display or 'print' the current partition setup
• d 'x'?
  delete partition 'x'
• a 'x'
  ? add partition 'x'

Take a look at the current partitions:

> p

You will see two partitions, a and c. Partition c always
stays, it simply shows the physical disk. Remove partition a and then print to
check that it's gone:

> d a

> p

Now we need to plan our partitions, there is a 4GB disk and
we don't plan on installing much more than the base install. I would say to use
something like:

/           250MB
Swap   64MB (twice the
RAM)
/tmp     1000MB
/usr       1500MB
(allow for source and user installed programs)
/var      1250MB (logs
etc)

So, to create the root partition:

> a a

offset: [63]

size: [8385867] 250M

Rounding to nearest
cylinder: 512001

FS type: [4.2BSD]

mount point: [none] /

The offset and FS type should be left as default (just hit
enter). Next the swap partition (swap is always b), don't worry about the FS
Type, it will always offer swap as the default for partition b. You can't use c as this is the disk, so from b move on to d. Once you have made all of your partitions, view them ( > p ) and they should look like
this:

 

Confirm by typing:

> q

Write new label?: [y]
yes

When prompted to confirm the mount points simply type done and you will pass to the next
stage. OpenBSD will show you the partitions which you have chosen to create and
as you whether you want to proceed, of course the answer is yes. You will now see the partitions
being created and formatted.

When asked for the system hostname, I have chosen to call
this GatewayA, accept the default of
configuring the network now (this gets it out of the way). We have adaptors le1 and le2; lets go with the default and configure le1 first:

As you can see, I have set le1 to be out virtual internet network and le2 will represent our internal network. The nameserver and default
route would normally be those provided by your ISP or those of your internet
router. Don't edit hosts with ed and don't do any manual configuration. Set the
root passwords and you will be asked where to install from; simply type c for (c)drom and then keep the default
options for the device name and file path.

The package selection screen is shown next, by default all
of the essential package groups are selected, all those with 'x' at the
beginning relate to x-windows, as we don't want these installed, we simply type
done to continue. You will confirm
that you are ready to install and then the packages will be copied from the
disk. A second chance to install sets will be given; simply hit enter to accept
the default (done}. Do the same for
any following questions, except whether you expect to run x-windows--the answer
to that one is no.

Set your time zone (in my case Europe/London).

That's it, done. You now have to remove the CD, reboot and a
fresh OpenBSD installation has been completed! That wasn't too bad was it!

In next week's instalment we will finish the gateway
configuration, compile / install nmproxy and then clone the gateway to create GatewayB.

An article in Computer Weekly mentioned that Bristol council will be
migrating 5500 desktops to Sun?s
StarOffice suite.  Even taking in to
account the cost of converting existing documents and two half-day courses for
users, they stand to make massive savings over Microsoft Office. 

StarOffice is developed by Sun, here is their sales
description ?Enhanced usability, compatibility, interoperability, new XML File
Format, and more developer features and tools all combine to make StarOffice 8
the best office suite value by far.?  The
cost is $69.99, a heck of a lot cheaper then Microsoft, but how about something
that?s free?  OpenOffice is the open
source suite which StarOffice is based on, take a look here to see what you
don?t get with OpenOffice (nothing that I would miss).

OpenOffice2 is now available
for download! 

Give it a go?

Ok, so we now have an OpenBSD gateway, let's make it useful.

I took the nmproxy source code and created an ISO with it (I used UltraISO; you may have your own preferred method). It's then possible to mount the ISO, making it appear as a drive in your VM.

You can then mount the drive in OpenBSD:

Create a directory and copy the source code:

# mkdir /usr/src/nmproxy
# cp ?R /mnt/cd/nmproxy /usr/src/

Now compile:

# make ?f ./Makefile.OpenBSD

If you don't get any nasty errors, install:

# ./nmproxy_install

There you go, now we just need to set up Packet Filter, edit a few configuration files, and we are ready to clone. I will assume from now on that you are familiar with Linux and the vi editor. If not, then look here.

First let's allow IP forwarding by editing /etc/sysctl.conf and removing the # comment in front of net.inet.ip.forwarding=1. Save the file and now open up /etc/rc.conf search for pf=NO and change it to pf=YES.

You can pretty much follow the default setup for PF; the following lines need to be added for nmproxy:

# Redirect port 1720

rdr proto tcp from any to any port 1720 -> 127.0.0.1 port 1720# Nmproxy specific rules. Note that the port number ranges look strange# because of the way ranges are specified.pass in proto tcp from any to 127.0.0.1 port 1720 flags S/SA keep statepass in proto tcp from any to any port 10199><10210 flags S/SA keep statepass in proto udp from any to any port 10199><10260

Nothing too taxing there. Give the VM a reboot, and the changes made should take effect. We can now check that nmproxy is running and the firewall is letting connections through:

# telnet 168.1.1.1 1720

All is well, and the connection succeeded.

Now we need to clone the machine. Shut down and we will start.

Select the VM menu and then Clone? to start the cloning wizard.

Most options can be left as default; when you get to the following screen, you must select Create a Full Clone:

The new clone can be called OpenBSD B; locate it wherever you like. You should now have something like this:

<!--[if !vml]--><!--[endif]-->Start up the new VM and we will change the configuration to make this system ready. I have decided to call my second firewall GatewayB.testdomain.com, the internal network address is 10.2.1.1, and the external one is 168.1.1.2. Ideally, we would re-generate the ssh keys, but I don't think this is necessary for a test system. 

Files which need to be edited are:

/etc/hosts                     Hostnames
/etc/hostname.le1        IP configuration of internal interface
/etc/hostname.le2        IP configuration of external interface
/etc/nmproxy.conf       NMproxy configuration
/etc/pf.conf                  Firewall configuration (change IP details of networks)
/etc/myname                The system hostname
/etc/mygate                  Default route/gateway

All of these files are self explanatory--nothing complex at all. After we have edited these files, a quick reboot will put everything into action.

Check that the interfaces have taken the new IP details:

# ifconfig ?a 

If your changes don't seem to have taken effect, check that you saved the files after editing!

If we start up the original VM, we should now be able to telnet into port 1720 of that machine to verify that we have communication between the two:

That's all for now, next week we will finish this off by creating a team consisting of our two firewalls and two Windows XP VM's. We will also look at some of VMware's more advanced networking features and finally test nmproxy!

Over the last few year I have used Linux as my desktop
operating system on and off.  This has
normally been in very short spells, I never found a distribution which I liked
enough to keep me from going back to Windows. 
I tried SuSe
(Their Enterprise Linux offering is great), I always seemed to get hung up with library files not
being found etc.  Fedora (previously RedHat) was pretty
good, that was back at version 2; I recently tried release 4 and had no end of
problems trying to configure my WiFi card, not so good.  A few days ago a colleague of mine showed me Ubuntu, he couldn?t say a bad word about it
so I have installed it myself.  Installation
was fast and clean, the base system (which still includes major packages like OpenOffice,
Gimp etc) installs from one CD?additional software can be downloaded (including dependencies)
using the included package manager. 
Despite the fact that my WiFi card is not natively supported by Linux,
an included tool allowed me to easily install the Windows driver (with ndiswrapper).

So far I haven?t got a bad word to say about it, let?s see
how long that lasts!

Firefox is celebrating it?s
first birthday! That?s right, on the 9th of November the groundbreaking Firefox web-browser was one
year old with over 106 million downloads.
It?s estimated that Firefox
currently serves 9% or surfers, with 85% being held by Internet Explorer. That sounds small, but when you consider that
all other browsers combined make up the remaining 6% (which would Netscape etc),
plus the fact that Internet Explorer comes pre-installed with Windows, it?s not
a bad feat in 12 months. I have used Firefox since its release
and could never go back to Internet Explorer.
Being a developer in the past I would always prefer Firefox for testing as it
followed W3C standards much more closely that
Microsoft?s offering. If you haven?t tried
it yet then give it a go?It?s free so there?s nothing to lose!

Continuing from last week, we now have two OpenBSD gateways
which are able to talk to each other. In this final instalment, we will use the
team feature of VMware to group each Gateway with a Windows XP machine, and then
try to initiate a call from one network to the other.

I am assuming that you have already installed your Windows
XP machines and have given them IP addresses 10.2.1.2 and 10.1.1.2 with the
gateway/DNS addresses as 10.2.1.1 and 10.1.1.1 respectively.

In VMware, start the new team wizard File > New >
Team...

Add the Virtual Machines as above, then move on and create three LAN segments:

Now configure the Virtual Machines to connect to those LAN
segments as follows:

Finish the wizard and we will now look at a more interesting
feature. Open the team Settings and continue to the LAN Segments tab. We
can see our three LAN segments earlier defined: LAN1 is our 'Internet' segment,
so we can rename it. We can also have this segment emulate a 1.5-Mb leased line
with 1% packet loss (now you are seeing that this can be a great tool for
testing and emulating various network conditions). The other two segments can
be renamed Internal LAN1 and 2 or left as they are.

The group can now be started. This is where you will notice
a slowdown if your host machine does not have a good helping of RAM. Our setup
here is using 384 MB of RAM (64x2 + 128x2); you will have probably noticed in
the preferences that you don't need to have this all in physical RAM. You can
have some swapped to disk; however, this is very slow. I would recommend
placing all of this in physical RAM.

The first thing to do once all machines are up is to ping
the opposite counterpart. From Windows XP A ping Windows XP B and
vice versa. This should work without problems (turn off the Windows firewall;
the BSD gateway provides the firewall), but if you do have trouble, check the
firewall rules in /etc/pf.conf on
each gateway.

The nmproxy configuration file is /etc/nmproxy.conf. Configuration
is not difficult--we simply need to specify the local network, and map the
default forward rule (full details here).

I used two USB Webcams--one connected to each XP machine. Connecting
the camera to your VM is simple: Give the desired machine focus, then plug the
USB camera into your host. VMware should conne ct automatically to the USB
device and bridge it to the VM. If not, you can go to VM > Removable
Devices > USB Devices > (your webcam) to connect it manually.

Within Windows XP we now need to start Netmeeting. Most
people don't realise that this is still installed by default, as there are no
links created. Type conf.exe in your Run dialogue and
there it is!

Once this is running we can try to initiate a call from one
machine to the other. Type the IP address of the second machine in your call
box and hit the telephone button. The counterpart Netmeeting instance on the
second machine should ring!!!

This is where things become a little disappointing; the
second machine did receive the call, however, when pickup was selected, the
call did not connect. The first machine didn't even recognise that the call was
accepted. I checked all of the settings in both pf.conf and nmproxy.conf
with no obvious errors. I then also use the pflog device and tcpdump
to see if any connections were being blocked by the firewall, but unfortunately
this was not the case. It seems that nmproxy collects the connections but does
not then initiate the audio/video streams. I emailed the author who was not
helpful in the slightest. After posting questions on a few popular networking
forums, it seemed that nobody had successfully managed to get this working.
After that I decided that it's not worth wasting more time trying to flog a
dead donkey, so I'm looking at alternative gatekeeper solutions.

I hope this series of posts has been useful to people. We
haven't found a great H.323 video proxy, but we have gone over basic
installation and configuration of OpenBSD as well as introducing the use of
VMware to speed up testing and troubleshooting. In total, the practical
implementation of this test environment took me about 3-4 hours. This would
have been a little less if I had used a pre-prepared generic install of OpenBSD
to start from (as I did with the XP workstation VMs). I personally think this
is much more sensible than trying out untested code in a live environment; it's
also much faster than building a physical test environment due to the cloning
feature.

If any readers manage to get nmproxy running, or have done
so in the past, please let me know!

Intrusion detection is a vital part of any firewall, it?s
all very well to block traffic, but how do you know what is being blocked and
what is going through on your open service ports (SMTP, IMAP, DNS etc)?  Snort is
the most popular Intrusion Detection system around.  It?s offered as an open source project, with
a subscription available offering enhanced rules libraries.  Snort is highly configurable, with various
plug-ins for download.  Quite a few
commercial firewalls run snort under a custom web interface (look
here)!  The documentation is good and
I have compiled this on both OpenBSD and SuSe Enterprise 9 without problems.  Is anyone else using Snort, how are you
finding it?

I received
my Dell M170 today, this is a replacement for the Acer Ferrari 3400 which
despite being very nicely designed, was nothing but trouble.  Dell laptops come highly recommended, this
being their top spec machine, it should make multi-tasking much faster.  With VMware in mind 2GB of DDR2 RAM and a
100GB/7200rpm Hard Disk were chosen, I have yet to test this (I?m still going
through the slow process of installing applications and transferring data) but
I am expecting a considerable improvement over my current setup.  My only gripe so far is the ?tacky? design,
but then machines with this power are aimed at gamers?Luckily the coloured LED?s
in the speakers and fan ports can be turned off!  Is anyone else running VMware on a
notebook?  What kind of setup are you
using?

With
increasing numbers of servers in various locations around the world, monitoring
things such as disk space, load, and network status can be a bit of a headache.
This is especially true in a non-windows server environment. There are quite a
few offerings which will (or claim to) solve problems of control faced by
administrators. The obvious options come licensed with your servers, either IBM
Director or HP Insight
Manager. As most of our servers are from IBM, I'll take a brief look at
what Director offers: 

?
An easy-to-use, integrated suite of tools with consistent look-and-feel and
single point of management simplifies IT tasks

?
Automated, proactive capabilities that help reduce IT costs and maximize system
availability

?
Streamlined, intuitive user interface to get started faster and accomplish more
in a shorter period of time

?
Open, standards-based design and broad platform and operating support enable
customers to manage heterogeneous environments from a central point

?
Can be extended to provide more choice of tools from the same user interface

That's the marketing blurb, but what does it mean in
English? Well I installed IBM
Director, which was provided on CD's with some of our servers. Here, I came
across the first problem, and I was quite surprised by it! The agent (this goes
on the servers to be monitored) is included on the CD in a variety of formats
for different types of servers. I tried to use the provided installation
scripts to install the agent packages (system monitoring, service monitoring,
RAID configuration, etc.)--shock, horror--they failed!

The problem was quite obvious: In the installation scripts,
package files were referenced with caps, for example, DirectorAgentPackage.rpm, but the actual name of that file was directoragentpackage.rpm. Linux/Unix
file systems are case sensitive; therefore, the files could not be found. I
thought it quite surprising that a large corporation like IBM would make such
an obvious error, which would have been found if they decided to test the
scripts at least once (which I would do, personally, if I were planning to make
thousands of CDs to include with my products). Anyway, to overcome this, I
simply copied all of the files to the hard disk and then edited the installation
using the correct file names. It installed without any problems after that. I
came across the same problem with the server package installation--the same fix
required.

My second issue came while installing the client application
on my computer, after installation, and on my first attempt to log in to the
server. I was informed that my client version did not match the server version.
I had to download the correct client version from their Website, which again
left me wondering who on earth would distribute incompatible software versions
together!

With these problems overcome, I finally got to start looking
at the software. The RAID manager worked very well, but then the IBM RAID
manager can be used standalone without IBM Director. To be honest I wasn't very
impressed with anything else, it was a pretty drawn out and slow process just
to set monitoring of disk space. I didn't find the interface very intuitive and
very quickly felt that I didn't really want to deal with this on a day-to-day
basis.

Next week I'll take a look at Nagios; this is an open-source solution
offering server monitoring and alerting.

I came across a great project by the UK Honeynet Project.  For those who have not heard of  ?honeynets? yet, to put it simply they are
small, often virtual networks which are created purely for the purpose of diverting
attention from real networks and learning about techniques/exploits in the process.  A prime concern is making sure that once an
intruder has penetrated your honeynet, they are not able to get back out and
use your resources for activities such as denial of service and spamming.  The Honeynet
Project provides Honeywall,
this suite of tools provide a solid basis for any honeynet project.  Getting back to the point, I found an
interesting guide which describes the creation of a fully operational honeynet
on a 2GB USB key!  Here?s the link, I?m working on one at
the moment!

We are currently looking at setting up a VOIP PBX to allow IP dial-in conference calls. One solution looks to be Asterisk--An open source PBX offering just about every feature you will find in commercial solutions. Asterisk@home is a project which aims to make a basic install easier, this project provides a CD which will deploy a fully functional Asterisk PBX with the underlying OS and a fully operational web interface to ease configuration and administration.

You may wonder why go to this effort rather than using a simple program like Skype? Unfortunately it?s a case of compliance, followed by security?Add to this the fact that call quality with Skype degrades quickly when there are more than three callers, it?s not much good for commercial use.

Right, last week we looked at IBM Director, and I wasn't very impressed. Let's now take a look at Nagios and see if it's any better. Nagios is an open source host, network, and service-monitoring system, used by many large corporations and even some government agencies! The very honestly named propaganda page will fill you in on where and how Nagios is being used.

Nagios is a very flexible system with masses of potential; here is the official word on what it can do for you:

• Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)
• Monitoring of host resources (processor load, disk and memory usage, running processes, log files, etc.)
• Monitoring of environmental factors such as temperature
• Simple plugin design that allows users to easily develop their own host and service checks
• Ability to define network host hierarchy, allowing detection of and distinction between hosts that are down and those that are unreachable
• Contact notifications when service or host problems occur and get resolved (via email, pager, or other user-defined method)
• Optional escalation of host and service notifications to different contact groups
• Ability to define event handlers to be run during service or host events for proactive problem resolution
• Support for implementing redundant and distributed monitoring servers
• External command interface that allows on-the-fly modifications to be made to the monitoring and notification behaviour through the use of event handlers, the web interface, and third-party applications
• Retention of host and service status across program restarts
• Scheduled downtime for suppressing host and service notifications during periods of planned outages
• Ability to acknowledge problems via the web interface
• Web interface for viewing current network status, notification and problem history, log file, etc.
• Simple authorization scheme that allows you restrict what users can see and do from the web interface

Monitoring of host resources and network services is exactly what I'm looking for--add instant notification, and we are really cooking. Knowing that a problem exists 'before' the helpdesk phones go crazy with users complaining is a major benefit. Most of the time, issues can be resolved without many users noticing at all!

The support is good with Online Documentation, FAQ's, Mailing Lists, and Forums.

So, installation and configuration--how was it? I currently have one server with Nagios installed, which is going to be the main monitoring station, but it's currently only monitoring itself. We use SuSe Linux Enterprise Server, and Nagios is actually in the applications repository, so it can be installed with the YAST management tool. However, I took preference to compiling and installing Nagios from source, meaning I will have a better understanding of what's actually going on. The install was uneventful, everything working as described in the installation documents. Configuration of the service monitoring wasn't too difficult; I went for disk space, CPU load, and Memory Usage. These tools were in the form of plug-ins which are basically small scripts executed on the host and feedback information. Nagios can use SNMP to gather information; this will be very useful for monitoring server health, especially combined with HP's Integrated Lights Out (ILO) and various other devices that offer SNMP availability.

All things considered, I am very happy with Nagios. It's free, fully-featured and well supported. The installation went without a hitch--more than can be said about IBM Director. Setup and configuration will be time-consuming with a steep learning curve (my SNMP skills need to be developed); however, this is well worth the effort and won't take long to return this investment of time.

I hope this proved useful, I would love to hear from anyone else using Nagios.

Just an update on the Asterisk PBX project.  I now have a working PBX, this is only configured for internal calls (at the moment we only need this for conference calls).  The installation is pretty fast using the Asterisk@Home install CD, CentOS is the underlying distribution installed (this is basically RHEL with the RedHat bits removed) which allows easy updates via YUM.  I initially had some issues, although the system seemed to be functioning properly, no sound output was generated (music on hold, menu speech etc).  After a lot of hunting around and a lot of trial and error, this was tracked down to the installed Zaptel PCI card.  We installed the card with a view to later look in to PSTN intergration, however it seems Asterisk was a little unhappy about having the card installed but not used--Removal of the card solved all issues!  The call quality between two softphones is pretty good; today I will test the conferencing facility with 6+ callers.

While browsing I came across Windows Live Safety Center
(yes I know centre is spelt wrong, American of course!).  This is in beta and claims the following:

• Check for and remove
  viruses
• Learn about threats
• Improve your PC's
  performance
• Get rid of junk on your
  hard disk

I would be interested in hearing from someone who has tried
this, I don?t really trust Microsoft to keep my computer virus free (I?ll stick
with Norton Anti-Virus).  I do however
use the Microsoft
Anti-Spyware Beta application which I cannot fault, it works much better
than any other Anti-Spyware/Malware programs which I have used.

 
There comes a time within a growing company where the IT
support operation goes from a few 'Tech' guys keeping users happy, to a
reasonably sized department having ever more demanding requests piled on by
users. Efficiency can be increased by having certain support staff cover key
areas of the companies needs (Network/Server support, Desktop support, Software
support, etc), but without the proper underlying structure in place, making
this work can seem like fighting a losing battle. 

An essential tool in creating a basis for this structure is
of course a helpdesk/call logging system. I?m sure everyone who has worked in a
medium to large corporation has used at least one helpdesk solution, and while
that means staff need to log how/where their time is used (which may be
unpopular with less productive members of a team), the statistics provide a way
to justify budgetary requirements and departmental expansion.

Our company is currently looking at some of the helpdesk
solutions on the market; I thought I would comment on our findings so far. We
are, of course, challenged in the fact that we run a Linux/Unix-based network, and
most of the systems out there are geared towards Windows Domains and require a
Windows Server to operate on.

 

Three popular systems that we have considered implementing
are Touchpaper,
SupportWorks and Topdesk Enterprise. In this
installment, I'll tell you about the first one, Touchpaper.

 

One of our team members has previously used Touchpaper,
hence our investigation into what it would do for our organisation. The
Helpdesk system has many optional plug-in applications (most of which can also
be used without the helpdesk suite), the most interesting of these being NMS
(network monitoring) and AUtoserve (service/process monitoring). These modules
are well thought out and, when used with Helpdesk, they will automatically log
a call and assign it to the correct operator (if a router or particular service
were to go down).

This all looked good, and according to their sales staff and
technical advisor, this would all run on a Linux base. Unfortunately, this has proven
not to be the case. It's a shame because the power of Touchpaper seemed to be
its compatibility and integration of other modules. LANDesk integration, fully-automated
asset discovery, and the modules previously mentioned would have been a great
help. We also felt they were trying to take us for a ride with their quote. The
software cost was a tad under five figures, but the consultancy and setup
charges took the total price to five times the software cost! (All in ?GBP too,
not $USD.)

A recent article in
Computer Weekly stated that the quality of application support and browser
plug-in support is hampering users? enthusiasm for Linux as a desktop operating
system.  Office productivity tools were
deemed the most critical component by 51% of those reviewed, 38% said that
browser plug-in support needs improvement with 10% of those saying this is a severely
inhibiting factor.

I find I can get by with Linux on the desktop, OpenOffice,
Firefox and Thunderbird provide all of the vital functions.  I can even play World of Warcraft using the
brilliant Cedega of Transgaming!  I will agree with the 38% who claimed browser
plug-in support needs work, that?s a very annoying issue when it appears (grrrr
I don?t want to have to reboot in to another OS just so I can read a certain
webpage!).  Application support isn?t too
bad, I guess for the enterprise this is a bigger issue, but may commercially
supported products are available, SunOffice for example; Yes you have to pay
for this, but then businesses shouldn?t expect to get something for
nothing!  This is still a cheaper option
that MS Office + Windows licence.

Any opinions on this topic? 
What are you pet hates with Linux on the desktop?  Do you use Linux desktops in an enterprise
environment?  Let us know!

While starting to configure Nagios with multiple remote
hosts, I came to appreciate just how complex the setup can be with a multitude
of files.  Luckily I have found a web
based administration for Nagios which can be used to add/modify hosts and
backup configuration.  NagiosQL is a php/mysql based
system, the project is open source and a good deal of online support is
available in the form of FAQ?s Forums and Wiki pages.  I?m going to install NagiosQL this week which
should hopefully speed up my deployment of Nagios in our company.

Last time, I was talking about the various helpdesk
solutions that we are considering for our company, and I gave you an overview of
our findings on TouchPaper. Today, I'll tell you about the other two. I have
used Hornbill Supportworks in a
previous company; the interface is nice and the process of logging and updating
calls is very intuitive. Asset discovery is not included in the helpdesk
package (it's a separate, plug-in/product), however, manual input of asset data
is allowed. We ran a two-week trial of Supportworks, and I had problems in
getting the shared mailbox function to work with our mail server. Everything
worked with POP3, however IMAP did not. I?m sure this could have been resolved
with Hornbill over time; however, we only had a two-week evaluation so we stuck
with the POP3 config and got on with testing.

We were quite happy overall with Supportworks. The only
massive negative was that this system again needs a Windows Server base. It?s
quite disappointing that Hornbill don?t make this available for a Linux-base
system, considering that its major components include Apache and MySQL!

TOPdesk
is a lesser known helpdesk environment, and none of our team had used this
before. We found it on a Google search! We had our sights on TOPdesk
Enterprise, which is completely platform-independent, the core services being
coded in Java and database options of MSSQL or Oracle. The user interface is completely
Web-based. At first this didn?t seem very attractive, because Web-based
interfaces are normally quite cumbersome, slow, and awkward to use (form
submissions, drop-down boxes, and text fields). I must now say that the
interface of TOPdesk was the most intuitive Web interface I have used. Cutting-edge
programming techniques and lateral thinking have clearly been put into action
with a pleasing result.

The pricing structure of TOPdesk is pretty fair; most of the
systems features are broken down into modules, meaning you only pay for what
you want. One suggestion from their sales rep was that we could purchase the
basic system and then take additional modules later on. This would mean
deployment and costs could be staggered over time. TOPdesk also did not base
their prices on the number of operators and the number of end users; the total number
of users--be they 'end' users or operators--was all that needed to be
considered. LANDesk integration is, of course, available; reporting is also
included and very simple to work with using the report generator. One gripe I
have about TOPdesk is that it requires Internet Explorer; Firefox compatibility
is apparently coming soon.

All things considered, helpdesk systems are much of a
muchness. The features offered are quite similar and there doesn?t seem to be
one package which shines forth above all others. Taking this into account, our
decision will probably be based on user interface, system compatibility, and of
course, price. TOPdesk looks to be doing well (seeing as it is the only
platform-independent option so far). Any comments from current TOPdesk users,
or do you have any suggestions on other systems, which we should be looking at?

Last time, I was talking about the various helpdesk
solutions that were considering for our company, and I gave you an overview of
our findings on TouchPaper. Today, I'll tell you about the other two. I have
used Hornbill Supportworks in a
previous company; the interface is nice and the process of logging and updating
calls is very intuitive. Asset discovery is not included in the helpdesk
package (it's a separate, plug-in/product), however, manual input of asset data
is allowed. We ran a two-week trial of Supportworks, and I had problems in
getting the shared mailbox function to work with our mail server. Everything
worked with POP3, however IMAP did not. I?m sure this could have been resolved
with Hornbill over time; however, we only had a two-week evaluation so we stuck
with the POP3 config and got on with testing.

We were quite happy overall with Supportworks. The only
massive negative was that this system again needs a Windows Server base. It?s
quite disappointing that Hornbill don?t make this available for a Linux-base
system, considering that its major components include Apache and MySQL!

TOPdesk
is a lesser known helpdesk environment, and none of our team had used this
before. We found it on a Google search! We had our sights on TOPdesk
Enterprise, which is completely platform-independent, the core services being
coded in Java and database options of MSSQL or Oracle. The user interface is completely
Web-based. At first this didn?t seem very attractive, because Web-based
interfaces are normally quite cumbersome, slow, and awkward to use (form
submissions, drop-down boxes, and text fields). I must now say that the
interface of TOPdesk was the most intuitive Web interface I have used. Cutting-edge
programming techniques and lateral thinking have clearly been put into action
with a pleasing result.

The pricing structure of TOPdesk is pretty fair; most of the
systems features are broken down into modules, meaning you only pay for what
you want. One suggestion from their sales rep was that we could purchase the
basic system and then take additional modules later on. This would mean
deployment and costs could be staggered over time. TOPdesk also did not base
their prices on the number of operators and the number of end users; the total number
of users--be they 'end' users or operators--was all that needed to be
considered. LANDesk integration is, of course, available; reporting is also
included and very simple to work with using the report generator. One gripe I
have about TOPdesk is that it requires Internet Explorer; Firefox compatibility
is apparently coming soon.

All things considered, helpdesk systems are much of a
muchness. The features offered are quite similar and there doesn?t seem to be
one package which shines forth above all others. Taking this into account, our
decision will probably be based on user interface, system compatibility, and of
course, price. TOPdesk looks to be doing well (seeing as it is the only
platform-independent option so far). Any comments from current TOPdesk users,
or do you have any suggestions on other systems, which we should be looking at?

Version 3 of Nessus
has now been released.  For those
unfamiliar with Nessus, this tool
used by security professionals and hackers alike is one of the best
vulnerability scanners out there.  It is
estimated that Nessus is used by
over 75,000 organisations around the world, auditing the security of business
critical devices and applications.  New
plugins are constantly being released, meaning Nessus stays up to date with current
trends and newly discovered issues.  For
a modest fee a direct feed plugin is also offered which will ensure that your
scanner is as up to date as possible, email support is also offered to direct
feed customers.

Nessus 3 is
currently only available for Linux, however Windows and MacOSX platforms should
be supported in early 2006.

A big story of the week has been the Swiss governments?
decision to opt for Novell?s Suse Linux as
it?s standard server operating system. It
had been reported that over 300 public sector servers will be rolled over,
replacing both Microsoft Windows and Unix platforms. This move highlights that governments and
local authorities have become much more willing than the private sector to
adopt open-source platforms?The total cost of ownership over time outweighing concerns
of potential patent issues. Novell also recently
closed a deal with the UK?s
National Health Service worth over $39m.

As previously promised, I'll now cover the basic setup of
VPN tunnels between two OpenBSD gateways. So as to save wasting time on
unnecessary repetition, the basic installation of OpenBSD can be revisited both
in my previous blog and the OpenBSD FAQ pages.

I taught myself how to configure this system by reading the
vpn man page, plus some trial and error. I hope to simplify this process for
readers, giving clear examples through every step. Another very useful VPN
implementation is PPTP (VPN dial-in). I'll cover the installation and
configuration of PPTP later, which proves more troublesome than a basic IPSEC
tunnel. I'm starting with two clean OpenBSD installations; each has two network
interfaces installed and the following configuration:

Gateway A:

Hostname - vpnA
Domain - test.com
Interface1 - 10.1.1.1/255.255.255.0
Interface2 - 20.1.1.1/255.255.255.0

Gateway B:

Hostname - vpnB
Domain - test.com
Interface1 - 10.2.1.1/255.255.255.0
Interface2 - 20.1.1.2/255.255.255.0

As you can guess, Interface1 is to be connected to the
internal network, Interface2 is simulating out our(?) Internet connection.

Once the basic setup of the gateway machines is done
(referring to the install guides and above guidelines)?there is surprisingly
little which needs to be done to get a VPN tunnel up and running. The following
files will need to be edited. I'll explain how and why as we go along:

/etc/sysctl.conf
/etc/rf.conf
/etc/rc.conf.local
/etc/rc.local
/etc/pf.conf
/etc/isakmpd/isakmpd.conf
/etc/isakmpd/isakmpd.policy

There are two methods of authenticating the two gateways in
order to setup the VPN tunnel: manual or automatic. Manual keying requires that
you manually generate keys, security associations and then configure the IPSec
flows. Automatic keying does all of this for you (you never would have guess
that!). I have only used automatic keying?it's easier to configure than manual
keying and has worked flawlessly, so I see no reason to switch to manual
keying. I guess it comes down to a matter of preference. Instructions and
explanations of manual keying can be found on the vpn man page.

So, to get started, we must first make sure that IP
forwarding is allowed (any gateway machine will require this, whether it runs
VPN tunnels or not). This option is found inside the file /etc/sysctl.conf
along with activation of Authentication Header (AH), and Encapsulating Security
Payload (ESP) protocols. AH protocol provides replay protection, integrity, and
authentication. ESP provides the same functions, with the addition of confidentiality;
securing everything in the packet which follows the IP header. For a more
detailed explanation take a look at the ipsec man page.

Next, edit /etc/sysctl.conf. The following lines need to be
modified/added:

net.inet.esp.enable=1
net.inet.ah.enable=1
net.inet.ip.forwarding=1

> vi /etc/sysctl.conf

As discussed in my previous blog, packet filter is the
built-in firewall of OpenBSD. We need to make sure this is enabled at boot. In
the same configuration file, we will need to enable a daemon called ISAKMPD.
ISAKMPD is the automatic keying daemon which handles the creation of our IPSec
tunnels, authentication between the hosts, and so on. Full details can
surprisingly be found on the isakmpd man page.

The file is /etc/rc.conf.local, which may not exist; if not,
then create it. The following content needs to be entered:

pf=YES
isakmpd=YES

> vi /etc/rc.conf.local

We also need to edit /etc/rc.conf to allow ISAKMPD to start
on bootup:

isakmpd_flags=??
 

That was pretty easy! Next time, we'll configure ISAKMPD to
set up our VPN tunnels.

Berkeley, Carnegie Mellon,
the Georgia Institute of Technology, Illinois,
the Rensselaer Polytechnic Institute, Stanford and Texas universities have united with for major IT suppliers
to create a new set of common standards for the development of open source software.  It?s hoped that these standards will serve to
protect open source software projects from third parties looking to enforce
patents. IBM?s senior vice-president of technology and Intellectual property,
John Kelly, hopes that this will lead to greater commercial pickup of open
source software.

2005--It?s almost over and what a tough year it was for both
network administrators and end users in terms of security.  Leaks of financial data left over 50 million
accounts open for exploitation, phishing attacks have been steadily increasing
and bot nets have continued to grow.

While worm attacks have subsided we are seeing increasing trojan
infection taking hold with the help of client side exploits and vulnerabilities
(mostly in Internet Explorer).  Once
infected, most of these machines will become part of a bot net, these are used
for various shady activities including the stealing of sensitive data (credit
card details etc), spamming and distributed denial of service attacks.

It?s not just the Internet underworld who have caused a stir
this year, Sony BMG has came under heavy pressure when it was discovered that their
DRM (Digital Rights Management) software acted exactly as a malicious rootkit
would, installing itself without giving any notification to the user and
leaving no evidence of it?s activities. 
Sony BMG has been forced to withdraw CD?s incorporating the software in
question and proposed settlement for six cases filed against it in
the Southern District of New York.

What will 2006 bring us?  I won?t make any wild predictions, we?ll just
have to wait and see!

Wishing everyone a happy new year.

In part
1 of this tutorial on setting up VPN tunnels with OpenBSD, I went over
authenticating the gateways with automatic (or manual) keying, began editing
some of the files that need to modified, and enabling the ISAKMPD daemon.
Now, let's configure ISAKMPD to set up our VPN tunnels. This is a little more
complex than the previous steps. It's quite important that you understand what's
going on at this point. Two files need to be created/modified at this point. They
are /etc/isakmpd/isakmpd.conf
and /etc/isakmpd/isakmpd.policy,
click on the links to view the full man page for these files. Basically isakmpd.conf is the general
configuration file for the ISAKMPD daemon; isakmpd.policy
sets the acceptable security policy for key exchange.

Let's first look at /etc/isakmpd/isakmpd.policy.
The contents of this file will be the same on both gateway machines. Here are
the contents of this file:

Keynote-version: 2
Authorizer: "POLICY"
Conditions: app_domain
== "IPsec policy" &&
esp_present
== "yes" &&
esp_enc_alg
!= "null" -> "true";

Now we can consider /etc/isakmpd/isakmpd.conf,
this will be different on both gateway machines. This file contains
instructions on which IP address the daemons should listen on, VPN end points,
internal network details for each end, encryption types, and of course, a pre-shared
key which will be used to authorize the remote gateway.

Here are the contents of
/etc/isakmpd/isakmpd.conf for vpnA:

# Filter incoming phase 1 negotiations so they are only# valid if negotiating with this local address.

[General]

Listen-On=              20.1.1.1

# Incoming phase 1 negotiations are multiplexed on the# source IP address.  Phase 1 is used to set up a protected# channel just between the two gateway machines.# This channel is then used for the phase 2 negotiation# traffic (i.e. encrypted & authenticated).

[Phase 1]

20.1.1.2=           vpnB

# 'Phase 2' defines which connections the daemon# should establish.  These connections contain the actual# "IPsec VPN" information.

[Phase 2]

Connections=            VPN-A-B

# ISAKMP phase 1 peers (from [Phase 1])

[vpnB]

Phase=                  1Transport=              udpAddress=                20.1.1.2Configuration=          Default-main-modeAuthentication=         aaf5dc2122288ff01485329b2f51902d63874a9c

# IPSEC phase 2 connections (from [Phase 2])

[VPN-A-B]

Phase=                  2ISAKMP-peer=            vpnBConfiguration=          Default-quick-modeLocal-ID=               vpnA-internal-networkRemote-ID=              vpnB-internal-network

# ID sections (as used in [VPN-A-B])

[vpnA-internal-network]

ID-type=                IPV4_ADDR_SUBNETNetwork=                10.1.1.0Netmask=                255.255.255.0

[vpnB-internal-network]

ID-type=                IPV4_ADDR_SUBNETNetwork=                10.2.1.1Netmask=                255.255.255.0

# Main and Quick Mode descriptions# (as used by peers and connections).

[Default-main-mode]

DOI=                    IPSECEXCHANGE_TYPE=          ID_PROTTransforms=             3DES-SHA,BLF-SHA

[Default-quick-mode]

DOI=                    IPSECEXCHANGE_TYPE=          QUICK_MODESuites=                 QM-ESP-3DES-SHA-SUITE

And for vpnB:

# Filter incoming phase 1 negotiations so they are only# valid if negotiating with this local address.

[General]

Listen-On=              20.1.1.2

# Incoming phase 1 negotiations are multiplexed on the# source IP address.  Phase 1 is used to set up a protected# channel just between the two gateway machines.# This channel is then used for the phase 2 negotiation# traffic (i.e. encrypted & authenticated).

[Phase 1]

20.1.1.1=           vpnA

# 'Phase 2' defines which connections the daemon# should establish.  These connections contain the actual# "IPsec VPN" information.

[Phase 2]

Connections=            VPN-B-A

# ISAKMP phase 1 peers (from [Phase 1])

[vpnA]Phase=                  1Transport=              udpAddress=                20.1.1.1Configuration=          Default-main-modeAuthentication=         aaf5dc2122288ff01485329b2f51902d63874a9c

# IPSEC phase 2 connections (from [Phase 2])

[VPN-B-A]

Phase=                  2ISAKMP-peer=            vpnAConfiguration=          Default-quick-modeLocal-ID=               vpnB-internal-networkRemote-ID=              vpnA-internal-network

# ID sections (as used in [VPN-B-A])

[vpnA-internal-network]

ID-type=                IPV4_ADDR_SUBNETNetwork=                10.1.1.0Netmask=                255.255.255.0

[vpnB-internal-network]

ID-type=                IPV4_ADDR_SUBNETNetwork=                10.2.1.1Netmask=                255.255.255.0

# Main and Quick Mode descriptions# (as used by peers and connections).

[Default-main-mode]

DOI=                    IPSECEXCHANGE_TYPE=          ID_PROTTransforms=             3DES-SHA,BLF-SHA

[Default-quick-mode]

DOI=                    IPSECEXCHANGE_TYPE=          QUICK_MODESuites=                 QM-ESP-3DES-SHA-SUITE

Now these are in place, we need to change the permissions
and owner/group. If we don't do this, then the daemon will refuse to read the
configuration files. The following commands will do the trick:

> chown root:wheel /etc/isakmpd/isakmpd.conf

> chmod 0600 /etc/isakmpd/isakmpd.conf

> chown root:wheel /etc/isakmpd/isakmpd.policy

> chmod 0600 /etc/isakmpd/isakmpd.policy

In the
next and final instalment, I'll go over editing the Packet Filter rules.

There seems to have been quite a lot of debate in the security
arena over the past few day on the topic of Windows vs. Linux as a secure platform.  As you can guess it?s a hot topic with many
heated opinions on either side.

ComupterWeekly
state that Linux/Unix bugs outnumbered Windows flaws three-to-one with 45%
of all vulnerabilities.  These figures
were provided by CERT, from browsing their
website it isn?t clear if they are funded by any party which may sway their independence.

An article on Slashdot,
the security research group, mentions a story from the Globe and Mail.  This states that "During August, 67
per cent of all successful and verifiable digital attacks against on-line
servers targeted Linux, followed by Microsoft Windows at 23.2 per cent. A total
of 12,892 Linux on-line servers running e-business and information sites were
successfully breached in that month, followed by 4,626 Windows servers." The reactions to this have been ongoing and
with some passion.  The biggest concerns
over this article were firstly that the research was funded by Microsoft, the
second being that the context in which these breaches are used or recorded can
pervert the reality.  The number of Linux
servers running e-business and information sites is much greater than that of
Windows, also if taken in a broader context, each Windows machine (be that a
server or home user) which is infected by an internet worm like SLAMMER.
NIMDA. CODE RED. BUGBEAR. BLASTER etc is actually fully breached and
potentially much more of a concern than a defaced or broken website.

I think as with any statistics these will always show what
the organisation behind the collection and processing of them wants to
show.  I don?t think there will ever be
universal agreement on which system is better, which is more secure etc.  Having worked with both I would personally go
for Linix/BSD, however I?m sure many readers would go the other way.

While browsing the net I came across some great Mini-PC?s made
by a company called SD-Omega.  Various flavours of microscopic PC?s are
offered, from Celeron based ?book size? systems to the much more powerful
Pentium4 based systems running at over 3Ghz! 
I doubt these would make for a very practical PC system, they could make
great media PC?s or when combined with a touch screen monitor and software like
GpsDrive, a great in-car navigation
and entertainment system could be knocked together!

In Part 2 of the tutorial, I took you through the configuration of files for the ISAKMPD daemon. Now, all that's left to do is edit our Packet Filter rules so that the VPN traffic can pass through. I'll assume we are starting from a blank rule set. We only allow traffic to pass from one gateway to the other, not to any hosts on the internet. All traffic between the two private networks and the two gateways needs to be passed; this will be on device enc0 (IPsec tunnel). UDP traffic between the two gateways will be allowed on port 500 (the key exchange) and encrypted data will need to be passed between the two gateways (ESP protocol).

pf.conf for vpnA:

GATEWAY_A = "20.1.1.1"
GATEWAY_B = "20.1.1.2"
NETWORK_A = "10.1.1.0/24"
NETWORK_B = "10.2.1.0/24"

int_if="le1"
ext_if="le2"

# default deny
# $ext_if is the only interface going to the outside.
block log on { enc0, $ext_if } all

# Pass encrypted traffic to/from security gateways
pass in proto esp from $GATEWAY_B to $GATEWAY_A
pass out proto esp from $GATEWAY_A to $GATEWAY_B

# Need to allow ipencap traffic on enc0.
pass in on enc0 proto ipencap from $GATEWAY_B to $GATEWAY_A

# Pass traffic to/from the designated subnets.
pass in on enc0 from $NETWORK_B to $NETWORK_A
pass out on enc0 from $NETWORK_A to $NETWORK_B

# Pass isakmpd(8) traffic to/from the security gateways
pass in on $ext_if proto udp from $GATEWAY_B port = 500 to $GATEWAY_A port = 500
pass out on $ext_if proto udp from $GATEWAY_A port = 500 to $GATEWAY_B port = 500

pf.conf for vpnB:

GATEWAY_A = "20.1.1.1"
GATEWAY_B = "20.1.1.2"
NETWORK_A = "10.1.1.0/24"
NETWORK_B = "10.2.1.0/24"

int_if="le1"
ext_if="le2"

# default deny
# $ext_if is the only interface going to the outside.
block log on { enc0, $ext_if } all

# Pass encrypted traffic to/from security gateways
pass in proto esp from $GATEWAY_A to $GATEWAY_B
pass out proto esp from $GATEWAY_B to $GATEWAY_A

# Need to allow ipencap traffic on enc0.
pass in on enc0 proto ipencap from $GATEWAY_A to $GATEWAY_B

# Pass traffic to/from the designated subnets.
pass in on enc0 from $NETWORK_A to $NETWORK_B
pass out on enc0 from $NETWORK_B to $NETWORK_A

# Pass isakmpd(8) traffic to/from the security gateways
pass in on $ext_if proto udp from $GATEWAY_A port = 500 to $GATEWAY_B port = 500
pass out on $ext_if proto udp from $GATEWAY_B port = 500 to $GATEWAY_A port = 500

Ok that's the firewall sorted out. One more edit, and we should be done. We want to add a route from network 10.1.1.x to 10.2.1.x and vice-versa, and we want this to happen automatically each time the host is rebooted. To make sure this happens, we need to add the command to /etc/rc.local.

For vpnA:

route add ?net 10.2.1 10.1.1.1

For vpnB:

route add ?net 10.1.1 10.2.1.1



Right, that should cover everything.  Reboot both gateways and you should be able to ping the opposing network:





Don't forget, if you don't want to use OpenBSD as your main gateway, but you would like to use it for VPN tunnelling, this should not pose a problem. Simply make sure the correct port redirections are made on your firewall and put a route for the remote network on your current gateway which points to the OpenBSD host.

It would be great to hear if anyone found this guide useful.  If so then I will also write a guide to getting other essential services like PPTP, DNS and DHCP running on the OpenBSD platform.

Novell and RedHat have joined IBM?s strategic alliance,
their highest tier partner status.  IBM
have said that the strengthened alliance will allow users to obtain standards
based Linux hardware, software and service through integrated channels.  Customers will be able to purchase one and
three year Linux support subscriptions for the Linux operating system on both
IBM and non-IBM hardware.  Suse Linux
Enterprise Server will certify IBM?s version of Apache Geronimo?an open source
J2EE application server Websphere Community Edition.

Despite opposition from RedHat it has been announced the
Fedora Core 5 will include both the Mono runtime and Mono applications like F-Spot and Beagle.  Mono provides a base to develop and run .NET
applications on Linux and other Unix based operating systems (MacOS X, Solaris
etc) and is fast becoming a leading choice for application developers.  With the upcoming Windows Vista making
increasing use of the .NET framework it could mean that in the future running
Windows applications on a Linux platform becomes a realistic option.

Following up on my previous series on implementing VPN
tunnels with OpenBSD, I thought I should cover the configuration of another VPN
implementation, PPTP. PPTP stands for 'Point to Point Tunnelling Protocol.' This
allows users to 'dial-in' to access files or services on the internal corporate
network, from any Internet connection. The great thing about PPTP versus other
remote 'dial-in' types of VPN is that Microsoft Windows
(95/98/Me/NT/2000/XP/Vista) has a PPTP client built in, which means
administrators don't have to deal with any additional client software and the
problems that normally accompany it.

By far the most popular Open-Source PPTP server offering is Poptop. Poptop has the following features:

• Microsoft compatible
  authentication and encryption (MSCHAPv2, MPPE 40 - 128 bit RC4 encryption)
• Support for multiple client
  connections
• Seamless integration into a
  Microsoft network environment (LDAP, SAMBA) using RADIUS plugin
• Works with Windows
  95/98/Me/NT/2000/XP PPTP clients
• Works with Linux PPTP client
• Poptop is, and will remain,
  totally free under the GNU General Public License

While there isn't source for OpenBSD on the Poptop project
page, a port of Poptop is made available in the OpenBSD
packages archive. I'm going to run through installing and configuring Poptop on
an almost clean OpenBSD 3.7 installation; in fact, it's the exact same system
which I have just used in the IPSec tutorials.

I found the Poptop package here.
While I should use the UK
mirror, it's slow and often incomplete, and the German mirror sites are usually
fast and exact! Note that this is the package for OpenBSD 3.7. If you're using
another release of OpenBSD, then be sure to get the package from the correct
branch. I don't think there would be a problem but the packaging system may
have been modified between releases.

Getting Poptop running is not as simple as it initially
sounds. We have to go through the following process:

1. Recompile
   BSD Kernel for GRE support and additional tun devices.
2. Create
   additional tun devices.
3. Install
   package.
4. Configure
   Poptop to run with full strength encryption.
5. Allow
   Poptop traffic through the firewall.

I know recompiling the Kernel can sound quite scary to
someone who hasn't done this before. It did to me. This was required when I
first performed a Poptop installation with OpenBSD 3.6. I don't know if it's
still required, but as far as I can tell it is, (if anyone knows otherwise then
please let me know!). You don't need to do this for every system built. I did
it the first time and then kept a copy of the new kernel to use on later
installs.

The following process is just one way in which Poptop can be
configured, but I'm sure there are others. I found this quite difficult the
first time with various mailing lists and forum posts giving conflicting
information. Hopefully, this guide brings all of the correct information
together into one place.

First of all, copy and unzip the system source files to your
/usr/src directory. I won't go in to too much detail with explaining simple
actions like this, I'm assuming by now most people following these tutorials
are pretty comfortable with performing basic operations in BSD. The source will
be located in files called src.tar.gz, and sys.tar.gz, either located on your
installation CD or downloaded from the OpenBSD FTP servers.

# tar ?xzf src.tar.gz ?C /usr/src/

# tar ?xzf sys.tar.gz ?C /usr/src/

Move to the platform independent config directory and create
a copy of the GENERIC config file:

# cd /usr/src/sys/conf

# cp ./GENERIC ./Custom-Poptop-build

Now we need to edit the config,

# vi ./Custom-Poptop-build

First comment out the inbuilt GRE support:

#pseudo-device  gre            # GRE encapsulation interface

Secondly increase the number of tun devices to match the
maximum number of concurrent users you expect to have connected. I have set
this to 50, which is much more that I will ever need (I would say 10 is enough
for my needs):

pseudo-device   tun     50       # network tunneling over tty

Now lets rebuild the kernel; we need to create a copy of the
platform dependent configuration file:

# cd /usr/src/sys/arch/i386/conf

# cp ./GENERIC ./Custom-Poptop-build

Edit this config file to point to the previously modified platform
independent config:

# vi ./Custom-Poptop-config

Replace:

include ?../../../conf/GENERIC?

With:

include ?../../../conf/Custom-Poptop-build?

Now start the building process:

# config ./Custom-Poptop-build

# cd ../compile/Custom-Poptop-build

# make depend && make

Hopefully you shouldn't get any nasty errors thrown up. Once
the build process has completed you should find the kernel (filename is simply 'bsd')
with the size 4.9MB. Let's now replace the default kernel:

# cp /bsd /bsd.old

# cp./bsd /bsd

Now a reboot will verify that all is working okay. After
logon you should see the name of your new kernel (Custom-Poptop-build) to the
right of the timestamp. Well that's the kernel recompiled; it wasn't as tricky
as it sounds was it? That's enough for one installment. In the next one, we'll
continue with creating the additional tun devices that you'll need, and then
actually installing and configuring the Poptop package.

Just an update on my experience so far with Nagios.  After playing around with various front-ends
for easy configuration (which I previously mentioned), I wasn?t happy with the
setup they had given and found I was often forced to setup functions which I
didn?t want, just to stop the configuration tool from throwing up errors and
let me proceed.  Back to square one, I
had to bite the bullet and set aside quite a bit of time to properly read the
manuals and fully understand the configuration process?Lots of time, boring
manuals, but in the end well worth it.  I
now have Nagios configured to monitor quite a few of our servers and alert when
various system variables reach warning or critical levels.  This has proven to be very useful for pinpointing
intermittent problems with our mail server, with alerts coming in because of
mail queue size, number of processes, memory usage and so on; it really helps
give a wider view of the big picture and lets me know exactly what to look for
in system logs.  I have even found that I
can fix some problems pre-emptively before they become a problem (before users
notice), examples being low disk space, jammed mail queue due to spam attacks
etc.

Overall I would say not to be put off by what first looks to
be a complex configuration, once understood it?s pretty simple and the rewards
are well worth the initial effort.  Has
anyone else had success with Nagios?

Although many hardware manufacturers are offering 108Mbps
products, these in practise rarely operate above 50Mbps (TomsNetworking
tests).  High speeds are currently
offered using MIMO (Multiple Input Multiple Output) or similar technologies,
this basically means that the devices use multiple channels to send/receive data,
this is pretty controversial as it means more traffic in busy areas and is
pretty much seen as marketing spin to keep people upgrading while real benefits
are questionable, especially as various manufacturers standards wiffer and are incompatible
with each other.

802.11n is now on it?s way, this will offer true standards
for high speed WiFi with Broadcom announcing it?s Intensi-fi chips are now
available in sampling?These have a maximum throughput of 300Mbps!  Marvell, another manufacturer of WiFi chips
has announced that it also has 802.11n chips ready for testing, these have a
potential for working at up to 600Mbps!

Speeds like this will truly open up WiFi as a realistic
alternative to wired networks for high bandwidth applications, Voice Over IP
and even Video Conferencing.

In last week's tutorial installment on PPTP VPN, we
recompiled the kernel. The next step is to create the additional tun devices and
finish installing and configuring Poptop.

Let's get started: tun0 ? tun3 exist by default, so create
additional devices with the following:

# cd /dev

# sh ./MAKEDEV tun?

Where ? is the device number, I need to go through from tun4
- tun49 to create the 50 concurrent devices I enabled in the kernel.

Flying along now, we can get down to installing the Poptop
package. Download the package from the repository of your choice and install
with:

# pkg_add poptop-1.1.4.b4p1.tgz

A few errors are shown but they aren't anything to worry
about. Let's get down to the Poptop configuration. The first file to edit is
/etc/pptpd.conf:

option /etc/ppp/ppp.conf

# IP address of your server-side PPP endpoint:

# (An unused IP address on your internal LAN)

localip 20.1.1.2

# IP address range to use for your PPTP clients:

# (Unused IP addresses on your internal LAN)

remoteip 20.1.1.200-250

# IP address of external LAN interface:

# (The IP which a remote users client will connect with)

listen 10.21.7.63

pidfile /var/run/pptpd.pid

Now /etc/ppp/ppp.conf needs to be configured to handle
encryption via a loop back:

loop:

      set timeout 0

      set log phase chat connect lcp ipcp command

      set device localhost:pptp

      set dial

      set login

      set mppe * stateful

      # Server (local) IP address, Range for Clients, and Netmask

      # Use the same IP addresses you specified in /etc/pppd.conf :

      set ifaddr 20.1.1.2 20.1.1.200-20.1.1.250 255.255.255.255

      set server /tmp/loop "" 0177

loop-in:

     set timeout 0

     set log phase lcp ipcp command

     allow mode direct

pptp:

     load loop

     # Disable unsecured auth

     disable pap

     disable chap

     enable mschapv2

     disable deflate pred1

     deny deflate pred1

     disable ipv6

     accept mppe

     enable proxy

     accept dns

     # DNS Servers to assign client 

     # Use your own DNS server IP address :

     set dns 20.1.1.100 

     # NetBIOS/WINS Servers to assign client 

     # Use your own WINS server IP address :

     set nbns 20.1.1.100

     set device !/etc/ppp/secure

We need to create the file /etc/ppp/secure and add the
following content:

#!/bin/sh

exec /usr/sbin/ppp -direct loop-in

Chmod the file after creation:

# chmod u+x

The file /etc/ppp/ppp.secret holds usernames and passwords
for your dial-in users. The format is quite simple:

username       password       *

username       password       staticip

username       password       *

This file needs to have chmod 0400
performed on it after editing. The * denotes that this user will be
automatically allocated a free IP address; you can alternatively specify a
static address for this user.

It's nice to have any PPP log messages sent to it's own log
file, as this makes debugging easier and keeps things tidy. Add the following
lines to /etc/syslog.conf :

!ppp

*.*                    /var/log/ppp.log

Remember to create ppp.log and reload syslogd:

# touch /var/log/ppp.log

# kill ?HUP (syslogd PID)

Just as a hint, find the syslogd process ID with ps aux. There will be two syslogd processes running, so you
need to use the one running as root.

Poptop can be launched manually, the ?d switch will enable
debug output.

# /usr/local/sbin/pptpd -d

To start Poptop automatically during boot, the following
lines should be added to /etc/rc.local:

if [ -x /usr/local/sbin/pptpd ]; then

    echo -n " pptpd";    /usr/local/sbin/pptpd -d

fi

I would recommend doing this as it would be easy to forget
to start the daemon after rebooting and takes no effort to set up.

Our last consideration is the firewall (Packet Filter). We
need to allow inbound tcp connections on port 1723 on the external IP, inbound
and outbound connections of type gre on the external IP, and also all traffic
to tun* devices:

# PPTP Rules (VPN Dial in)

pass in quick on $ext_if proto tcp from any to $ext_if port = 1723 modulate state

pass in quick on $ext_if proto gre from any to $ext_if keep state

pass out quick on $ext_if proto gre from $ext_if to any keep state

pass in quick log on tun0 all

pass out quick log on tun0 all

pass in quick log on tun1 all

pass out quick log on tun1 all

Now all that's left is to test it. Reboot the machine to
make sure that everything is started cleanly. Now, we just need to create a
PPTP client connection and make sure it actually connects.

I'm using Windows XP as an example. Start the New Connection
Wizard, and select the option 'Connect to the network at my workplace'. The
next option to select is 'Virtual Private Network connection' rather than
Dial-up connection. Enter any name for the connection; the suggestion is 'Company
Name'. There is an option at this stage to have an initial connection dialed before
making the VPN connection. I prefer to disable this option, but the choice is
yours. At the next step, enter the IP address or hostname of your Gateway
machine; this is the address seen by the outside world. In our example, this is
10.21.7.63, the IP specified in /etc/pptpd.conf with the listen directive.

In last week's tutorial installment on PPTP VPN, we recompiled the kernel. The next step is to create the additional tun devices and finish installing and configuring Poptop.

Let's get started: tun0 ? tun3 exist by default, so create additional devices with the following:

# cd /dev

# sh ./MAKEDEV tun?

Where ? is the device number, I need to go through from tun4 - tun49 to create the 50 concurrent devices I enabled in the kernel.

Flying along now, we can get down to installing the Poptop package. Download the package from the repository of your choice and install with:

# pkg_add poptop-1.1.4.b4p1.tgz

A few errors are shown but they aren't anything to worry about. Let's get down to the Poptop configuration. The first file to edit is /etc/pptpd.conf:

option /etc/ppp/ppp.conf

# IP address of your server-side PPP endpoint:

# (An unused IP address on your internal LAN)

localip 20.1.1.2

# IP address range to use for your PPTP clients:

# (Unused IP addresses on your internal LAN)

remoteip 20.1.1.200-250

# IP address of external LAN interface:

# (The IP which a remote users client will connect with)

listen 10.21.7.63

pidfile /var/run/pptpd.pid

Now /etc/ppp/ppp.conf needs to be configured to handle encryption via a loop back:

loop:

      set timeout 0

      set log phase chat connect lcp ipcp command

      set device localhost:pptp

      set dial

      set login

      set mppe * stateful

      # Server (local) IP address, Range for Clients, and Netmask

      # Use the same IP addresses you specified in /etc/pppd.conf :

      set ifaddr 20.1.1.2 20.1.1.200-20.1.1.250 255.255.255.255

      set server /tmp/loop "" 0177

loop-in:

     set timeout 0

     set log phase lcp ipcp command

     allow mode direct

pptp:

     load loop

     # Disable unsecured auth

     disable pap

     disable chap

     enable mschapv2

     disable deflate pred1

     deny deflate pred1

     disable ipv6

     accept mppe

     enable proxy

     accept dns

    # DNS Servers to assign client 

     # Use your own DNS server IP address :

     set dns 20.1.1.100 

     # NetBIOS/WINS Servers to assign client 

     # Use your own WINS server IP address :

     set nbns 20.1.1.100

     set device !/etc/ppp/secure

We need to create the file /etc/ppp/secure and add the following content:

#!/bin/sh

exec /usr/sbin/ppp -direct loop-in

Chmod the file after creation: 

# chmod u+x

The file /etc/ppp/ppp.secret holds usernames and passwords for your dial-in users. The format is quite simple:

username       password       *

username       password       staticip

username       password       *

This file needs to have chmod 0400 performed on it after editing. The * denotes that this user will be automatically allocated a free IP address; you can alternatively specify a static address for this user.

It's nice to have any PPP log messages sent to it's own log file, as this makes debugging easier and keeps things tidy. Add the following lines to /etc/syslog.conf :

!ppp

*.*                    /var/log/ppp.log

Remember to create ppp.log and reload syslogd:

# touch /var/log/ppp.log

# kill ?HUP (syslogd PID)

Just as a hint, find the syslogd process ID with ps aux. There will be two syslogd processes running, so you need to use the one running as root.

Poptop can be launched manually, the ?d switch will enable debug output.

# /usr/local/sbin/pptpd -d 

To start Poptop automatically during boot, the following lines should be added to /etc/rc.local:

if [ -x /usr/local/sbin/pptpd ]; then

    echo -n " pptpd";    /usr/local/sbin/pptpd -d

fi

I would recommend doing this as it would be easy to forget to start the daemon after rebooting and takes no effort to set up.

Our last consideration is the firewall (Packet Filter). We need to allow inbound tcp connections on port 1723 on the external IP, inbound and outbound connections of type gre on the external IP, and also all traffic to tun* devices:

# PPTP Rules (VPN Dial in)

pass in quick on $ext_if proto tcp from any to $ext_if port = 1723 modulate state

pass in quick on $ext_if proto gre from any to $ext_if keep state

pass out quick on $ext_if proto gre from $ext_if to any keep state

pass in quick log on tun0 all

pass out quick log on tun0 all

pass in quick log on tun1 all

pass out quick log on tun1 all

Now all that's left is to test it. Reboot the machine to make sure that everything is started cleanly. Now, we just need to create a PPTP client connection and make sure it actually connects.

I'm using Windows XP as an example. Start the New Connection Wizard, and select the option 'Connect to the network at my workplace'. The next option to select is 'Virtual Private Network connection' rather than Dial-up connection. Enter any name for the connection; the suggestion is 'Company Name'. There is an option at this stage to have an initial connection dialed before making the VPN connection. I prefer to disable this option, but the choice is yours. At the next step, enter the IP address or hostname of your Gateway machine; this is the address seen by the outside world. In our example, this is 10.21.7.63, the IP specified in /etc/pptpd.conf with the listen directive.

That's the final step. Initiate the connection and enter a username/password from the ppp.secret file.

Once the connection is made you should be able to find your locally allocated IP in the VPN Status window, and you should also be able to ping an internal address (in my example 20.1.1.1 responds just fine).

I hope this has been an easy to follow guide to configuring PPTP access using OpenBSD and Poptop. If you have any problems following this guide then let me know.

As you have probably already guessed we are having a few
technical hitches with the blog software. 
The first part of the PPTP tutorial seems to have vanished, I?ll shortly
post a link to the entire article?published on TechRepublic.com