Re: Best practices for internal/external servers

In article <8LGdnVl3NtgDQNLeRVn-hQ@xxxxxxxxxxxxx>, "wkearney99" <wkearney99@xxxxxxxxxxx> writes:
>> In this case they are already using dialup to get to the inside network.
>> There is no increase in risk (unless you are suggesting that they never
>ever
>> connect their clients to the internet except through dialup to work and
>> therefore can't be compromised).
>
>In the land of the theoretical there's certainly validity to that point.
>However, it's not explained how the current dial-up setup is configured or
>what it allows. A limited number of dial-in lines has the potential to be
>less of a security risk than does an inbound VPN. If only from the
>standpoint of limited resources. There's only so many people that'll bother
>wardialing anymore. Versus plenty of script kiddies port scanning VPNs (and
>IMAPS ports too I suppose)
>
>> Of course you would want a strict policy to keep their client machines
>upto
>> date with patches and anti-virus and running a personal firewall
>> (some VPN solutions available can now check this before allowing
>connection).
>
>Which assumes a degree of influence over the remote machines. If they're
>not company property it's unlikely. Even if they were, if they're out of
>direct control of the IT staff then it's reasonable to assume things will be
>installed on them that render them unsafe for VPN access.
>
>> On the other-hand poking holes through the firewall for IMAP access
>permits
>> anyone anywhere in the world to attempt to attack the IMAP server.
>> Even in recent years well known IMAP servers have had buffer overflow
>> weaknesses. Most of these are post-authentication but I'd hate to rely
>> on that for the future.
>
>So what's less of a risk? Exposing solely the IMAPS and SMTP ports or ALL
>of it via VPNs? If all they want is remote mail then it seems a far more
>reasonable solution to expose solely those services. Perhaps through an
>IMAP proxy. Then if a client machine is compromised the only thing it'll be
>able to do is distrupt things via mail traffic. If the client's compromised
>and has VPN access there's considerably more risk. And given the potential
>issues with the exposed IMAP daemons it's certainly worth being vigilant
>regarding their setup and use.
>
>I'm not saying VPNs don't have their use, they certainly do and I use one
>everyday. I'm merely suggesting simple firewall port rules and/or proxy
>instead. Provide what's requested and avoid increasing the larger security
>risks.
>

We'll probably have to agree to disagree since I see the VPN (and I'm talking
IPSEC based VPN here) as being the more secure option.
Your only objection to using VPN seems to be the risk of client compromise
but you state you are willing to use VPNs in some circumstances.
That doesn't make sense. The risk of client compromise will be there in all
circumstances. However the number of clients which could be compromised and
could be used to attack the network is going to be very limited.
On the otherhand the number of systems able to attack a buffer overflow
vulnerability in IMAP is equal to the number of systems on the internet.
(VPN is not so vulnerable since in order for any traffic to get through it must
have completed all phases of the IPSEC authentication).

(I'm ignoring IMAP proxy solutions in the above comparison since I have no
knowledge of such systems).




David Webb
Security team leader
CCSS
Middlesex University


>-Bill Kearney
>
.

Relevant Pages

  • Re: [fw-wiz] VPN endpoints
    ... > 1) Some VPN products default to allowing the Null encryption algorithm. ... The cost of compromise is a function of the risk that the data may be ... > most of the benefits are in the fact that practically any client can be ...
    (Firewall-Wizards)
  • Re: Best practices for internal/external servers
    ... less of a security risk than does an inbound VPN. ... > anyone anywhere in the world to attempt to attack the IMAP server. ... I'm merely suggesting simple firewall port rules and/or proxy ...
    (comp.mail.imap)
  • [NEWS] Cisco VPN 5000 Client Multiple Vulnerabilities
    ... Multiple vulnerabilities exist in the Cisco Virtual Private Network (VPN) ... 5000 Client software. ... These vulnerabilities are documented as Cisco bug ID ... CSCdx17109 - MAC OS VPN 5000 Client password vulnerability ...
    (Securiteam)
  • Re: VPN clients unable to connect to other resources.
    ... gateway matches the IP of the remote client, and DNS and WINS point to the ... remote (although it takes close to a minute to connect, ... This is just regular Windows VPN, ... VPN server, remote routing and access running on the SBS 2003 server ...
    (microsoft.public.windows.server.sbs)
  • RE: Slow VPN logon and Spuratic folder visibility
    ... I understand that the remote VPN client ... network configuration. ... the VPN client can access SBS fine? ... Slow VPN logon and Spuratic folder visibility ...
    (microsoft.public.windows.server.sbs)