Re: (preparing for)Pentesting firewall /Checkpoint box

[Todd Haverkos <infosec () haverkos com>]

pent 5971 <pent5971 () gmail com> writes:
> Hi
>
> I would like to ask for your advice on something. Ill have a
> penetration test soon in the enterprise and im need of that nothing
> (configuration mistakes advices etc also) would be found on my
> Checkpoint R65 boxes (both on Windows and Secure Platform) . So what
> can you advice for me to prepare  and also how can i do a pentest to
> these boxes by myself?

I'd advise against fearing the paid pentest, or contribute to a "rubber
stamp" mentality in the company that'll undermine the value you can
get from a penetration test.  I can't recall who said it at which
defcon, but the quote was "People don't want to be secure.  They want
to have a rubber stamp that says they're secure."  Such a thought
really impairs improving things, so it's definitely a mindset to
avoid. 

What you should fear and prepare for, however, is the pen test you get
every day from people the company isn't paying, and who aren't under
contract to tell you everything they find and suggest how to fix it.

Following best practices in configuration from veteran admins of
similar hardware is probably the best approach if your
responsibilities are limited to the firewalls themselves.  I can't
offer you any Checkpoint R65 specific gotchas.  

If you want to try to perform a baseline of what may be part (but
certainly not all) of a quality penetration test, throwing a port
scanner like nmap at your external IP ranges with a variety of options
varying timing and scan type (SYN, full connect, ACK), covering all
65k ports for tcp and udp, protocol scans and ikescans, and seeing how
your firewall and logging that is visible to you responds can be
useful so you start knowing what portscan traffic looks like, and can
quickly identify it.  Also, depending on what a portscanner sees as
open, hopefully you won't have any surprises there in the results.

Then, maybe throw a vulnerability scanner like OpenVAS at live targets
in your IP range, and see how that lights up or doesn't in your logs
and sensors and what it finds.

Review your firewall rules and verify that your rulesets don't have a
"permit any/any" in an unfortunate place, and take a default deny
stance.  Manually review your rulesets to see if anything jumps out at
you as redundant, out of date, or opening unintended paths through the
firewall an attacker might leverage.  Patch your management software,
patch your firewalls.  Don't have administrative interfaces listening
on the internet or to the entire intranet.  Don't have a default
password or exceedingly lame password remaining on your administrative
interface.

If you have more latitude to dictate network architecture than most
firewall-dedicated admins, give egress filtering and proxying all
outbound traffic a thought, as it complicates remote callbacks in
comparison to networks that cheerfully let any traffic (like reverse
shells, reverse VNC tunnels, reverse what have you, arbitrary outbound
traffic destined for 443 or 80 somewhere) go out of the network.

If your phone rings or email chimes, make sure you're not too cheerful
a target for social engineering.  Make sure the firewall is in a
secured room/facility with controlled access, and not a door easily
bypassed via ceiling tiles or raised floor tiles, or slipping $100 to
a cleaning crew member.  Make sure the console isn't easily available
to any passer by.  If it's in a cage, think about whether someone
outside the cage might be able to work a usb key into the machine, or
just unplug the thing if it's too close to the cage edge.  Think about
processes by which firewall configs/rules get changed, and think of
any procedural loopholes a crafty attacker with a phone and a modicum
of gathered inside knowledge might try to exploit.

All these can help you improve the security posture of your slice of
the network with the added benefit of not making your stuff the low
hanging fruit of the environment.   

This is not an exhaustive list, but things to think about at least. 

--
Todd Haverkos, LPT MsCompE
http://haverkos.com/

------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT 
and CEPT certs require a full practical examination in order to become certified. 

http://www.iacertification.org
------------------------------------------------------------------------