Perhaps I was a bit careless with my words, I was trying to portray that the
threat on the server is more an issue than the threat of someone reading
data in transit. Man-in-the-middle attacks or someone trying to catch the
data is a potential threat but I'm always leary about how a site stores the
information locally. If I wanted to gather credit card or personal info, I
wouldn't try to catch it in transit (too much trouble), I'd try to root a
server and get the data there (much easier).
David Ishmael, CCNA, IVCP
Senior Network Management Engineer
Windward Consulting Group, Inc.
Phone: (703) 283-7564
Pager: (888) 910-7094
eFax: (425) 969-4707
Fax: (703) 351-9428
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 4:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; 'John Steniger'
Subject: RE: Re[2]: Configuration Arguments... In House...
Being a little picky here - but SSL does not prevent sniffing. The
encrypted data that can
be sniffed has to be decrypted to be of any use. Provided you have a
"strong" algorithm
and a sufficient encryption level to make a brute-force attack futile (40
or 56 bit would not
be sufficient), the data should not be able to be decrypted. Just my two
cents.
Thanks!
Chris
Chris Hastings
Manager, Network Security
Network Computing Services
Vanderbilt University Medical Center
[EMAIL PROTECTED]
"David Ishmael"
<dishmael@windwardcg To: "'John Steniger'"
<[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
.com> <[EMAIL PROTECTED]>
Sent by: cc:
firewalls-owner@List Subject: RE: Re[2]:
Configuration Arguments... In House...
s.GNAC.NET
02/02/2001 02:40 PM
Please respond to
dishmael
Although SSL is nice, I'd be more concerned with the actual storage of the
credit card and personal information on the server. SSL prevents sniffing,
but doesn't prevent a compromise on the server itself.
David Ishmael, CCNA, IVCP
Senior Network Management Engineer
Windward Consulting Group, Inc.
Phone: (703) 283-7564
Pager: (888) 910-7094
eFax: (425) 969-4707
Fax: (703) 351-9428
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of John Steniger
Sent: Friday, February 02, 2001 2:22 PM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: Re[2]: Configuration Arguments... In House...
SSL provides encryption of the data as it travels over the network. This
way no one can sniff credit card #'s, ss#'s, etc.
John J. Steniger
Network and Security Specialist
Familymeds, Inc.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 02, 2001 12:29 PM
> To: [EMAIL PROTECTED]
> Subject: Re[2]: Configuration Arguments... In House...
>
>
> I want to make sure I understand one aspect of using an SSL
> secured web server
> on the internal network.
>
> SSL slows the attacker, forcing them through an
> authentication challenge, and
> gives you a layer of auditing. If the SSL authentication is
> compromised, the
> SSL server is just as vulnerable as a non-SSL server and
> subject to the same
> attacks. Is that right? Is there anything else that SSL
> will do for you in
> this circumstance?
>
> Thanks,
>
> Conrad Schellenberg
>
>
> ____________________Reply Separator____________________
> Subject: Re: Configuration Arguments... In House...
> Author: "David Lang" <[EMAIL PROTECTED]>
> Date: 2/2/2001 12:38 PM
>
> Brian, that depends on how your firewall passes 'only http traffic'
>
> for example Raptor checks the message from the client and
> makes sure it is
> a valid get/post/etc message, then it checks the response
> from the server
> and makes sure it's also valid. It does this for each request.
>
> firewall-1 on the other hand may check the inital connection
> to the server
> to see if it's a get/post/etc but after that allows that connection
> without spending more time on it.
>
> this means that if your inital connection triggers a bug on the server
> (IIS but, buffer overflow, etc) that ends up giving you a comand/shell
> prompt on the webserver if you have firewall-1 the attacker
> can then type
> commands on your webserver to download additional tools and
> attack your
> internal network from the webserver. Raptor watches the
> entire exchange
> and would prevent this.
>
> now no firewall can watch SSL connections so I'm not sure exactly what
> happens there. I don't know how many (if any) of the exploits
> can be used
> against SSL servers and continue to be exploited after the
> webserver is
> compramised.
>
> David Lang
>
>
>
> On Fri, 2 Feb 2001, Brian Steele wrote:
>
> > Date: Fri, 2 Feb 2001 12:20:10 -0400
> > From: Brian Steele <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: Configuration Arguments... In House...
> >
> > Hmm.. Can someone give an example of how a "compromise"
> that opens the
> > internal network to the attacker could work, if the proxy
> server is passing
> > only HTTP traffic on port 80 between the internal server
> and the Internet
> > client?
> >
> >
> > Brian
> >
> >
> > ----- Original Message -----
> > From: "Paul Cardon" <[EMAIL PROTECTED]>
> > To: "Kelly Slavens" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Friday, February 02, 2001 11:55 AM
> > Subject: Re: Configuration Arguments... In House...
> >
> >
> > > Kelly Slavens wrote:
> > > >
> > > > I have a situation where I have a Server,
> which will host web
> > > > content from "Internal" Data to the external world.
> This Server Needs
> > only
> > > > have web services accessible to the outside world
> beyond our network.
> > Our
> > > > current configuration is a Cisco Hardware Nat/Router
> Packet filter
> > directly
> > > > connected to the Internet connection. Connected to that
> is our MSProx2.0
> > > > (Being replaced with ISA Server soon)... One individual
> wishes to place
> > this
> > > > new web server directly behind the NAT alongside the
> Prox, With a so
> > called
> > > > "one way" push only network connection to the internal
> network. This
> > seems
> > > > like a bad idea to me. My suggestion was Place the Web
> server behind the
> > > > prox and use Reverse prox to redirect all web traffic
> to only this
> > single
> > > > internal Web server. This to me seems to be more secure
> than a second
> > > > machine sitting in the DMZ with a connection to the
> internal network.
> > >
> > > With the web server behind the Proxy, if the web server
> is compromised
> > > (eg. IIS Unicode vulnerability) then the entire internal
> network is open
> > > to the attacker. The other configuration is better but
> it isn't the
> > > only solution.
> > >
> > > -paul
> > > -
> > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > > "unsubscribe firewalls" in the body of the message.]
> >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
