There are 3 major VNC distributions on Windows. They are RealVNC, UltraVNC, and tightVNC.

RealVNC has 3 different editions. If possible, please avoid the free version since it doesn't support encryption. The personal and enterprise edition are both fine.

As about the UltraVNC, it's fine if the DSM (Data Stream Modification) plugin is installed and enabled.

The tightVNC doesn't support encryption by itself. This one is not safe when used along without SSL tunneling.

Among the 3 distributions, only RealVNC can detect "man in the middle" attack. When selecting security level, please avoid 3-DES encryption, because there is handy tools (for example, the "cain & able" from www.oxid.it) that is capable of hacking VNC communication with such encryption.

The simplest way is through "round robin DNS". It's a load balancing technique in which balance power is placed in the DNS server instead of a strictly dedicated machine as other load techniques do. You can get detailed information by using Google. As long as you can control and configure the DNS server, the load balance is done. The "round robin DNS" can do load balancing but not fault tolerance.

The second place goes to "layer 4 switch". A layer 4 switch is a hardware device which route network traffic and connections to backend servers depends on predefined criteria. The defined criteria are mainly related with 4^th layer protocol defined by OSI. Again, you can get the many products of this category by using Google. The pros are easy for installation, and it can support fault tolerance. The cons is that it costs. 

The third place goes to "intelligent gateway". An intelligent gateway can be either a hardware device or a host which route network traffic and connections to backend servers depends on predefined criteria. The defined criteria are mainly related with 7^th layer protocol defined by OSI. For example, you can use HTTP or any proprietary protocol to do highly supplicated load balancing, routing, and fault tolerance. To save the cost, the "intelligent gateway" can be realized by a simple linux or windows box with pre-designed detection system (should be designed). In this way, an "intelligent gateway" server may much cheaper than a "layer 4 switch" device. In some sense, when "intelligent gateway" is implemented in the form of a server, it's playing the role of a central job dispatcher which is close to the last solution.

 The last solution goes to "server based high availability clustering" (SBHA). Its support and implementation is highly relied on the selected server OS and applications. 

When compared with "easy to implementation" (easy to difficult):
        RRDNS > L4S > IG >= SBHA

 When compared with "cost" (from cheap to expensive):
        RRDNS > L4S, IG, SBHA

When compared with "OS transparency" (from transparent to opacity):
        RRDNS > L4S > IG, SBHA

When compared with "application transparency" (from transparent to opacity):
        RRDNS > L4S, IG > SBHA

When compared with "fine control of load distribution" (from fine to rough):
        IG, SBHA > L4S > RRDNS

When compared with "ability of fault tolerance" (from high to low):
        SBHA > IG > L4S       (RRDNS is not capable of fault tolerance)

IPCop Firewall is a Linux firewall distribution geared towards home and SOHO (Small Office/Home Office) users. The IPCop interface is very user-friendly and task-based. IPCop offers the critical functionality of an expensive network appliance using stock, or even obsolete, hardware and OpenSource Software.


OLD PC + IPCOP = Secure Internet Appliance

IPCop lets you take an old PC and convert it into an appliance that will.

1. Secure your home network from the internet.
2. Improve the performance of web browsers (by keeping frequently used information)

All this functionality can be managed from a simple to use web interface, even updates and patches can be installed using a web browser.
Remember IPCop works with most home networks and small office networks, dial up modems, cable modems, ADSL, Leased lines and ISDN. It also lets several PCs share connections to the internet. If you have an always on connection to can even use IPCop to protect your web and email servers. IPCop also has remote management meaning you can securely update and reconfigure your IPCop firewall from anywhere with an internet connection!
(full story)

cutter+ngrep+wget+unzip+iftop+ssh+iptraf+natdet+ntop

"The Sentry tools provide host-level security services for the Unix platform. PortSentry, Logcheck/LogSentry, and HostSentry protect against portscans, automate log file auditing, and detect suspicious login activity on a continuous basis" (from http://sourceforge.net/projects/sentrytools/).

What is port knocking?

Port knocking is a method by which a remote computer (client) communicates with another computer (server) across closed ports. Information is encoded in the sequence of ports to which the client attempts to connect. The information flows in one direction, from the client to the server. The server does not send any response to the client as receipt of the information. Once encoded into a sequence of port numbers, any information can be sent across closed ports.

Logcheck is based upon a log checking program called frequentcheck.sh featured
in the Gauntlet(tm) firewall package by Trusted Information Systems Inc.
(http://www.tis.com). The logcheck shell script and logtail.c program have been
completely re-written from scratch and is implemented in a slightly
different manner to accommodate for two methods of log file auditing:

1) By reporting everything you tell it to specifically look for via keywords.

2) By reporting everything you didn't tell it to ignore via keywords.

This ensures that important messages are specifically brought to your
attention (via the keywords you look for) and that important messages that
you may have overlooked are also reported (by only ignoring items you tell
it to). The original frequentcheck.sh script was implemented in a somewhat
similar manner.

The script is a simple shell programming model and the logtail.c program
uses basic ANSI C compatible functions with comments and easy to follow
source. Unusual tricks and "golly-gee" features have been left out to
prevent problems.

The logcheck script should be run at least hourly on your hosts from the
cron daemon. This script will check files for unusual activity through the
use of simple grep(1) commands and will mail all findings (if any) to the
administrator. If nothing is found you'll receive no mail.

http://lists.freebsd.org/pipermail/...May/000695.html

On 6 May 2003, at 9:55, Bogdan TARU wrote:

> /kernel: pmap_collect: collecting pv entries -- suggest increasing
> PMAP_SHPGPERPROC
>
>  The machine being more than 200km away, I cannot compile a new kernel
> right away. So I was wondering if there are any tweaks that I can do
> 'remotely', to solve the problem at least temporary.

We ran into this problem on a similar system to your setup.  Here
is what we learned:

PV Entries are directly related the number of simultaneous children
processes Apache is allowed to spawn.

To figure out how many PV entries your system is using per
Apache process, run this command:

ipcs -a ; sysctl vm.zone | grep PV

Take a look at the "shared" memory section and find the NATTCH
value for Apache.  That number is the total number of Apache
processes that have attached to that shared memory segment.

The last line of output is your PV entry stats.  The third number in
from the left is the number of PV entries currently in use.

Since there are other things using PV entries on the system
(usually very few - Apache is the big consumer on a web server),
this isn't an exact science, but take the number of PV entries in
use and divide it by the number of Apache processes.  That will
give you a rough estimate of how many PV entries are in use per
Apache process.

I don't fully understand the code (pageout daemon) that calls the
code that generates that warning, but in practical use, the warning 
usually means that you don't have enough pages on the PV entry
"free" list and it has to compete with other page consumers to get
more pages from the system. 

Generally, it isn't a serious problem unless you see 5 of those
messages since the last boot or you're seeing panics from running
out of PV entries.  Five is the maximum warnings you'll see of that
type.  Any activity after that that would have generated the warning
has the warning suppressed, so if you hit five of those messages
from boot to present time, you have a problem that needs to be
addressed.

To address the problem, you'll need to tweak your Apache config
and restart Apache.  Decrease KeepAliveTimeOut or turn off
KeepAlive.  Set MaxClients to a number that will prevent your
system from being crashed by having too many PV entries in use
and yet still handle the load after reducing KeepAliveTimeout.

To determine MaxClients, take your maximum PV entries and
divide it by the number of PV entries per Apache process that you
calculated above.  Then, subtract a few clients from the result (10
or 20) and that should be a good number for MaxClients.

The Apache status page will be your friend when tweaking your
Apache config so that it efficiently handles the load without hitting
MaxClients.  It's off by default, so you'll have to turn it on in your
Apache config if it isn't already on.

To view your current maximum for PV entries, look at 'sysctl
vm.zone' and look at the "limit" column for PV ENTRY.

Determining the maximum PV entries your system will support
after tweaking PMAP_SHPGPERPROC isn't the easiest of tasks,
but here's the basic idea:

pv_entry_max = (shpgperproc * maxproc) + (((((availmem - 1) * 2) +
1) / pagesize) - firstpage)

Availmem can be found by doing a 'less /var/run/dmesg.boot' and
looking at the available memory figure in bytes (not Kbytes). 
Pagesize is typically 4096 bytes on FreeBSD 4.7 i386.  I'm not
certain on this, but I believe firstpage is the same as pagesize. 
Maxproc can be found with a 'sysctl kern.maxproc'.  Shpgperproc
defaults to 200 on FreeBSD 4.7, but may be higher depending on
your kernel config.

Just remember that you can't set PMAP_SHPGPERPROC
arbitrarily high or you could overflow your KVA without ever hitting
the limit for PV ENTRY.  It's best to nudge it upwards gradually
until the "collecting PV entries" goes away, provided you've
tweaked Apache as suggested above.

I know it's kludgy and annoying, but it's just what us heavy Apache
users have to deal with to avoid crashes due to the state of the
FreeBSD VM system.  The general idea is that FreeBSD is
designed for systems that don't do a lot of memory sharing
between overgrown parent and children processes.

Here's an article I found awhile back by Matthew Dillon (FreeBSD
VM guru) that outlines the issue with FreeBSD and memory
sharing between large numbers of large processes:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/x106.html

Most of these types of problems will go away when Apache 2.0
becomes useable by most people (missing many vital modules at
the present time) due to it's threading model (vs. spawning
children).  For now, we've just got to deal with it, unless someone
with the right expertise is willing to create a kernel config option
that changes how PV Entries are allocated for systems that have
many big fat memory sharing processes.

Sincerely,
Andrew Kinney
President and
Chief Technology Officer
Advantagecom Networks, Inc.
http://www.advantagecom.net