Jen,
Answers to your questions below.
Avi
-----Original Message-----
From: Jen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 08, 1999 2:43 PM
To: Fogel, Avi; 'Firewalls'
Subject: Re: Subject: Remote diagnostic security
Avi,
Is cyberwall a generic category or a product name?
AF>> cyberwall is a category name, defined by Aberdeen group for distributed
(spatially) security products that perform the integrated (locally)
functions of intrusion detection / prevention , network access control and
policy implementation - throught the network, and not just at the perimeter.
Hence they provide at every network junction (between segments, on servers
and clients, right above NDIS)an integrated function similar to the detect +
protect combination of a segment based RealSecure activating a perimeter
Firewall-1 or Gauntlet.
Is the word "cyberwall" trademarked?
AF>> Our "flagship" suite is hence called CyberwallPLUS. It is this name
that we have trademarked. Any vendor may use the category name cyberwall as
they can use firewall.
This isn't criticism, I'm just curious, because I haven't heard any other
company use the term "cyberwall", but whenever I hear it referenced by you
guys, it's referred to as a category of products.
AF>> I have not seen other vendors use the term either, they may be under
the misconception that cyberwall is the name of our product. vs the category
name. There are quite a few vendors though, that our G2 indicates, that are
developing competing products for this category.
Now for the technical questions:
How do you verify that the cyberwall clients have not been tampered with, or
that they are running correctly?
How do you make certain that the cyberwall client is running (with the
appropriate policies) before it connects to the remote access server? Do you
have a component that runs on the remote access server that checks to see
that the client is properly protected before allowing them to connect?
AF>> cyberwall can but not necessarily include strong authentication
functions. Network-1's product does not , but relies on the authentication
functions of the applications on the server. Our cyberwall would be
installed on the server you would want to remotely administer and other ones
on the same LAN that you would want to protect. The cyberwall provides a
configuartion and adaptive rule base GUI that allows for defining trust
relationships, defining network access controls (which ports can be
accessed, in or out, by which network addresses or address ranges, at what
time windows) and defining intrusions to look for and protect against.
For each of those servers it would be configured (remotely or locally) The
cyberwall on the remotely managed server would be configured to allow say
PCAnyWhere (port 5253?) access from given IP addresses or IP address ranges
and at specific time windows only. Cyberwalls on the other servers on the
LAN would be configured to disallow transmissions alltogether, or disallow
transmission on port 5253 from the remotely managed server, or allow
transmissions using other (Network Neighbourhood) only with specific
authentications. Other considerations involve NT domain configurations,
Primary and Secondary Domain Controllers - and we can continue off the
thread if you are interested. Typically cyberwalls would be installed on
clients only if there is information to protect on the client.
My understanding of cyberwalls is that they are installed on every device
you want to protect, much like anti-virus software is. Like some anti-virus
software, they can be centrally managed. Is this correct?
AF>> Both points are correct, typically installed between multi-protocol or
IP segments or on Win NT servers.
Also, I've read bunches of messages about cyberwalls ... all from Network-1.
Does anyone else have input on the products?
AF>> The products are very new, the server edition of CyberwallPLUS just
commenced shipments in May of 1999. A bunch of folks are testing them for
DNS, DHCP, LDAP, Web, ERP VoIP and other servers. One industry player that
tested the server edition, is Mark J Edwards of the NTSHOP
(http://www.ntshop.net). SC InfoSecurity Magazine recently gave the server
product a 4 star rating
http://www.infosecnews.com/scmagazine/1999_06/testc/prod1.html#CyberWallPLUS
-SV 5.0 Several other publications are reviewing it.
Jen
----- Original Message -----
From: Fogel, Avi <[EMAIL PROTECTED]>
To: David Markle <[EMAIL PROTECTED]>; 'jaeger' <[EMAIL PROTECTED]>;
'Firewalls' <[EMAIL PROTECTED]>; 'ruegamer'
<[EMAIL PROTECTED]>
Sent: Thursday, July 08, 1999 9:08 AM
Subject: RE: Subject: Remote diagnostic security
> A new category of products - cyberwalls, that performs very granular
network
> access control and intrusion prevention on the actual servers - can
> eliminate your concern, since a rule can be put on the server defining
> combinations of in/out services (ports) and IP addresses and would hence
> eliminate back-end connections by someone accessing the remote diagnosed
(or
> managed) server.
>
> If you like more info - pls send me a mail off the thread.
>
> Thanx
>
> Avi
>
> Network-1 Security Solutions, Inc.
> "Securing e-Business Networks"
>
> > -----Original Message-----
> > From: /o=citicorp/ou=DOMDI/cn=Recipients/cn=dmarkle On Behalf Of David
> > Markle
> > Sent: Thursday, July 08, 1999 8:51 AM
> > To: 'jaeger'; 'Firewalls'; 'ruegamer'
> > Subject: RE: Subject: Remote diagnostic security
> >
> > Good points. Additionally, you can use dialer call back as another
layer
> > of protection.
> >
> > -----Original Message-----
> > From: jaeger [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, July 08, 1999 5:56 AM
> > To: Firewalls; ruegamer
> > Cc: jaeger
> > Subject: RE: Subject: Remote diagnostic security
> >
> > we recommend the following approach to this wide spread problem:
> >
> > put a RAS Server or any other remote access device in the DMZ.
> > Authenticate remote users on the firewall. Establish a rule set on
> > the
> > firewall that limits remote users access to only those systems
> > really
> > needed. Sounds to good to be true? Right, you still have the problem
> > of
> > authenticated remote users misusing the servers they have access to
> > as a
> > jump platform. To prevent this you should have an IDS in place, that
> > monitors remote users activity and enforces a security policy on the
> > server itself. You need a host based IDS to achieve that level of
> > security.
> > Alternatively you could have more than one DMZ or a second firewall,
> > where all your servers
> > are sitting behind the 1st firewall, but cannot be misused as a jump
> > platform because of the 2nd firewall.
> >
> > Karl Jaeger
> > BDG
> >
> > Peter wrote:
> >
> > >Date: Tue, 6 Jul 1999 10:53:40 +0200
> > >From: [EMAIL PROTECTED]
> > >Subject: Remote diagnostic security
> > >
> > >Hello,
> > >
> > >has anyone a suggestion how I can handle remote diagnostic access
> > to
> > >servers in our LAN. My first thought was to put the server which
> > need
> > >remote diagnostic access in the DMZ. But in this case I have to put
> > all
> > >my servers in the DMZ sooner or later. The remote diagnostic user
> > >shouldn't get any access to other servers on the LAN. Yes I know I
> > >asking for something impossible. But, if anyone has a solution
> > please
> > >let me know. Thanks in advance.
> > >
> > >Peter Ruegamer
> > >Network Administrator
> > >MTU Friedrichshafen
> > << File: jaeger.vcf >>
> -
> [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.]
