lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <40E31938.9030206@jsbc.cc>
From: jimb at jsbc.cc (Jim Burwell)
Subject: PIX vs CheckPoint

I use both PIX and Checkpoint, and have used Checkpoint since 3.0b.  
IMHO, Checkpoint is far more intuitive and easy to use.  Adding host and 
network objects, placing them into groups, and employing them in rules 
is straight forward.  PIX also has this feature (object groups), but 
it's not as quick or easy since it's CLI.  I can get a basic FW1 config 
up and running a lot faster than a PIX, esp if using a Nokia appliance 
or something like Secure Platform where most of the OS 
configuration/armoring chores are done for you already.  I'm sure you 
could also search/replace and copy/paste out a basic PIX configuration 
too, but I find that I need to double and triple check my PIX configs 
where the CP GUI presents the config in very concise/intuitive matter.  
There's no checking through pages of ACL lines like on a PIX.

The NAT implementation in Checkpoint is also far more intuitive IMHO.  
Just match an original source IP/dest IP/dest port set in one table on 
the left side of the page,  and if the original packet matches, perform 
this or that NATing operation in table on the right side, all on a 
single line per matching rule in the GUI.  Match this, do this.  
Simple.  This is in contrast to the PIX with it's non-intuitive special 
case NAT 0 "no NAT" rule, and somewhat confusing NAT cofiguration 
syntax, etc, etc (and even worse the IOS method of NATing.  Ick.).  One 
nice thing about PIX in this regard is you don't have to worry about 
static public ARP entires.  It's taken care of for you.

CP of course has it's own pains and lots of little idiosyncrasies, 
undocumented features and pitfalls you need to learn about (yea for 
phoneboy.com).  For instance, never define a Firewall object as the 
internal IP if you want VPNs to work right, etc.

VPNs are also very easy to implement, espcially in CPNG, and especially 
if you have multiple sites (full meshes on Cisco are a PITA).  But only 
as long as it's a CP <-> CP VPN.  I've had lots of trouble getting CP 
<-> other vendor VPNs going and stable, although this can probably be 
said of most vendors.

CP rules for multiple firewall management.  From the beginning they've 
had the concept of a centralized management station which could control 
multiple firewall enforcement points/vpn devices.  CP also has both 
failover and clustering options, where PIX, AFAIK only has failover.

Having said all that, PIXes also work well for most FW tasks.  They're 
just a bit more awkward to configure/administrate IMHO, and lack some of 
the above mentioned features/functionality of CP.

I'm also a fan of iptables/netfilter, which I also think once you get 
the concept of the tables and chains down.  It's also nice because you 
have the power of Unix behind it, so you can easily use a real editor, 
to edit your config, display them in a real pager (less), and use 
scripting to modify your configs easily.  There's even GUI tools like 
fwbuilder to do things GUI style.  I've had some performance issues on 
iptables though when the data starts moving fast, but those are likely 
due to the slow machine I use it on (P133) and/or the old kernel and 
iptables implementation I'm using (needs upgrade really bad).

- Jim

Ray P wrote:

> You sure got a whole bunch of good opinions with such a short 
> question. :-)
>
> As always, the answer is that it depends on what you need to do. If 
> you need a basic firewall and you have no bucks, go PIX. If you need 
> secure remote access as well (built-in personal firewall, ability to 
> deny access based on the computer configuration, AD interoperability, 
> etc.) go Check Point (or buy additional Cisco products to gain the 
> same capability). If you are managing only one or two firewalls, go 
> PIX. If you're handling dozens or hundreds, go Check Point. If you 
> don't care about application-layer attacks against your 
> infrastructure, go PIX. If you think attacks against the applications 
> are the coming thing, go Check Point.
>
> There is no right or wrong answer. They both call themselves 
> "firewalls" but that's where the similarity ends. I suspect most 
> people would find a mix of both products would provide their operation 
> with optimal protection.
>
> And like all products, implementation and configuration errors can 
> turn either one into Swiss Cheese.
>
> Ray
>
>> From: "Darkslaker" <rienzi@...rod.com.mx>
>> To: full-disclosure@...ts.netsys.com
>> Subject: [Full-Disclosure] PIX vs CheckPoint
>> Date: Tue, 29 Jun 2004 13:24:05 -0500 (CDT)
>>
>> i am studying for the CCSA and my Friend for CSPFA in the interchange of
>> ideas we did not find differences significant; maybe two ; PIX run in OS
>> for CISCO and CheckPoint in many platforms;  and checkPoit have more
>> products.
>>
>> My question is PIX or Checkpoint what is better and why.
>>

-- 
+---------------------------------------------------------------------------+
|         Jim Burwell - Sr. Systems/Network/Security Engineer, JSBC         |
+---------------------------------------------------------------------------+
| "I never let my schooling get in the way of my education." - Mark Twain   |
| "UNIX was never designed to keep people from doing stupid things, because |
|  that policy would also keep them from doing clever things." - Doug Gwyn  |
| "Cool is only three letters away from Fool" - Mike Muir, Suicyco          |
| "..Government in its best state is but a necessary evil; in its worst     |
|  state an intolerable one.." - Thomas Paine, "Common Sense" (1776)        |
+---------------------------------------------------------------------------+
|   Email:  jimb@...c.cc                              ICQ UIN:  1695089     |
+---------------------------------------------------------------------------+
|  Reply problems ?  Turn off the "sign" function in email prog.  Blame MS. |
+---------------------------------------------------------------------------+



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ