Well I've been working with Legato Support on this same issue. You should
1st look at TEch Bullentin 354 and if that doesn't mess you up nothing
will. Then they sent me the document I am pasting below. The one thing I
would like to see from the folks who made this work is a document showing
their envirourment. Software Release, # storage nodes, # tape drives +
type, # of clients and save sets, parallelism client's and server. With
this information and a little luck it just may work.
Ed Skolnik
IPG Shared Services
support AT legato DOT com wrote:
Date: Thu, 15 Aug 2002 14:30:36 -0700 (PDT)
From: support AT legato DOT com
To: Ed Skolnik
Subject: Re: Regarding Case Number 3024715
Ed,
Here is a document which discusses why there is no need to go through the
admittedly complex process of restricting the port range. I am still
going over the information in tech bulletin 354, but thought you might
this interesting.
----------ID: legato8672
There are two types of firewall software in the market, packet-filtering
and stateful firewall, below is a configuration requirement for
packet-filtering firewall:
You need to open up the following ports
(1) 7937-9000: for service daemons listening for requests;
(2) 10000-30000: for client-side process such as "save" to connect to the
service daemons;
(3) Legato uses both TCP and UDP, but only TCP is used for backup and
restore. UDP is for licensing, administration and other features outside
of backup/restore.
Example for Winroute Professional firewall (http://www.winroute.com) for
windows
----------------------------------------------------------------------------
Rule#1: Incoming packets (PERMIT)
Source address: [all clients outside firewall]; TCP: 7937-9936
Destination address: [backup server IP inside firewall]; TCP 10000-30000
Rule#2: Incoming packets (PERMIT)
Source address: [all clients outside firewall]; TCP: 10001-30000
Destination address: [backup server IP inside firewall]; TCP 7937-9000
Rule#3: Incoming packets (PERMIT)
Source address: [all DNS IP]; UDP: 53
Destination address: [backup server IP inside firewall]; UDP > 1023
Rule#4: Incoming packets (PERMIT)
Source address: [all DNS IP]; TCP: 53
Destination address: [backup server IP inside firewall]; TCP > 1023
Rule#5: Incoming packets (DROP)
Source address: [any host]; IP
Destination address: [any host]; IP
----------------------------------------------------------------------------
Rule#1: Outgoing packets (PERMIT)
Source address: [backup server IP inside firewall]; TCP: 7937-9936
Destination address: [all clients outside firewall]; TCP 10000-30000
Rule#2: Outgoing packets (PERMIT)
Source address: [backup server IP inside firewall]; TCP: 10001-30000
Destination address: [all clients outside firewall]; TCP 7937-9936
Rule#3: Incoming packets (PERMIT)
Source address: [backup server IP inside inside firewall]; UDP > 1023
Destination address: [all DNS IP]; UDP: 53
Rule#4: Incoming packets (PERMIT)
Source address: [backup server IP inside inside firewall]; TCP > 1023
Destination address: [all DNS IP]; TCP: 53
Rule#5: Outgoing packets (DROP)
Source address: [any host]; IP
Destination address: [any host]; IP
#################
LAB VERIFICATION
#################
NetWorker 6.1.1.b238 has been tested to successfully backup and restore
clients machines outside the firewall over the internet (WAN):
(1) Filesystem backups (commandline and GUI)
(2) NetWorker Module for SQL Server (commandline and GUI)
(Scheduled backup was only tested in a LAN but not WAN as there were
issues with DNS resolution over the internet, but commandline backup works
over WAN, and you can automate it via Task Schedule on Windows, or cron
jobs in UNIX)
###
FAQ
###
Q. Technical
Bulletin 354 seems very complex. But the suggestion above is so
simple, are you sure the suggestion above does not incur major security
leak?
A. This is a very common question as firewall security is only getting
attention in the past couple of years, so not many people understand the
capabilities of hackers, and what a firewall is limited to do.
Hacker is simply a term given to geeks who knows the ins and outs of an
operating system, software, or network; some hackers have high moral
values and uphold the good, some simply want to show off they are good,
some completely do it for evil purposes which is definitely going to be
caught and brought to justice sooner or later.
With software advances, there is always new ways for hackers to do both
good and evil. Currently, the most command ways for hacking into the
network is via memory buffer overflow which a firewall cannot protect; the
only way to protect against memory buffer overflow is having an alert
sysadmin keeping up to date with security leaks via newsgroups and other
means of staying up-to-date, and ensure the systems he/she maintain are
up-to-date with security patches.
Now back to the configuration issues to allow Legato NetWorker to work
across firewalls. In short, the suggestions in TB354 give two types of
examples,
(1) one that is listed in the example above, and
(2) one that shows you know to reduce the number of open port ranges
required to be opened (this is not necessary)
There is actually no benefit in estimating and reducing the number of open
port ranges required to do backup/recover in fact it will only cause
problems since you are bound to add or remove clients every now and then,
and the port range requirement will need to be recalculated every time,
and there is no easy way to calculate an adequate enough port range other
than to specify all the required port ranges that NetWorker uses by
default.
When you allow backup via the firewall, you are already opening holes to
hackers. But if you restrict communication to be only between your backup
clients and backup server, and ensure all these machines are up to date
with operating system security fixes, you should be safe. You might also
want to ensure you prevent IP spoofing if you firewall has this kind of
capablitity. Security maintainence is a lot of work to get started, but
once you are familiar with the known issues and hacker's techniques,
things will be easier as you know what resources to go to to keep your
network safe. Signup to newsletters from Microsoft, Linux, SUN for regular
updates as a start.
But is a firewall useless? No, firewall gives you the protection of
restricting only specific types of network packets through
(ICMP,IP,TCP,UDP, etc.), and allows control to limit access from and to
certain IP address(es) only. For example, a web server (without using
HTTPS) basically just needs TCP port 80 to be opened for incoming packets,
and restrict outcoming backs to originate from port 80. This effectively
protects you from many off-the-shelve trojans, probes, and hacker
utilities available freely for download on the internet. This type of
network packet-filtering firewall is termed "packet filtering firewall".
Linux's ipchains is a "packet filtering firewall". Recent new firewall
software improvise on packet filtering to become "stateful firewall". For
every packet that goes out, we expect a response (except for UDP), so
stateful firewall remembers this relationship, which effectively protects
you from DoS attacks (Denial-of-service) attacks via TCP SYN packets, etc.
A rule of thumb against fear of attack is whenever there is a security
leak, there is bound to be a fix for it, one just needs to stay alert and
patch your systems whenever there is a security leak.
######################
Reference information
######################
1) NetWorker clients will only use incoming SYN traffic to ports 7937 and
7938 (and not 7937-9000). But if you have a storage node, opening the
ports 7937-9000 should take care of any problems, remember to restrict
only communication between the backup server and storage node, so as to
restrict attack to only IP spoofing, which can be blocked by low-cost
hardware router/firewall (such as SonicWall XPR/2 from <A
href="http://www.sonicwall.com)">http://www.sonicwall.com) by putting
the storage node in a DMZ zone.
2) In practice UDP is not used by the NetWorker during client-server
exchanges.
Hence, notice in the example above, we only use TCP, and block all UDP
except for DNS queries.
In some old clients UDP was being used for portmapper broadcasts for
discovering NetWorker servers. However this is an anachronism and the
newer versions of clients (NetWorker 6.0.1 and above) are designed never
to attempt to discover the networker server by broadcasts.
-----
--
Greg Aranda E-mail: support AT legato DOT com
Technical Support Engineer WWW: www.legato.com
Legato Systems, Inc. FTP: ftp.legato.com
Hotline: 877-LEGATO-7 (877-534-2867)
Fax: 650-842-9344
*******************************************************
Please send e-mail to support AT legato DOT com
with your case number in the subject.
*******************************************************
On Thu, 15 Aug 2002 12:12:47 +0200, Irvine Short <irvine AT SANBI.AC DOT ZA>
wrote:
>"Faidherbe, Thierry" wrote:
>
>> I am backuping clients through firewall without any problem.
>> Here is the list of the ports I opened :
>>
>
>Thanks Thierry and all!
>
>I'll give it a bash. Any documentation on nsrla.res out there?
>
>Cheers,
>
>Irvine
>
>
>--
>
>Irvine Short
>
>Sys Admin
>SANBI, University of the Western Cape, South Africa
>http://www.sanbi.ac.za
>tel: +27-21-959 3645
>cel: +27-82-494 3828
>
>--
>Note: To sign off this list, send a "signoff" command via email
>to listserv AT listmail.temple DOT edu or visit the list's Web site at
>http://listmail.temple.edu/archives/networker.html where you can
>also view and post messages to the list.
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
