Re: Guest wireless restrictions

[David Curry <david.curry () NEWSCHOOL EDU>]

The short answer is, we're probably not going to do anything for those
sites, unless we get lots and lots of requests (or the university president
starts using them :-). I didn't mean to imply, when I wrote "no plaintext,"
that we were expecting (or even trying) to keep unencrypted traffic off the
network. All I meant was that we're not going to open up the "plaintext"
(non-SSL) ports for these services.

The devices we mostly see on the network today doing POP/IMAP are phones.
As far as I know, neither iOS nor Android support STARTTLS in POP/IMAP,
they use the SSL-ified versions of those services. If that changes in the
future, I suppose we would just open those ports back up. We're not
planning to open up XMPP at all, so we don't care about that. And for port
587, it's "supposed" to be STARTTLS, but we're not actually going to check
(just as we're not going to check for SSL on the other ports). The main
thing there is we're not opening up port 25.

At the end of the day, we're trying to offer a convenience service for most
of our guests, for the hour or two that they're on campus, while at the
same time not opening things up for abuse. It's not intended to replace
their home/work Internet, and they can always use their cellular connection
if they need something we don't permit.

--Dave



--

*DAVID A. CURRY, CISSP* • DIRECTOR OF INFORMATION SECURITY

*THE NEW SCHOOL* • 55 W. 13TH STREET • NEW YORK, NY 10011

+1 212 229-5300 x4728 • david.curry () newschool edu



On Tue, Apr 30, 2013 at 12:26 PM, Derek Diget <
derek.diget+educause-security () wmich edu> wrote:

> On Apr 29, 2013 at 10:19 -0400, David Curry wrote:
> =>We're (still) in the process of thinking about how we want to split our
> =>wireless network into two SSIDs, one for students/faculty/staff and one
> for
> =>"guests" (in quotes because students and staff may be allowed to use it
> =>too). We're thinking we want to do what a number of other schools have
> =>done, and limit the "guest" SSID to a few protocols:
> =>
> =>   - ICMP
> =>   - HTTP and HTTPS
> =>   - POP and IMAP in their SSL flavors only (no plaintext)
>
> What are you going to do for sites that offer with IMAP on 143 with
> LOGINDISABLED and STARTTLS?  It isn't any less "secure" than IMAP on 993
> with SSL.
>
>
> =>   - SMTP in its SSL and TLS flavors only (no plaintext)
>
> How do you tell the difference with a message submission over 587 that
> does not require STARTTLS before any SMTP AUTH and one that does?
>
>
> =>   - VPN (IPSec, PPTP, L2TP)
> =>
> =>which after Googling around a bit seems to be a pretty common set (some
> =>also allow unencrypted POP/IMAP/SMTP, and others also allow various
> flavors
> =>of chat/instant messaging).
>
> I think that XMPP has the same issue in that you can do clear text or
> STARTTLS on the same port.  Same for LDAP (mail clients doing address
> book lookups).
>
>
> So how can you really restrict "no plaintext" on protocols/ports that
> implement a STARTTLS type command?  OK, there might be some firewalls
> that can do it, but it brings back memories of PIX's fixup problems.
> Not ones that I would want to relive.
>
>
>
> --
> ***********************************************************************
> Derek Diget                            Office of Information Technology
> Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
> ***********************************************************************