[9228] in athena10
Re: Changing How MIT's VPN & Dial-Up Servers Handle Unauthenticated
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Tue Jun 12 18:58:45 2012
Date: Tue, 12 Jun 2012 15:58:22 -0700 (PDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Andrew Munchbach <amunch@MIT.EDU>
cc: Jonathon Weiss <jweiss@MIT.EDU>, Jonathan D Reed <jdreed@MIT.EDU>,
"linerva@mit.edu" <linerva@MIT.EDU>, release-core@MIT.EDU,
debathena@MIT.EDU
In-Reply-To: <CBE2830B.D24D%amunch@mit.edu>
Message-ID: <alpine.DEB.2.00.1206121555340.7240@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Hi,
We're working on integration of this change into the Athena sendmail
script and are curious what the expected behavior when trying to connect
to the outgoing server from a dialup/VPN machine would be. In particular,
it would be helpful to get an explicit connection-refused response instead
of for the connection to hang and be silently dropped -- otherwise the
user experience for users whose tickets have accidentally expired will be
poor, or we risk timing out too quickly when outgoing is in fact under
load. Do you know what the response will be?
Is there a way we can test the new environment; e.g., can you get
linerva-test put under these rules before June 16?
Thanks,
--
Geoffrey Thomas
geofft@mit.edu
On Wed, 23 May 2012, Andrew Munchbach wrote:
> Hi Geoff,
>
> The plan is to block access for 18.181.0.232 and 18.181.0.233
> (linerva.mit.edu and dr-wily.mit.edu) from accessing
> outgoing-legacy.mit.edu via a firewall rule. There are no plans to
> restrict your entire IP range.
>
> Best,
> Andrew
>
>
>
> On 5/23/12 11:40 AM, "Geoffrey Thomas" <geofft@MIT.EDU> wrote:
>
>> Ccing the Linerva team. Andrew, thanks for letting us know; more advance
>> and direct notice (and possibly some input into this decision) would have
>> been appreciated, since we do use unauthenticated mail from root as part
>> of Linerva's automated notifications and will need to write and test some
>> code to make this work. We'll also need to do user outreach, since I
>> expect we have users who are currently sending unauthenticated mail.
>>
>> Can you expand on the nature of the block? Linerva has multiple IP
>> addresses; there are also several hosts on the same network that need to
>> send unauthenticated mail and cannot be configured to send authenticated
>> mail.
>>
>> Thanks,
>> --
>> Geoffrey Thomas
>> SIPB Linerva team
>> linerva@mit.edu
>>
>> On Wed, 23 May 2012, Andrew Munchbach wrote:
>>
>>> Hi Geoffrey,
>>>
>>> I've been told that Linerva will not have access to outgoing-legacy
>>> after Jun. 16th.
>>>
>>> Best,
>>> Andrew
>>> --
>>> Sent from a mobile device. Please excuse any typos.
>>>
>>> On May 22, 2012, at 11:17 AM, "Jonathan Reed" <jdreed@MIT.EDU> wrote:
>>>
>>>> Well, Athena has minimal resources at this point (me), and those are
>>>> solely devoted to the summer release. We also need to come up with a
>>>> good plan for how to fix this. Dealing gracefully with timeouts kind
>>>> of sucks.
>>>>
>>>> -Jon
>>>>
>>>>
>>>> On May 22, 2012, at 10:57 AM, Jonathon Weiss wrote:
>>>>
>>>>>
>>>>> I don't have specific knowledge of how the block would be preformed,
>>>>> but
>>>>> I would expect the behavior to be the same as for off-campus hosts
>>>>> today. I believe they are blocked by the firewall, which means the
>>>>> expected behavior is hangign while trying to establish the connection
>>>>> until a timeout occurs.
>>>>>
>>>>> Assuming that is the case then yes, we'll want to make debathena-msmtp
>>>>> clever enough not to even try the connection and just return a fast
>>>>> error. I do hope to do that for the dialups, but I'm not sure when,
>>>>> and
>>>>> I expect the code I wrote to never try an unauth'd connection, and not
>>>>> to do a lookup on the IP address before deciding. That said, I'd love
>>>>> it if someone else wrote the code and I didn't have to. :-)
>>>>>
>>>>> I also don't have a hard answer regarding linerva, but Garry and I are
>>>>> both of the opnion that it should be treated the same way as the
>>>>> dialups, especially since we're still planning to move the name to the
>>>>> dialups.
>>>>>
>>>>> --
>>>>>
>>>>> Jonathon
>>>>>
>>>>>
>>>>>
>>>>> Jonathan Reed <jdreed@MIT.EDU> wrote:
>>>>>
>>>>>> (dropping linerva, CC release-team)
>>>>>>
>>>>>> Do we know the details of how mail will be rejected? e.g. Will
>>>>>> connections get rejected explicitly at the network level, or will
>>>>>> they simply hang forever until they timeout, or will sendmail respond
>>>>>> with a 5xx error? (the latter seems unlikely)
>>>>>>
>>>>>> We should ensure debathena-msmtp behaves nicely in general if on a
>>>>>> VPN, though presumably Ops has considered this and will include it in
>>>>>> their dialup customizations.
>>>>>>
>>>>>> -Jon
>>>>>>
>>>>>> Sent from my mobile device
>>>>>>
>>>>>> On May 18, 2012, at 12:48 PM, Geoffrey Thomas <geofft@MIT.EDU> wrote:
>>>>>>
>>>>>>> Okay, cool. Linerva is on a different network, so I'd assume not
>>>>>>> (and approximately everything else on 18.181 needs to send
>>>>>>> unauthenticated mail). Thanks for checking.
>>>>>>>
>>>>>>> --
>>>>>>> Geoffrey Thomas
>>>>>>> SIPB Linerva team
>>>>>>> linerva@mit.edu
>>>>>>>
>>>>>>> On Fri, 18 May 2012, Andrew Munchbach wrote:
>>>>>>>
>>>>>>>> Hi Geoffrey,
>>>>>>>>
>>>>>>>> The dial-up servers are losing access to outgoing-legacy.mit.edu
>>>>>>>> (mint-square, scrubbing-bubbles, etc.). I (perhaps incorrectly)
>>>>>>>> assumed
>>>>>>>> linux.mit.edu was included in this mix. I'll double-check with
>>>>>>>> Server Ops
>>>>>>>> on what impact this will (or will not) have on Linerva and get
>>>>>>>> back to you.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> On 5/18/12 1:16 PM, "Geoffrey Thomas" <geofft@MIT.EDU> wrote:
>>>>>>>>
>>>>>>>>> On Fri, 18 May 2012, Andrew Munchbach wrote:
>>>>>>>>>
>>>>>>>>>> * Users on the dial-up servers (ssh linux.mit.edu) that try to
>>>>>>>>>> send
>>>>>>>>>> unauthenticated email using the server outgoing-legacy.mit.edu.
>>>>>>>>>
>>>>>>>>> Hi Andrew,
>>>>>>>>>
>>>>>>>>> Given your mention of linux.mit.edu, I wanted to confirm whether
>>>>>>>>> Linerva
>>>>>>>>> is included or not in this change. I guess it's not unreasonable
>>>>>>>>> to count
>>>>>>>>> Linerva and athena.dialup as equivalent for these purposes, but
>>>>>>>>> we do
>>>>>>>>> have
>>>>>>>>> some changes we'll need to make so that e.g. cronjobs from root
>>>>>>>>> send
>>>>>>>>> authenticated mail, and we may have different user assumptions
>>>>>>>>> than
>>>>>>>>> athena.dialup has (notably, we allow logging in without delegating
>>>>>>>>> credentials, and athena.dialup doesn't).
>>>>>>>>>
>>>>>>>>> While there's discussion of switching linux.mit.edu to point to
>>>>>>>>> athena.dialup, I'm pretty sure that's not going to happen by the
>>>>>>>>> time of
>>>>>>>>> this change. Then again, if this is just a typo, that would make
>>>>>>>>> things
>>>>>>>>> easier for us. :)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Geoffrey Thomas
>>>>>>>>> SIPB Linerva team
>>>>>>>>> linerva@mit.edu
>>>>>>>>
>>>>>>>>
>>>>
>>>
>
>
