Penetration Testing
auditing web/mail proxies Dec 05 2011 09:21AM
cribbar (crib bar hotmail co uk) (3 replies)
Re: auditing web/mail proxies Dec 13 2011 05:06PM
White Hat (whitehat237 gmail com)
Re: auditing web/mail proxies Dec 11 2011 12:54AM
Brian Quick (brian e quick1 gmail com) (1 replies)
Re: auditing web/mail proxies Dec 12 2011 07:38AM
A. Ramos (aramosf gmail com)
Re: auditing web/mail proxies Dec 06 2011 07:36AM
Anders Thulin (anders thulin sentor se) (2 replies)
Re: auditing web/mail proxies Dec 06 2011 07:42PM
Justin Rogosky (jrogosky gmail com)
Re: auditing web/mail proxies Dec 06 2011 09:54AM
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 (at) sentor (dot) se [email concealed] 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
------------------------------------------------------------------------

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus