Re: [fw-wiz] Securing a wireless network

From: Michael H (
Date: 10/29/04

  • Next message: Pete Lindstrom: "RE: [fw-wiz] Re: Ethics, morality, and mental retardation"
    Date: Fri, 29 Oct 2004 12:33:51 -0700

    This is essentially what we are doing. We have the WAP in a DMZ (on an
    OpenBSD fw) that only allows the MS ports to VPN to our network. Users
    authenticate witih their same Windows account and any scripts you want to
    run are part of our standard log in scripts.

    >From: Claudiu Dragalina-Paraipan <>
    >Reply-To: Claudiu Dragalina-Paraipan <>
    >Subject: Re: [fw-wiz] Securing a wireless network
    >Date: Fri, 29 Oct 2004 09:41:51 +0200
    >you could use VPNs. What I would do is this:
    >- set a VPN server, my choice would be FreeBSD or OpenBSD, for what I
    >think that are obvious reasons;
    >- on the client side, which I assume uses Windows, you can use the VPN
    >client that comes with Windows (2000, XP), or get one for older
    >version from Internet;
    >- back to the server, you should NAT/pass only IPs that come through
    >the VPNs, while the other http traffic can be redirected to an
    >instruction page.
    >This way you have almost what you want. You still can use DHCP to give
    >IPs to new clients, but allow only connections to Internet from IPs
    >used for VPNs. If you put your networks servers behind this "vpn
    >server", you can filter connections to them also.
    >This is not exactly what you want, but is far more secure then what
    >you have already.
    >Probably you can make a general user for VPNs, thus you don't have to
    >provide everyone with a user and password.
    >I hope this helps you.
    >Best regards,
    > Claudiu.
    >On Thu, 28 Oct 2004 20:14:05 -0400,
    ><> wrote:
    > > At my so-called place of business, there exists a completely insecure
    >public wireless network that I wish to lock down (ignoring WEP, Radius, and
    >other wireless security methods).
    > >
    > > I am looking for a means of forcing 'unverified' clients (by MAC
    >address?; not at all worried about spoofing) to run a script or program of
    >some sort before being able to interface with other network devices (to
    >scan for viruses, check software configuration, and whatever else). The
    >best bet at the moment seems to include VLAN's and some sort of destination
    >NAT to a generic web server that says "hey, run this!", but I'm having
    >trouble finding literature on the subject. Partly because I'm not entirely
    >sure what I'm looking for.
    > >
    > > The general idea:
    > > - unknown client connects to network and obtains IP from DHCP
    > > - client opens web browser, and is redirected to some generic page with
    > > - client follows instructions, runs script
    > > - <slightly hazy with a chance of rain>
    > > - client is assigned new [IP|VLAN|something else] and is able to connect
    >to the rest of the network
    > >
    > > Currently, the network (entirely Cisco) is setup as follows:
    > >
    > > - Backbone: Cisco Catalyst 6509 multilayer switch
    > > - Closets: various models of manged Catalyst switches running an
    >enterprise IOS version
    > > - Access Points: Cisco Aironet AP350's and 1120's
    > >
    > > Can anyone point me in some direction or offer a different solution? My
    >idea is not to authenticate clients and reject unknown users; the idea is
    >to force users to have semi-secured computers while maintaining an
    >otherwise open network.
    > >
    > > I would prefer a solution that requires the least amount of changes to
    >the backbone switch (because all requests regarding it have to be forwarded
    >to dept. A, which sends it to B, then C, and yadda yadda yadda; 5 years
    >later, it *might* get done), but I'm open to any possibilities.
    > >
    > > Thanks in advance,
    > >
    > > - Chris Carlson
    > >
    > > นนนนนนนบบบบบบบบบบบบบบบบบบบบบบบน
    > > * "First they ignore you, then they laugh at you, then they
    > > fight you, then you win." ~Mahatma Ghandi
    > >
    > > _______________________________________________
    > > firewall-wizards mailing list
    > >
    > >
    > >
    >Claudiu Dragalina-Paraipan
    >firewall-wizards mailing list

    firewall-wizards mailing list

  • Next message: Pete Lindstrom: "RE: [fw-wiz] Re: Ethics, morality, and mental retardation"

    Relevant Pages

    • 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 ...
    • Re: Outgoing VPN Error 619
      ... Outbound VPN problem: ... Q1 - is the test client configured as SecureNET? ... Q2 - what do you find in the ISA logs for your tests? ... I've checked in local network rules and I do have a rule called VPN clients ...
    • Re: VPN issues on SBS2003 with ISA 2004 installed
      ... Based on our work above, it seems the problem in client side, so I suggest ... and then click the Network and Dial-up ... Right-click the VPN connection that you want to change, ...
    • Re: VPN clients unable to connect to other resources.
      ... on the SBS 2003 server just not sure where to go for help on it. ... Next time I'm at my home PC, I'll VPN in and see what IP info I'm getting ... client PC on your LAN, you should be able to do so from a remote VPN client, ... get the network path was not found. ...
    • Re: [Full-disclosure] Remote Desktop Command Fixation Attacks
      ... This set of steps is redundant in many places, and it's also enormously expensive, since you're using no less than three different expensive bits of networking hardware (AP, PIX, VPN Concentrator), in addition to a bunch of x86 server hardware, windows server licenses, and at least one ISA license. ... Your computers necessarily don't have full access to your network infrastructure when they aren't logged on, so GPOs, software updates, etc can't be applied at the times you want them to be applied. ... Turning on, enabling, and implementing every possible security setting and device you think of is not defence in depth, and will probably only have two effects - your users won't use your wireless network, and you'll burn so much cash you won't have any left to spend on *useful* security measures. ...