Dear Mr.Mathur, Regarding Certificates issued by NG ICA for VPN-Client users in CP NG pdt.Well,This feature is supported in CP NG FP1 / FP2. So,Firstly,You should use CP NG Feature Pack-1/2. Then,From Policy Editor login to Management Server/Station/Module. And in User Tab of Object-Tree.You can create User.Down here in Auth Tab you can create Certificate for particular user "mathurn". Save that certificate in floppy.And use this certificate at the time of login from SecureCleint NG FP1.Instead of password choose certificate as a preffered authentication.Here we go!!
CP people are initiating trends of CA in Management Server & thereby they are proving if you are using CP and don't have external third party CA.No need to worry about. If you look at to trend-sequence... In CP NG---One can get Cert for only Management Server. In in CP NG FP1/2---One can also get cert for fwadmin/users!! What next we are waiting for getting certs for machines!! Who knows may be in next ver we can also have this ability. But,One of the rare problem associated with this ICA in site to site VPN-IKE using cert is sometimes the cert get corrupted at one site then you can not established VPN tunnel untill & unless you perform some painfull steps. This is what a short & sweet overview about CP NG ICA. Thanks. Respectfully Yours, Jigarkumar G Patel B.Tech.D.T,Masters,ECommerce MCSE,LCP,CCNA 1.0/2.0,CCSA/E/I ----- Original Message ----- From: [EMAIL PROTECTED] Date: Monday, June 10, 2002 1:01 pm Subject: Firewalls digest, Vol 1 #820 - 8 msgs > Send Firewalls mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnac.net/mailman/listinfo/firewalls > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Firewalls digest..." > > > Today's Topics: > > 1. Checkpoint NG and Securemote (Madhur Nanda) > 2. RE: Firewall for Small Office (Dan McGinn-Combs) > 3. RE: Opinions on netcache security (Kent Hundley) > 4. Re: Subject: Fw: netmeeting ports (Shay Hugi) > 5. Re: SSH for Firewall Management (was: Firewall Management > GUIs) (Mikael Olsson) > 6. Re: Subject: Firewall for Small Office (Shay Hugi) > 7. Re: Firewall for Small Office (Alvin Oga) > 8. Re: firewall logging (Mikael Olsson) > > --__--__-- > > Message: 1 > Subject: Checkpoint NG and Securemote > Date: Fri, 7 Jun 2002 11:01:53 +0530 > From: "Madhur Nanda" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > > Hi All, > > Has anybody successfully tested Checkpoint NG and Securemote > client = > connectivity using IKE as the encryption and certificates as the = > authentication method. I m trying but no success so far. Not able > to = > generate certificates for Securemote Users. I wish to first test > it with = > Checkpoint Internal CA... > > Still not clear how the whole setup would work..like CRL retrieval > by = > the Securemote clients..etc=20 > > any pointers or info are welcome=20 > > TIA > rgds > Madhur > > > > --__--__-- > > Message: 2 > From: Dan McGinn-Combs <[EMAIL PROTECTED]> > To: 'Richard Ginski' <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: RE: Firewall for Small Office > Date: Tue, 21 May 2002 09:54:19 -0400 > > Gee -- sounds like you're describing a Nokia ip120 to me. > > http://www.nokia.com/securitysolutions/platforms/index.html > > Dan > > -----Original Message----- > From: Richard Ginski [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 21, 2002 9:40 AM > To: [EMAIL PROTECTED] > Subject: Firewall for Small Office > > > Please forgive me for the question, but, I don't see it in the > archives. Our > organization is looking for an appliance firewall solution that > includes an > extra port. In other words, a minimum of 3 ports. Each of the 3 > ports must > be capable of processing firewall rules. The third port would be > for a DMZ > or "Service Net" (having its own set of rules). The problem I am > runninginto is that would be for a small office (30 users or > less), 3 ports,needs > to be securely remotely configurable (via the Internet), needs to > pass IPSEC > traffic (does not have to do VPN just pass the traffic)and inexpensive > ($1000 - $2000) I am aware of the many "types" of firewalls (stateful > inspection, etc). "Types of firewalls" are not my problem right > now. I can't > seem to find 1 firewall that meets our other needs. My problem is, > given our > needs, finding firewalls that meet our cost requirement.Are there > any such a > devices?Please let me knowwhat. Thanks in advance for your help. > _______________________________________________ > Firewalls mailing list > [EMAIL PROTECTED] > For Account Management (unsubscribe, get/change password, etc) > Please go to: > http://lists.gnac.net/mailman/listinfo/firewalls > > --__--__-- > > Message: 3 > From: "Kent Hundley" <[EMAIL PROTECTED]> > To: "'Ben Nagy'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: RE: Opinions on netcache security > Date: Tue, 21 May 2002 10:17:05 -0700 > > Good points all. Unfortunately, changing the firewall may not be > an option > for a variety of non-technical reasons which I won't bore anyone with. > (layer 8 - financial, layer 9 - political and layer 10 -religious) > Thanks > for the input, its appreciated. > > > Regards, > Kent > > -----Original Message----- > From: Ben Nagy [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 21, 2002 12:44 AM > To: 'Kent Hundley'; [EMAIL PROTECTED] > Subject: RE: Opinions on netcache security > > > Why do you need a reason _other_ than it's best practice? 8) > > In my experience, proxy vendors always seem keen to have their device > exempted from the firewall - yet another special exemption, just for > them, because they usually have outrageous performance lies to try and > justify. > > Even if the proxy server is perfectly hardened against an outside > attack, you should also remember that it probably significantly > weakensyour security policy for traffic from inside to outside. > Take a look at > the recent Cisco vulnerability - internal users were using the HTTPS > port redirction of the devices to send spam to outside hosts in a > prettymuch undetectable fashion (as far as inside admins were > concerned). I'm > happy to bet lunch that they aren't the only cache implementor to make > this "mistake" in the default configuration. After all, caching > devicesare all about speed, not security, right? The same > vulnerability could > obviously be used to make any TCP connection - UCE is just the one > thatcame up. Bill also makes a couple of other excellent points about > traffic policing and inspection which I won't go over again. If the > device supports any "intelligent" caching that should ring alarm bells > as well - because now it's probably starting to go out and pre-cache > things by itself, and who knows what could go wrong with that process. > > This is assuming that the cache appliance is as hardened as it > says it > is. As you've already mentioned, a port scan and a vulnerability > websearch aren't a complete testing regime. If I were testing it for > this kind of role I'd start by sending lots of evil packets of the > usualkind (overlapping fragments, bad length, bad checksums blah > blah blah) > all aimed at port 80 and all spoofed to come from google.com, to a mix > of inside and the proxy server's address, while it was in service. > Thencheck if it knows its inside addresses from its outside ones, > then...I'm not really a vuln-dev person, though. I'm sure there > are other > interesting possibilities. > > In short, this is an example of pure expediency. "It's not fast enough > through the firewall, let's just put it straight on the net." If you > have a firewall performance issue, fix it, or get a faster one. > > Cheers, > > -- > Ben Nagy > Network Security Specialist > Mb: TBA PGP Key ID: 0x1A86E304 > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Kent Hundley > Sent: Tuesday, May 21, 2002 12:06 AM > To: [EMAIL PROTECTED] > Subject: Opinions on netcache security > > > I'm looking for opinions on the relative security of installing a > netcache caching proxy in parallel with a firewall. > > I have always considered "best practices" to be that few, if any, > devices should be installed in parallel to a firewall unless there > is a > compelling justification for doing so. (less attack vectors, > simplicity,etc) However, my client is being told by Network > Appliance that they > should install their netcache proxies in parallel with their firewalls > for performance reasons. They are also being told that the netcache > proxies are "hardened" and do no support any outside to inside > initiatedconnections and that a large number of their clients > install their > netcache proxies in parallel with their firewalls. > > Some preliminary testing I have done did not reveal any available > portson the netcache when scanned from the outside and a search in > the ICAT > returned only 2 vuln's recorded for the netcache appliances. (one of > which was related to allowing HTTP tunnels in the default config) > > Given this, and given that there have been firewall performance > concernsby my client, I need a good reason not to install the > netcache's in > parallel with the firewalls other than "it's not best practice". Does > anyone have specific reasons why the netcache proxies should not be > installed in parallel with the firewall? In particular, any > experienceswith a netcache being compromised would be very helpful. > > Regards, > Kent > > > > --__--__-- > > Message: 4 > From: "Shay Hugi" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Re: Subject: Fw: netmeeting ports > Date: Fri, 7 Jun 2002 09:38:24 +0200 > > > Establishing a NetMeeting Connection with a Firewall > When you use NetMeeting to call other users over the Internet, > several IP > ports are required to establish the outbound connection. The > following table > shows the ports, their functions, and the resulting connection. > > Port Function Outbound Connection > 389 Internet Locator Service (ILS) TCP > 522 User Location Service TCP > 1503 T.120 TCP > 1720 H.323 call setup TCP > 1731 Audio call control TCP > Dynamic H.323 call control TCP > Dynamic H.323 streaming Real-Time Transfer Protocol (RTP) over UDP > > If you use a firewall to connect to the Internet, it must be > configured so > that the IP ports are not blocked. > > To establish outbound NetMeeting connections through a firewall, the > firewall must be configured to do the following: > > Pass through primary TCP connections on ports 389, 522, 1503, > 1720, and > 1731. > Pass through secondary TCP and UDP connections on dynamically > assigned ports > (1024-65535). > The H.323 call setup protocol dynamically negotiates a TCP port > for use by > the H.323 call control protocol. Also, both the audio call control > protocoland the H.323 call setup protocol dynamically negotiate > UDP ports for use by > the H.323 streaming protocol, called the Real-Time Transfer > Protocol (RTP). > In NetMeeting, two UDP ports are determined on each side of the > firewall for > audio and video streaming, for a total of four ports for inbound and > outbound audio and video. These dynamically negotiated ports are > selectedarbitrarily from all ports that can be assigned dynamically. > > NetMeeting directory services require port 389. Microsoft Internet > LocatorService (ILS) servers, which support the Lightweight > Directory Access > Protocol (LDAP) for NetMeeting, also require port 389. > > -Shay Hugi > -Mpthrill.com > > > > > > Message: 8 > > From: "Robert Lowe" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Subject: Fw: netmeeting ports > > Date: Fri, 7 Jun 2002 13:49:34 +1000 > _______________________________________________ > > Firewalls mailing list > > [EMAIL PROTECTED] > > For Account Management (unsubscribe, get/change password, etc) > Please go > to: > > http://lists.gnac.net/mailman/listinfo/firewalls > > > > > > End of Firewalls Digest > > > > > --__--__-- > > Message: 5 > Date: Fri, 07 Jun 2002 08:50:29 +0200 > From: Mikael Olsson <[EMAIL PROTECTED]> > Organization: Clavister AB > To: Kevin Steves <[EMAIL PROTECTED]> > Cc: Ben Nagy <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: Re: SSH for Firewall Management (was: Firewall Management > GUIs) > > (Remember, we were talking about the "best possible way" of > administrating a firewall; any little flaw counts :)) > > Kevin Steves wrote: > > > > On Tue, Jun 04, 2002 at 02:20:02PM +0200, Mikael Olsson wrote: > > > The complete (Open)SSH package is ~55000 lines of code, although > > > obviously not _all_ of it should be counted, and comes with > > > > that number seems overstated; for openssh-3.2.3p1 i see: > > > > $ kdsi *.[ch] openbsd-compat/*.[ch] > > 43488 7044 10999 4442 total > > I did "wc -l *.[ch]" in the 3.2.2p1 tarball root dir and got 54355 > lines; I even forgot about openbsd-compat and openssl, so it should > be even higher if you really want to count the complete package..? > > Anyway, the numbers here are sort of misleading anyway, since we > shouldn't really be counting code that never ever gets exposed > until > well after the user switch has been made. I was just trying to > illustrate the difference in code bulk. > > (Don't worry, I'm _not_ advocating supersimplistic frameworks like > ours for general-purpose use. It's very impractical for anything > but administering network gear; specialization does that.) > > > > backwards-compatibility code for stuff that shouldn't be used > > > to administrate firewalls (e.g. SSH1, which doesn't authenticate > > > the data stream). > > > > you are referring to insertion attacks due to CRC usage for data > > integrity checking? do you consider v1 to be fundamentally broken? > > Well, hm, yes and no. Insertion attacks by themselves could be bad > enough; consider the consequences of someone for instance > inserting > random garbage in a stream where you're uploading a new kernel... > to > a firewall far away... that needs to have 99.999% uptime. > > Also, from a generally paranoid perspective: best practices dictate > that one use a nonreversible hash to authenticate the stream. SSHv1 > fails in doing this. Ergo, it's less than perfect, and that's enough > for me to strongly recommend SSHv2 and disable v1 in the config. > � > > IMHO, for firewalls and firewall administration, the "less > exposure" > demand is a very real one, so ripping out unused code here is a good > thing, and having it around is a bad thing. How MUCH of a bad thing > is another story; again: we were shooting for "the best possible", > okay? :) > > > > from: http://www.cisco.com/warp/public/707/ssh.shtml > > > > "If a review of any claimed protocol defects shows that SSHv1 > protocol> in Cisco IOS is fundamentally broken, then Cisco will > determine if it > > is appropriate to migrate to SSHv2 at that time." > > Keeping in mind that migration would likely be costly for them, > I'd > take that statement with a pinch of salt. Out of curiosity: do > they > even _have_ code for SSHv2? Would they need to code it first? > > Statements like these tend to set me off on a rant though. Why > insist on staying with something that is "theoretically flawed", > just because a "real" vulnerability hasn't been shown to the > public? What if one day some clueful guy comes up with one, and > suddenly they've got millions of vulnerable units on their hands? > (Bah, I know, the vast majority uses telnet anyway :/ ) > > Granted, maybe some day someone will find a big-ass hole in the > SSHv2 protocol, or maybe in TLS, or maybe in IPsec, or maybe > in our framework for that matter. There is always that risk. > I still don't think "there are no public vulnerabilities" is > a convincing argument, in face of the theoretical flaws. In a risk > management scenario (which firewalling is all about), why choose > the bigger risk, when there is a better alternative? > (Although "SSHv2 is too demanding for the CPUs in the smaller > routers" is probably a more convincing argument, and likely closer > to the truth :/ ) > > -- > Mikael Olsson, Clavister AB > Storgatan 12, Box 393, SE-891 28 �RNSK�LDSVIK, Sweden > Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 > Fax: +46 (0)660 122 50 WWW: http://www.clavister.com > > --__--__-- > > Message: 6 > From: "Shay Hugi" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Re: Subject: Firewall for Small Office > Date: Fri, 7 Jun 2002 09:45:51 +0200 > > > check out the S-BOX http://www.s-box.com/ > > -Shay Hugi > -Mpthrill.com > > Message: 9 > Date: Mon, 20 May 2002 12:25:46 -0400 > From: "Richard Ginski" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Firewall for Small Office > > --=_025FDA9C.FD9CEE6A > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > > Please forgive me for the question, but, I don't see it in the > archives.Our organization is looking for an appliance firewall > solution that > includes an extra port. In other words, a minimum of 3 ports. Each of > the 3 ports must be capable of processing firewall rules. The > third port > would be for a DMZ or "Service Net" (having its own set of > rules). The > problem I am running into is that would be for a small office (30 > usersor less), 3 ports, needs to be securely remotely configurable > (via the > Internet), needs to pass IPSEC traffic (does not have to do VPN just > pass the traffic) and inexpensive ($1000 - $2000) . I am aware of the > many "types" of firewalls (stateful inspection, etc). "Types of > firewalls" are not my problem right now. I can't seem to find 1 > firewallthat meets our other needs. My problem is, given our > needs, finding > firewalls that meet our cost requirement. Are there any such a > devices?Please let me know what. Thanks in advance for your help. > > _______________________________________________ > > Firewalls mailing list > > [EMAIL PROTECTED] > > For Account Management (unsubscribe, get/change password, etc) > Please go > to: > > http://lists.gnac.net/mailman/listinfo/firewalls > > > > > > End of Firewalls Digest > > > > > --__--__-- > > Message: 7 > Date: Fri, 7 Jun 2002 00:08:58 -0700 (PDT) > From: Alvin Oga <[EMAIL PROTECTED]> > To: Richard Ginski <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: Firewall for Small Office > > > hi ya richar > > a 3-nic fw is fairly common... > - examples in the ipchains-HOWTO > > fairly simple fw machine so far... progbably run you under $800 > in hardware... > - but days/weeks to configure your ipchains correctly.. > > http://www.Linux-Sec.net/Firewalls/ > - list of firewall apps > - list of fw config gui > ... > > c ya > alvin > > On Mon, 20 May 2002, Richard Ginski wrote: > > > Please forgive me for the question, but, I don't see it in the > archives.> Our organization is looking for an appliance firewall > solution that > > includes an extra port. In other words, a minimum of 3 ports. > Each of > > the 3 ports must be capable of processing firewall rules. The > third port > > would be for a DMZ or "Service Net" (having its own set of > rules). The > > problem I am running into is that would be for a small office > (30 users > > or less), 3 ports, needs to be securely remotely configurable > (via the > > Internet), needs to pass IPSEC traffic (does not have to do VPN just > > pass the traffic) and inexpensive ($1000 - $2000) . I am aware > of the > > many "types" of firewalls (stateful inspection, etc). "Types of > > firewalls" are not my problem right now. I can't seem to find 1 > firewall> that meets our other needs. My problem is, given our > needs, finding > > firewalls that meet our cost requirement. Are there any such a > devices?> Please let me know what. Thanks in advance for your help. > > > > > --__--__-- > > Message: 8 > Date: Fri, 07 Jun 2002 09:06:19 +0200 > From: Mikael Olsson <[EMAIL PROTECTED]> > Organization: Clavister AB > To: Kevin Steves <[EMAIL PROTECTED]> > Cc: Ben Nagy <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: Re: firewall logging > > > > Kevin Steves wrote: > > > > I'm tending to think TCP syslog over SSL/TLS would be a good > > thing to have. > > Yeah, I've sort of been thinking along the same lines myself. > (Along > with using a remote-only syslog receiver that doesn't need to bind > the local domain sockets or whatever the OS flavour uses for local > event delivery.) Are you aware of a syslog receiver that actually > supports encrypted and authenticated logs? > > > -- > Mikael Olsson, Clavister AB > Storgatan 12, Box 393, SE-891 28 �RNSK�LDSVIK, Sweden > Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 > Fax: +46 (0)660 122 50 WWW: http://www.clavister.com > > > --__--__-- > > _______________________________________________ > Firewalls mailing list > [EMAIL PROTECTED] > For Account Management (unsubscribe, get/change password, etc) > Please go to: > http://lists.gnac.net/mailman/listinfo/firewalls > > > End of Firewalls Digest >
begin:vcard n:Patel;Jigarkumar G fn:Jigarkumar G. Patel tel;work:3934448/9 url:http://www.ecssin.com.sg org:ECS Computers (Asia) Pte Ltd;Training Division adr:;;19,Kallang Avenue;Singapore;Singapore;;Singapore version:2.1 email;internet:[EMAIL PROTECTED] title:Training Engineer end:vcard
