RE: websiite log transfers from exposed to internal nets :

["Sloane, David" <DSloane () vfa com>]

Richard,

I thoroughly enjoyed your post - especially the methodology for selecting a
solution.

One question - what brought you to this conclusion?

> > We want the secure area to connect to the unsecure area. 

It has always seemed safer to me to connect from the secure area to the
unsecure.  When the unsecure system is compromised, it has fewer attack
vectors to internal systems.

Can you elaborate on your preference?

-David


-----Original Message-----
From: Richard Threadgill [mailto:richardt () midgard net] 
Sent: Sunday, June 22, 2003 1:33 PM
To: R. DuFresne
Cc: 'firewall-wizards () honor icsalabs com'
Subject: Re: [fw-wiz] websiite log transfers from exposed to internal nets: 


In message
<Pine.LNX.4.05.10306191045500.8802-100000 () darkstar sysinfo com>"R. D
uFresne" writes
> Folks,
>
> I have a number of windoows/NT based systems that are in an exposed DMZ 
> that need  to transfer rotated logs to an internal unix system forlog 
> analysis.  My recommendation is to have the internal unix system pull 
> those logs from the exposed subnet via rsync/sshd <would require cgywin 
> besides licesngin of sshd for a windows  platform>.  Of course, the 
> windows folks are ballking at this due to haivng to to setup the 
> applications/deamons and all that, let alone licesning sshd for their 
> platform.  I see the pull coming from the inside as being the best way 
> to control the transaction in a secure manner rather then punching a 
> hole for their systems to push <via plain old ftp> to the inside.  But, 
> perhaps I'm seeing things in a tunnel.  Is my view lopsided or skewd 
> and dooes anyone know of a way to accomplish this chore with something 
> more standard then sshd/rsync between these two platforms?
>
>
> Thanks,
>
> Ron DuFresne

Short answer: you're being perfectly sane and have probably got the best
architecture for your situation.

Longer answer:

You're asking three seperate issues here, let's rip them apart from each
other.

First, you're asking wihch direction should the communication be initiated -
secured area to unsecured area, or unsecured area to secured area.  We want
the secure area to connect to the unsecure area.  The only wrinkle to this
is that if you use ftp, you have a seperate connection coming back at an
unpredictable port, so you should probably avoid using ftp.  

Secondly, what protocol would you like to use? Because of ftp's multiple
connection issues, ssh or rcp are preferable protocols.  You probably don't
want to use rcp, because the traffic and the access credentials are being
sent in the clear, so you'd prefer to use ssh if you can.  You also want to
avoid udp-based protocols, because they're connectionless and therefore
harder to filter properly.

The third issue is what implementation you would
prefer to use.  The questions to ask: 

        1. which implementation is my team most comfortable
        installing and managing
        2. which implementation is reputed to be best right now
        3. is the implementation I plan to use also in use in other
        similar installations with similar use profiles and security
        requirements
        4. is the implementation I plan to use known to be vulnerable
        to specific well-known attacks

That's a prioritized list - user comfort level starts out winning.  Question
2 is how you find an implementation if your team isn't familiar with any.
Question three is used to confirm the relevance of a product's reputation;
if a product is almost never used by similar users, none of the problems
that will make your life bad will have been found by the existing user base.
Question 4 is also a confirmation question; if the implementation you
planned to use has just been announced to be vulnerable to an attack which
your installation is particularly vulnerable to, then you should probably
wait until that vulnerability is fixed.

So, let's examine our options.  We've already decided which side should
initiate the connection. Protocol is probably ssh, unless there's some
native application protocol that both sides of the connection support.  That
leaves determining the vendor and implementation of ssh, which depends on
end-user factors that we don't have, but that you do.

RichardT
_______________________________________________
firewall-wizards mailing list firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards