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.]
