Penetration Testing mailing list archives
Re: (preparing for)Pentesting firewall /Checkpoint box
From: Todd Haverkos <infosec () haverkos com>
Date: Tue, 18 Aug 2009 15:16:41 -0500
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 ------------------------------------------------------------------------
Current thread:
- (preparing for)Pentesting firewall /Checkpoint box pent 5971 (Aug 18)
- Re: (preparing for)Pentesting firewall /Checkpoint box Francois Yang (Aug 18)
- Re: (preparing for)Pentesting firewall /Checkpoint box ml10024 (Aug 18)
- Re: (preparing for)Pentesting firewall /Checkpoint box Wim Remes (Aug 19)
- Re: (preparing for)Pentesting firewall /Checkpoint box Todd Haverkos (Aug 18)
- Re: (preparing for)Pentesting firewall /Checkpoint box David Howe (Aug 19)
- RE: (preparing for)Pentesting firewall /Checkpoint box Gorgon Beast (Aug 19)
- Re: (preparing for)Pentesting firewall /Checkpoint box JiPi DiNi (Aug 19)
- Re: (preparing for)Pentesting firewall /Checkpoint box Matt Gardenghi (Aug 19)