From: Dario Ciccarone (dciccaro) (dciccaro@cisco.com)
Date: Sat Sep 03 2005 - 23:01:25 EDT
Putting the device in question behind the firewall isn't going to help
him with DoS attacks - unless those attacks are due to malformed
packets, _and_ the firewall in question drops the type of malformed
packets that would trigger the DoS.
I'm not familiar with the Contivity boxes, but I will use the Cisco
VPN3K device as an example (Cam, extrapolate :)). VPN3K devices support
remote access and site-to-site VPNs, and some of the protocols it uses
(for VPNs and/or management) are:
* PPTP (1723/TCP, GRE)
* IPSec (500/UDP, 4500/UDP, Proto 50 ESP - AH not supported,
additional TCP/UDP port for 'Ipsec-thru-NAT' as defined by the user)
* SSL VPN (443/TCP)
* HTTPS management over 443/TCP
* SSH (management)
* telnet or telnet over SSL (management)
* ICMP (ping, anyone ? :)
* RADIUS, LDAP, etc for communication to external auth servers.
So, we're looking at a VPN device which, as I understand from Cam's
email, is sitting parallel to the corporate firewall. If we think of a
simple setup, using one interface (the external) to accept encrypted
traffic, and one (internal) to forward decrypted traffic towards the
internal network, we have many scenarios:
* external interface parallel to firewall, internal parallel to
firewall
* external on DMZ, internal parallel
* external parallel, internal DMZ
* external DMZ, internal _another_ DMZ
What would be the value of having the external interface on the DMZ? It
depends. If using only UDP and ESP as VPN protocols, we're talking about
two protocols the firewall can't make _huge_ decisions about - can't
look into ESP, UDP can only allow to go thru. So we're talking about
stateless analysis - for this, I would prefer to deploy an ACL on the
border router, only allowing ESP and 500/UDP, 4500/UDP to the VPN
external interface. If using SSL VPNs, it may make more sense to have
the external interface on a DMZ - firewall can check SEQ numbers, 3-way,
session teardown, etc. Now, the firewall could also filter ICMP and/or
rate-limit it (if the firewall provides that feature) - the router can
also do it. All in all, no great value to have the external interface on
a DMZ.
Having the internal interface on a DMZ makes a little more sense. As I
understand from Rodrigo's email, the Contivity box can filter traffic
once decrypted - which is good. The problem is that we're now
maintaining two separate set of filtering rules - one on the firewall,
another on the VPN device. It looks less error-prone, easier to maintain
to me, to do all filtering on the firewall - let the VPN device do what
it does best :). So, in this case, it makes sense to me to have the
internal network interface on a DMZ interface.
Finally, having the internal network interface on a firewall DMZ will
also allow the firewall to only allow traffic from the VPN device to the
RADIUS/LDAP server, and would also filter traffic from the inside
network to the VPN device for management (being it
ssh/telnet/https/whatever), protecting the VPN device from internal
would-be hackers.
Thanks,
Dario
> -----Original Message-----
> From: Rodrigo Blanco [mailto:rodrigo.blanco.r@gmail.com]
> Sent: Saturday, September 03, 2005 7:05 AM
> To: camfischer@gmail.com
> Cc: pen-test@securityfocus.com
> Subject: Re: Nortel Contivity 2600
>
> Hello,
>
> I would think of DoS at first (certain versions of the Conctivity have
> DoS vulnerabilities).
>
> Although its VXworks architecture seems very robust, it does not look
> right to me to have a VPN concentrator directly accessible on the
> Inernet, why not place it in a DMZ (firewall protection makes sense,
> and so does IDS/IPS)?
>
> By the way, bear in mind Contivity also has a firewall module that can
> run on its same platform, this could be very reccomendable if you are
> to place it directly on the Internet.
>
> Hope this helps,
> Rodrigo.
>
> On 9/1/05, Cam Fischer <camfischer@gmail.com> wrote:
> > Hi list!
> >
> > I am looking for good reasons why I should move a Nortel Contivity
> > 2600 VPN device behind a firewall.
> >
> > Currently the device sits on the internet, and is used for
> VPN traffic
> > from other offices, and also for VPN dial-in users.
> >
> > Are there any risks with this configuration? What comments
> can be made
> > around whether or not I should be placing this behind the firewall /
> > IDS....
> >
> > Thanks!
> >
>
> --------------------------------------------------------------
> ----------------
> Audit your website security with Acunetix Web Vulnerability Scanner:
>
> Hackers are concentrating their efforts on attacking
> applications on your
> website. Up to 75% of cyber attacks are launched on shopping
> carts, forms,
> login pages, dynamic content etc. Firewalls, SSL and
> locked-down servers are
> futile against web application hacking. Check your website
> for vulnerabilities
> to SQL injection, Cross site scripting and other web attacks
> before hackers do!
> Download Trial at:
>
> http://www.securityfocus.com/sponsor/pen-test_050831
> --------------------------------------------------------------
> -----------------
>
------------------------------------------------------------------------------
Audit your website security with Acunetix Web Vulnerability Scanner:
Hackers are concentrating their efforts on attacking applications on your
website. Up to 75% of cyber attacks are launched on shopping carts, forms,
login pages, dynamic content etc. Firewalls, SSL and locked-down servers are
futile against web application hacking. Check your website for vulnerabilities
to SQL injection, Cross site scripting and other web attacks before hackers do!
Download Trial at:
http://www.securityfocus.com/sponsor/pen-test_050831
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:49 EDT