On Sun, 31 Aug 1997, Frank Willoughby wrote:
> o The DMZ is just one leg of the firewall. A Firewall Penetration
> Test should performed on each interface of the firewall.
That depends on the security policy more than anything. Some places
allow all outbound traffic, and therefore, only concern themselves with
inbound results.
>
> o Depending on how the firewall's rules are set up, a set of exposures
> from the DMZ may be different than that of the firewall's external
> (Internet side) interface.
DMZ = Internet side, or it's not a DMZ, it's a protected segment, no
matter how public, private or little protection.
> Perhaps, but let's look at the possibilities:
> o If you are using the User->Firewall encryption or even the
> Firewall->Firewall encryption, and running the tools from your
> remote system to the firewall, then your test results may not
> be accurate. Some firewalls will pass encrypted sessions thru
> the firewall (tunneling) as it trusts the remote party.
I doubt you'd want to do encryption to the host you're testing. That
certainly skews the results.
> o If you wish, you can establish an encrypted tunnel to a system which
> the customer provides. The customer would then place the system on
> the outside and inside of the firewall. The problem here, is that you
> are expecting the customer to correctly install the system. They may
> indeed have this competence. But the problem is that *you* didn't set
> it up. Something may be misconfigured or may not work well enough for
> you to achieve accurate results. Also, how do you validate something
> you haven't seen yourself?
1 CD ROM, shipped to the customer.
> o You could send an attack system to the customer (@ $400-500 to ship)
CDs are much cheaper to ship than systems, and on-site work in our area
costs a lot due to high hotel fees which would negate your advantage
pretty quickly.
> Using part of a test in your reports for which you have no verification
> could taint the results. How do you know your attack system is correctly
By the results. If you're on the same segment, you can check the ARP
cache on the remote endpoint of the tunnel, other than that, all of the
packets will come back through the tunnel, so you can use the same
results. How do you *know* a switch port isn't VPNing you somewhere if
you're on-site? I can probably fool you as much in person as I can
remotely if we're not using just your hardware, and if we were, then
you're not auditing the complete setup, no? Any results can be tainted,
being there doesn't necessarily remove that possibility. Do you always
signal-test both ends of every cable when you're on-site? Do you
checksum switch and router sofware? There's a million ways a corrupt
admin or already compromised site can skew a test, if you're looking for
absolutes, then you're probably going to get very frustrated.
> Since we have no physical control over the system (during shipping and
> while onsite), there is also the possibility that the tools may be copied
> and used for unintended purposes (raising potential legal liability issues)
> or be used against the customer (if the attack system is stolen during
> shipping).
If your contracts aren't already protecting you from that, you're in need
of a *lot* of help.
> Actually, we do test flood protections. Dialup connections won't give
Flood protection can be tested with spoofed source addresses, so the
issue there is pretty moot. Most flood attacks have that signaure
anyway, and if you're not doing that, then you aren't fully testing the
robustness of the stack, since multiple source addresses are a lot more
resource grabbing than packets from a single address.
> Good point. But OTOH, we don't need to add fuel to the fire either.
> As InfoSec consultants, we need to be discreet. Testing across the
> Internet isn't very discreet.
If it's a target, it's a target, and there's not a lot of difference
between a test and an attack, so I'm unsure how much that raises the bar.
Packets don't necessarily scream "I'm not a new VPN application", or
"This is a good-guy test, not a bad-guy probe".
> Assuming they are running one of the popular scanners, the report will
> be finished in @15 minutes. When we do the testing onsite, the customer
> is there with us and sees the results in real time. Once the firewall
> passes the tests, only *then* will the firewall be put on line.
That's only useful in situations where the firewall isn't already up.
I'd hazard to guess that in most cases it's more useful to be able to do
recurring audits than preliminary work. I also would have guessed that a
consultant would want that business more than the one-time stuff.
> >And mostly moot, the majority of connections are small enough that they
> >can be flooded further back in the path, smurf.c is a prime example of
> >that working at provider's peering routers even.
>
> I disagree. The test is being performed against the firewall - not
> the various and sundry components of the Internet over which the
> customer has no control. The firewall *should* be capable of handling
> the most prevalent attacks. Some problems are the result of inherent
> design problems in TCP/IP and there is little the firewall vendors can
> do to prevent these problems.
But if it's based on a D-O-S attack, there's not a whole bunch of value
to certifying the fact that the bastion isn't vulnerable if the next
upstream hop is always vulnerable. In either case, the site is down and
the attack succeeds. Vendors can address most of the flaws, and some
have, others haven't.
> But the company may not *yet* be under attack. Remote testing draws
> unnecessary attention to the customer's firewall and may provide the
> attacker with some information which they ordinarily wouldn't receive.
Which, if it's done to fix the problems should be moot fairly quickly.
Also, it shows that someone is watching packets into and out of the
network, and most of the bad guys probably don't want to go near a
network that probably has a sniffer sitting there logging the evidence,
along with someone who knows how to interpret it analyzing the results.
> >On-site gives you physical access, and if I'm not auditing physical
> >access, then I may require that you do the penetration testing remotely.
>
> That's OK. We either do it right, or not at all (& we don't charge
> extra for doing it right). 8^) I'm not going to sign off that
> something is secure unless I have verified it myself.
>
> Regarding physical access... you could have a bullet-proof firewall
> which is correctly configured and have a rock-solid network security
> design. However, if the firewall is sitting in an open area and
> someone reconfigures the firewall to pass all services (perhaps
> because someone forgot to use a screensaver) or someone *steals*
> the firewall, then the firewall was never properly secured IMO.
> I'm not about to walk into that landmine.
By the same token, if the firewall is in a secure area, I may not want
short-term consultants in that area. For all I know, you're bringing in
stuff to grab signals off of the *other* sensitive equipment in that
area, leaving diskettes in the servers, and all kinda of dastardly things
that even complete dilligence on the part of the escort won't turn up.
> Another thing is to check references (customers & character). Just
> keep in mind that hackers who have set themselves up as consultants
> will also have customers. But what about the ethics? If you have
> 10 problems & the hacker writes up only 9 in the report.... 8^(
References are very hard to check in this industry unless someone has a
specific well-known name, which may be the opposite of the requirements
of thier last employer. There's no central registry of folks who used
to do good stuff for [pick an agency that needs good stuff]. A company
*can't* say why a former employee was terminated without the threat of rather
large lawsuits, and even the government, with its vast background-checking
resources misses things during SBI and EBI investigations, so a couple of
phone calls aren't much assurance. In an industry where it's very
difficult to hire your own resources (not to mention expensive),
outsourcing should be looked at with even more paranoia than normal.
Regards,
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts @
clark .
net which may have no basis whatsoever in fact."
PSB#9280
|
|
