Send firewall-wizards mailing list submissions to
firewall-wizards@honor.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@honor.icsalabs.com
You can reach the person managing the list at
firewall-wizards-admin@honor.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. RE: Opinion: Worst interface ever. (Eugene Kuznetsov)
2. wifi signal teft, first documented case (R. DuFresne)
3. Discretionary WiFi Access (Dave Null)
4. (no subject) (Spearman, William CONT (FISC YOKO))
5. Re: Discretionary WiFi Access (John Adams)
6. Re: Discretionary WiFi Access (vbwilliams@neb.rr.com)
7. Re: Discretionary WiFi Access (Sp0oKeR Labs)
8. Re: Discretionary WiFi Access (Kevin)
9. RE: (no subject) (Ben Nagy)
10. RE: Discretionary WiFi Access (Jose Varghese)
--__--__--
Message: 1
From: "Eugene Kuznetsov" <eugene@datapower.com>
To: "'Paul D. Robertson'" <paul@compuwar.net>
Cc: <firewall-wizards@icsalabs.com>
Subject: RE: [fw-wiz] Opinion: Worst interface ever.
Date: Thu, 7 Jul 2005 11:02:12 -0400
> One of my coworkers had the same issue, so I'm guessing that
> it's not all
> that intuitive where that turn was.
I wasn't insisting it's intuitive, but it's probably intuitive for some
subset of users. In the end, most vendors don't purposefully make their
products worse.
> I'm really starting to dislike the "interface can't run locally on the
> device" stuff when coupled with "won't log on the device."
Yeah, I've never understood the "requiremes management server or thick
client to be useful" approach.
> > So take this as a vendor perspective: it's not easy,
> especially since
> > customer requirements are increasingly diverging. More
> features --> more
> > complexity.
>
> Hey, I didn't ask for more features, someone's marketing
> department did!
No, probably some other set of users did (just not the same kind of user as
you). ... Or maybe a competitor came out with a bunch of new features, got a
good review in ___ Magazine, and so they had to follow.
> I'm also going to add a new vendor test to my criteria- if I can't get
> read-only access to the support site without a login, that
> vendor's off my
> list.
You know why vendors don't do this? It's not because they are evil. It's
because the moment you put something on your website, your dozen competitors
immediately download and copy it, down to the diagram colors. Of course,
once they do -- and everyone has the same features, at least in the UI --
your next release has to add new ones to differentiate! Which confuses the
poor user, who then wants to have unauthenticated access to all the support
information.
\\ Eugene Kuznetsov, Chairman & CTO : eugene@datapower.com
\\ DataPower Technology, Inc. : Web Services security
\\ http://www.datapower.com : XML-aware networks
--__--__--
Message: 2
Date: Thu, 7 Jul 2005 12:31:00 -0400 (EDT)
From: "R. DuFresne" <dufresne@sysinfo.com>
To: "'firewall-wizards@honor.icsalabs.com'" <firewall-wizards@honor.icsalabs.com>
Organization: sysinfo.com
Subject: [fw-wiz] wifi signal teft, first documented case
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://www.cnn.com/2005/LAW/07/07/wi.fi.theft.ap/index.html
Thanks,
Ron DuFresne
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCzVjJst+vzJSwZikRArZnAJ9IThpXWHFmvu84VvpPp7bkQc/hOQCggJKE
yUp88Nt6mf/1eMxehLC2KVk=
=yhib
-----END PGP SIGNATURE-----
--__--__--
Message: 3
Date: Thu, 7 Jul 2005 13:46:38 -0700
From: Dave Null <noid23@gmail.com>
Reply-To: Dave Null <noid23@gmail.com>
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] Discretionary WiFi Access
Its not firewall related, but there's some smart minds on this list.
My company has started looking into campus-wide WiFi. I'll keep my
personal feeling on this to myself though. One thing that keeps
comming up is that one of the largest user communities that would take
advantage of this would be non-employees. Vendors, Salesmen, people
meeting with GMs/VPs/Execs are probably going to be the main users of
this. My question is, if you currently have a similar situation in
your work environment, how do you handle granting these people
temp/guest WiFi access.
Access controls for employees can be fairly stringent (i.e. only
connect from company owned assets who's MAC is inventoried, use of 2
factor authentication, etc), but a lot of this isnt applicable for
temporary visitors. I know one company that would give you a WiFi card
when you signed in that was in their database of 'allowed' MAC
addresses (I know, dont get me started on MAC spoofing), however I
would bet cash money that those cards walked away regularly. Similar
thing with issuing a temporary token fob (SecureID or the like).
I know the easy answer here is 'Dont give them WiFi access', but I
don't think that is going to be an option. Thoughts, comments, flames?
-noid
--__--__--
Message: 4
Date: Fri, 8 Jul 2005 08:15:04 +0900
From: "Spearman, William CONT (FISC YOKO)" <William_W_Spearman@yoko.fisc.navy.mil>
To: "Wizards Firewall (E-mail)" <firewall-wizards@honor.icsalabs.com>
Subject: [fw-wiz] (no subject)
Wizards,
Sorry about the last post. Here it is (I hope) in plain text: (Thanks =
again Paul!)
I have a laptop running the subject VPN Client
I have a PIX 515E running in stateful failover mode with a VAC=20
I attempted to replace the VAC with a VAC+, and not having a brain in my =
head on a late Saturday night, I just pulled open the PIX and switched =
the cards. The remote access users then began to call. I've been working =
on this problem for a week and am at my wits end. I do keep good notes, =
and so reconfigured the VPN with exactly the same command set I had used =
originally with no success.=20
Here is a copy of the (sanitized) relevant portions of the PIX =
configuration:=20
ip address outside 12.34.56.78 255.255.255.X=20
ip address inside 34.45.56.67 255.255.255.X=20
#Note: The IP networks for access-list "split" and access-list =
"nonat_inside" are the same=20
access-list split permit ip 192.168.XX.0 255.255.255.0 192.168.X1.0 =
255.255.255.0=20
access-list nonat_inside permit ip 192.168.XX.0 255.255.255.0 =
192.168.X1.0 255.255.255.0=20
Note: Local pool "vpnpool1" includes addresses from the same subnet as =
configured in the access-lists above=20
ip local pool vpnpool1 192.168.X1.X-192.168.X1.X=20
nat (inside) 0 access-list nonat_inside=20
route outside 0.0.0.0 0.0.0.0 12.34.56.79 1=20
Many routing statements .......=20
route inside 192.168.X1.X 255.255.X.X 34.45.56.68 1=20
More Routing Statements .........=20
sysopt connection permit-ipsec=20
crypto ipsec transform-set standard esp-3des esp-md5-hmac=20
crypto dynamic-map clientvpn 10 set transform-set standard=20
crypto map map1 10 ipsec-isakmp dynamic clientvpn=20
crypto map map1 client authentication LOCAL=20
crypto map map1 interface outside=20
isakmp enable outside=20
isakmp identity address=20
isakmp nat-traversal 20=20
isakmp policy 10 authentication pre-share=20
isakmp policy 10 encryption 3des=20
isakmp policy 10 hash md5=20
isakmp policy 10 group 2=20
isakmp policy 10 lifetime 5000=20
vpngroup GroupName address-pool vpnpool1=20
vpngroup GroupName dns-server domain-controller=20
vpngroup GroupName wins-server domain-controller=20
vpngroup GroupName default-domain domain.name=20
vpngroup GroupName split-tunnel split=20
vpngroup GroupName idle-time 1800=20
vpngroup GroupName password ********=20
username someuser password somepassword encrypted privilege 2=20
I get good ISAKMP packet trades, good DPD packets, actually a good =
connection to the VPN from the remote (as seen in the debug crypto ipsec =
and isakmp output on the PIX). All indications from the client log are =
that everything is copasetic. Then I look at the syslog output and see:=20
%PIX-6-302013: Built inbound TCP connection 3062304 for =
outside:192.168.X1.X/2728 (192.168.X1.X/2728) to inside:192.168.X2.X/22 =
(192.168.X2.X/22)
Jul 8 08:08:57 172.16.1.1 Jul 08 2005 08:08:57 boukap : %PIX-3-106011: =
Deny inbound (No xlate) tcp src outside:192.168.X2.X/22 dst =
outside:192.168.X1.X/2728
The first packet is the SYN, the second says "no xlate tcp src outside =
dst outside"??? The first ip is the internal address and the second is =
the VPN Client address. I looks like the VPN is initialized, but the =
packets from the client are being sent OUTSIDE the pipe! AAAHHHHH! What =
am I missing here? Thoughts, suggestions, more info required?=20
Arigato Gozaimasu
--__--__--
Message: 5
Date: Thu, 7 Jul 2005 18:16:08 -0700 (PDT)
To: Dave Null <noid23@gmail.com>
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Discretionary WiFi Access
From: John Adams <jna+dated+1121217368.5d89bc@retina.net>
On Thu, 7 Jul 2005, Dave Null wrote:
> Its not firewall related, but there's some smart minds on this list.
> My company has started looking into campus-wide WiFi. I'll keep my
The way I see it, you've got three options if you want to run wireless:
1) Open Internet Access, where the APs terminate access outside the
firewall (or on a seperate leg of the firewall). Corporate users have
to use a VPN to get into the corp. network. This is what many large
companies with campus-wide networks do. Pretty easy to implement with
commercial VPN or Windows VPN solutions.
2) No access to network at all without network authentication (802.1X /
TTLS / EAP / MSv2CHap or PAP.) No one gets in unless they authenticate,
and even then, there's different levels of authentication for different
sections of the network. Hard to implement, but worth it in the end.
3) Same as #2, but you create a 'guest' account for Network Authentication
with limited access. I don't like this one, and few admins do, but it
keeps interlopers off your net.
-john
--
J. Adams http://www.retina.net/~jna
--__--__--
Message: 6
Date: Thu, 07 Jul 2005 20:22:41 -0500
From: vbwilliams@neb.rr.com
Subject: Re: [fw-wiz] Discretionary WiFi Access
To: Dave Null <noid23@gmail.com>
Cc: firewall-wizards@honor.icsalabs.com
Reply-To: vbwilliams@neb.rr.com
Here's what I'd do:
Get a separate cheapo internet pipe; lowest-end DSL or the like, put a
wireless router/access point on it, no filtering.
When there are guests, they sign a simple waiver that says whatever
happens to their PC while they are on this *guest* network you aren't
liable/responsible for. Have your legal team make sure it's legit.
Problem solved. If management wants it, they better be able to accept
responsibility for it or fund it being done the *right* way.
----- Original Message -----
From: Dave Null <noid23@gmail.com>
Date: Thursday, July 7, 2005 3:46 pm
Subject: [fw-wiz] Discretionary WiFi Access
> Its not firewall related, but there's some smart minds on this list.
> My company has started looking into campus-wide WiFi. I'll keep my
> personal feeling on this to myself though. One thing that keeps
> comming up is that one of the largest user communities that would take
> advantage of this would be non-employees. Vendors, Salesmen, people
> meeting with GMs/VPs/Execs are probably going to be the main users of
> this. My question is, if you currently have a similar situation in
> your work environment, how do you handle granting these people
> temp/guest WiFi access.
>
> Access controls for employees can be fairly stringent (i.e. only
> connect from company owned assets who's MAC is inventoried, use of 2
> factor authentication, etc), but a lot of this isnt applicable for
> temporary visitors. I know one company that would give you a WiFi card
> when you signed in that was in their database of 'allowed' MAC
> addresses (I know, dont get me started on MAC spoofing), however I
> would bet cash money that those cards walked away regularly. Similar
> thing with issuing a temporary token fob (SecureID or the like).
>
> I know the easy answer here is 'Dont give them WiFi access', but I
> don't think that is going to be an option. Thoughts, comments, flames?
>
> -noid
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>
--__--__--
Message: 7
Subject: Re: [fw-wiz] Discretionary WiFi Access
From: Sp0oKeR Labs <spooker@spooker.com.br>
To: Dave Null <noid23@gmail.com>
Cc: firewall-wizards@honor.icsalabs.com
Date: Thu, 07 Jul 2005 22:37:11 -0300
Some features with linux box
- ebtables
- snort
- nocat (authentication) http://nocat.net/
Regards,
Sp0oKeR
On Thu, 2005-07-07 at 17:46, Dave Null wrote:
> Its not firewall related, but there's some smart minds on this list.
> My company has started looking into campus-wide WiFi. I'll keep my
> personal feeling on this to myself though. One thing that keeps
> comming up is that one of the largest user communities that would take
> advantage of this would be non-employees. Vendors, Salesmen, people
> meeting with GMs/VPs/Execs are probably going to be the main users of
> this. My question is, if you currently have a similar situation in
> your work environment, how do you handle granting these people
> temp/guest WiFi access.
>
> Access controls for employees can be fairly stringent (i.e. only
> connect from company owned assets who's MAC is inventoried, use of 2
> factor authentication, etc), but a lot of this isnt applicable for
> temporary visitors. I know one company that would give you a WiFi card
> when you signed in that was in their database of 'allowed' MAC
> addresses (I know, dont get me started on MAC spoofing), however I
> would bet cash money that those cards walked away regularly. Similar
> thing with issuing a temporary token fob (SecureID or the like).
>
> I know the easy answer here is 'Dont give them WiFi access', but I
> don't think that is going to be an option. Thoughts, comments, flames?
>
> -noid
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
--__--__--
Message: 8
Date: Fri, 8 Jul 2005 02:58:34 -0500
From: Kevin <kkadow@gmail.com>
Reply-To: Kevin <kkadow@gmail.com>
To: Dave Null <noid23@gmail.com>
Subject: Re: [fw-wiz] Discretionary WiFi Access
Cc: firewall-wizards@honor.icsalabs.com
On 7/7/05, Dave Null <noid23@gmail.com> wrote:
> . . . one of the largest user communities that would take
> advantage of this would be non-employees. Vendors, Salesmen, people
> meeting with GMs/VPs/Execs are probably going to be the main users of
> this. My question is, if you currently have a similar situation in
> your work environment, how do you handle granting these people
> temp/guest WiFi access.
. . .
> I know the easy answer here is 'Dont give them WiFi access', but I
> don't think that is going to be an option. Thoughts, comments, flames?
So do what the coffee shops do -- give the outsiders low-speed "unrestricte=
d"
access to the Internet with little or no firewalling or access
control, and require
some sort of strong-authentication VPN for anybody who needs access to
more sensitive "internal" networks and services.
The coffee shops somehow avoid getting sued over file-sharing and spam
incidents from their "open" WiFi, so you should be no worse off than they.
Kevin Kadow
--__--__--
Message: 9
From: "Ben Nagy" <ben@iagu.net>
To: "'Spearman, William CONT (FISC YOKO)'" <William_W_Spearman@yoko.fisc.navy.mil>,
"'Wizards Firewall (E-mail)'" <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] (no subject)
Date: Fri, 8 Jul 2005 10:34:26 +0200
I'm not sure. However...
> -----Original Message-----
>[...]
> access-list nonat_inside permit ip 192.168.XX.0 255.255.255.0
> 192.168.X1.0 255.255.255.0
[...]
> ip local pool vpnpool1 192.168.X1.X-192.168.X1.X
[...]
> nat (inside) 0 access-list nonat_inside
All good so far - don't NAT traffic going from inside to 192.168.X1.X, which
are the external VPN pool addresses.
[...]
> route inside 192.168.X1.X 255.255.X.X 34.45.56.68 1
Uh.. I may well be having a stupid day and it's a long time since I played
happy-pix-games, but why are you routing your VPN addresses to the
_internal_ interface?
ben
--__--__--
Message: 10
From: "Jose Varghese" <jose.varghese@paladion.net>
To: <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Discretionary WiFi Access
Date: Fri, 8 Jul 2005 18:18:45 +0530
Keeping it simple:Physical segregation and only Internet access
Provide access points ONLY at cafeterias and conference rooms. Have separate
L2, L3 devices for these access points and donor interface at any point with
the company LAN.Limit signal strength to within your premises.
Have a separate Firewall and provide outbound access, with standard gateway
controls like AV, URL filter .
---------------------------------------------
Some companies implement MAC-address-locking for guests. Give your driving
license and take a wireless card. U always remember to take your license
back.
Jose Varghese
Paladion Networks
Application Security Magazine
http://palisade.paladion.net
-----Original Message-----
From: firewall-wizards-admin@honor.icsalabs.com
[mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf Of Dave Null
Sent: Friday, July 08, 2005 2:17 AM
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] Discretionary WiFi Access
Its not firewall related, but there's some smart minds on this list.
My company has started looking into campus-wide WiFi. I'll keep my personal
feeling on this to myself though. One thing that keeps comming up is that
one of the largest user communities that would take advantage of this would
be non-employees. Vendors, Salesmen, people meeting with GMs/VPs/Execs are
probably going to be the main users of this. My question is, if you
currently have a similar situation in your work environment, how do you
handle granting these people temp/guest WiFi access.
Access controls for employees can be fairly stringent (i.e. only connect
from company owned assets who's MAC is inventoried, use of 2 factor
authentication, etc), but a lot of this isnt applicable for temporary
visitors. I know one company that would give you a WiFi card when you signed
in that was in their database of 'allowed' MAC addresses (I know, dont get
me started on MAC spoofing), however I would bet cash money that those cards
walked away regularly. Similar thing with issuing a temporary token fob
(SecureID or the like).
I know the easy answer here is 'Dont give them WiFi access', but I don't
think that is going to be an option. Thoughts, comments, flames?
-noid
_______________________________________________
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
End of firewall-wizards Digest
No comments:
Post a Comment