Re: auditing web/mail proxies

[Dion Stempfley <dtsonline () verizon net>]

On Dec 6, 2011, at 2:36 AM, Anders Thulin wrote:

> On 2011-12-05 10:21, cribbar wrote:
>
> > Has anyone ever audited a proxy during a pen test/IT audit or as an audit on
> > itself? If so do you have a scope of what kind of checks you reviewed, or a
> > checklist? 
>
>  An audit is intended to answer the question: does the examined system work
> according to the rules and regulations it should follow? The next question is,
> obviously, are there any such rules?
>
>  That should be answered by the organization owning or otherwise managing
> the proxy: what rules should be followed? These will typically relate to the
> management of the proxy: how is access controlled, how are changes implemented,
> how are logs and backups handled, and so on. (Tests of proper function -- quality
> testing -- is usually not regarded as part of an audit. That's more akin to
> penetration testing.)  The rules need not be expressed for the proxy specifically,
> they could be part of an IS or IT policy, applying to all IS or IT systems in
> the organization. And in some special cases, they might even take the form of
> local or national law.
>
>  For an audit, you job includes defining the system you are auditing (the word
> 'system' is used an a fairly general sense here -- it needn't be just a network 'box',
> but an entire proxy support and management -- don't forget helpdesk!), identify
> the rules that are relevant that system, and then verify that they are indeed being
> followed.
>
>  If there are no relevant rules, an audit cannot be done.  If the system cannot
> be strictly defined (in the sense of if some entity is part of the system or not),
> there will be difficulties later. Additionally, if there are rules, but they cannot be
> audited (quite often because they are imprecise), the only thing is to identify the
> problem, and suggest a remedy for the next audit.
>
>  There *are* usually best practice suggestions, which, in the absence of other
> requirements, could (barely) be used. But again, the system definition decides:
> are you looking at a proxy box only, or a component in a network, at a system
> that must be managed over it's lifetime, alone or in relation to other information systems
> of which it is considered a part?
>
>
>  'Muscular audits' ... deciding on your own what the rules are (or should be) is a
> possible way, technically, but it's so far from the accepted definition of an audit that
> I don't consider it practical.
>
> -- 
> Anders Thulin      anders.thulin () sentor se      070-757 36 10 / Intl. +46 70 757 36 10


All good advice.  Like Anders implied, without some detailed understanding of what the proxy is doing and why it's 
difficult to give anything specific.  But there are a few things I think about when testing a proxy or firewall. 

I look at the device at 3 levels:  can the proxy be attacked, does it properly protect and control access to the 
devices it is supposed to protect, and can it be used as a way to forward attacks to other systems that are not 
supposed to be protected.  

The first level is a pretty straight forward pen test against the device itself, management interfaces, device 
vulnerabilities, etc.  Keep in mind that a port scan isn't necessarily useful since the proxy will respond to a number 
of ports and not actually connect you to a service on the device.  It takes some finesse, but sometimes you can get 
useful data.  I usually find issues with management of the device to be the biggest problem.  

The second is more of a policy review, and is helpful in the larger pentest to access other systems.  Using the 
protocols that the device supports, can you break the proxy services to access protected systems (including listening 
services on the proxy).

The third is an architecture and system configuration review.  For example, if you can connect to the proxy from the 
outside and get it to access outside systems that's not generally a desirable situation.

Many people ask about scanning through a proxy to find things.  That's less of an assessment of the proxy and more of 
an assessment on the systems that are legitimately supported by the proxy.  It is very dependent on the technologies 
being used.

Ultimately, the whole thing comes down to the question of what you are trying to test for, which is derived from what 
is the purpose of the device.  You need to ask yourself a few more specific questions then, "how do I audit the proxy?"

/Dion 
------------------------------------------------------------------------
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
------------------------------------------------------------------------