Re: [fw-wiz] risk level associated with VPNs?

From: Shimon Silberschlag (shimons_at_bll.co.il)
Date: 02/07/05

  • Next message: Richards, Jim: "RE: [fw-wiz] risk level associated with VPNs?"
    To: <rlmieth@arcol.org>, <avishai_w@yahoo.com>, <firewall-wizards@honor.icsalabs.com>
    Date: Mon, 7 Feb 2005 10:38:56 +0200
    
    

    I tend to agree with Avishai, for the reasons he described and for another
    reason: running the VPN code on the border FW proved vulnerable in the past.
    Various FW manufacturers have had in the past problems in the code that
    handles the VPN connections (IKE and ASN.1 in particular) that enabled an
    attacker to take over the FW. If it was done in a separate DMZ, you can
    still control what the 0wned machine does.

    Shimon Silberschlag

    +972-3-9351572
    +972-50-7207130

    ----- Original Message -----
    From: <rlmieth@arcol.org>
    To: <avishai_w@yahoo.com>; <firewall-wizards@honor.icsalabs.com>
    Sent: Saturday, February 05, 2005 6:27 PM
    Subject: RE: [fw-wiz] risk level associated with VPNs?

    Dear Avishai,
    Though your scenario may add a level of security, in practice it may
    introduce certain inefficiencies in the system which would prove
    unnecessary. The reason for the VPN is to establish a trusted WAN link. As
    IPS, IDS and log analysis are necessary in both circumstances; it does not
    appear to make that much of an impact to call for such a move. I would be
    very interested in hearing other opinions as well.

    Lindsay Mieth
    AGS, LC.
    Av. Morones Prieto #791 pte.
    San Pedro, Garza García
    66230 NL México
    52 81 81149790 (tel/fax) / 52 81 80636252 (cel 1) / 52 81 12127982 (cel 2)

    -----Original Message-----
    From: Avishai Wool [mailto:avishai_w@yahoo.com]
    Sent: Thursday, February 03, 2005 16:55 PM
    To: firewall-wizards@honor.icsalabs.com
    Subject: [fw-wiz] risk level associated with VPNs?

    Dear all,

    While doing firewall policy analyses for customers,
    I very often come across rules that allow
      any ip traffic
      from anywhere outside the primeter
      into big portions of the inside networks
    but over a VPN link (i.e., encrypted & authenticated).

    let's put aside the question of whether the authentication is
    sufficient, and assume that nobody is cracking the passwords.
    I tend to trust the encryption and believe that noone can snoop
    the traffic in flight.

    My claim is that these rules are very risky and a wonderful
    vector for all kinds of malware. All those home
    computers, laptops on the road etc, are much more at risk
    of infection than inside computers are. Plus the VPN has the
    nice side-effect that filters can't see though the encryption
    and control (or even log) where the connection is going
    and what it is doing.

    Left to my own devices, I would recommend terminating the VPNs
    in a DMZ, and putting all the usual controls (anti-virus/mail filter/etc)
    between the DMZ and the inside, and I would flag these raw VPN connections
    as risky, maybe even very risky.

    However, customers uniformly disagree with this argument, and tell me that
    "traffic coming over a VPN is not perceived as a risk so shut up
    about it."

    Thoughts anyone?
    Any credible war stories about malware/abuse traveling over VPNs?
    Or are the customers right and I'm being paranoid?
     (please don't respond that "the customer is always right" :-)

    Thanks,
      Avishai

    =====
    Avishai Wool, Ph.D.,
    http://www.algosec.com http://www.eng.tau.ac.il/~yash
    yash@acm.org Tel: +972-3-640-6316 Fax: +972-3-640-7095

    __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


  • Next message: Richards, Jim: "RE: [fw-wiz] risk level associated with VPNs?"

    Relevant Pages

    • Re: Need help setting up remote desktop.
      ... The reason I wanted to use the web based method is that I wanted to temporarily ... those folders, the way I can with the people who are on the home network (D-Link ... If you want a secure way to transfer files to/from your son's PC and/or your PC you could use a Virtual Private Network (VPN) or Secure Shell connection. ... Remote Desktop or VNC are basically remote access/control programs for taking control of a remote PC. ...
      (microsoft.public.windowsxp.network_web)
    • Re: Using VPN, loose conectivity with exchsrv
      ... everything was setup just the same as I do now, but for some reason the OS ... ping the exchsrv. ... John Flint ... If you're connected via VPN, ...
      (microsoft.public.win2000.networking)
    • Re: remote office vpn products
      ... was there a reason for using two ... Was your Netopia at your central office and the Sonicwall ... >Linksys products. ... >The VPN built into SBS2003 out preformed the Netopia ...
      (microsoft.public.windows.server.sbs)
    • Re: AD site to site replication
      ... This would be a problem if you lose the VPN. ... In native mode, you need a GC ... > there a valid reason why we need a DC at each jobsite. ...
      (microsoft.public.win2000.active_directory)
    • Re: netgear VPN/Router
      ... If you have a Router-Router config giving you in effect a permanent ... that allows you to VPN from remote clients at the 'remote' ... >> need to run the MS client in order to connect to the SBS box. ... The reason that you can't get access from the outside ...
      (microsoft.public.backoffice.smallbiz)

    Loading