LGfL 2.0 Problems

[Soulfish]

Soulfish, do you happen to know or have in writing what their 'security guidance' is? Otherwise it's fairly ambiguous.

 

They can all be found at About | London Grid for Learning

 

The most recent security guidelines were updated in March after we had some discussions with LGfL (and one of the reasons for our deciding to leave).

[GrumbleDook]

Let me get this straight.... they're blocking OUTBOUND connections??!?

 

Are you saying you think it is a bad idea to block outbound connections? Would you prefer that all ports were open?

[esucmn]

I'd like it under my control. I have no confidence their security policies will allow the services we run.

[SchoolsBroadband]

may I ask out of interest how long everyone has contracted with LGFL 2.0 for?

 

We've a few schools using our services in London as an alternative to LGFL

[SchoolsBroadband]

may I ask out of interest how long everyone has contracted with LGFL 2.0 for?

 

We've a few schools using our services in London as an alternative to LGFL

[SYNACK]

Are you saying you think it is a bad idea to block outbound connections? Would you prefer that all ports were open?

 

Only if they have no free, easy and fast way of unblocking stuff for themselves otherwise one person/organisations views of a a service or IP end up being enforced as as inpromptue law.

[esucmn]

may I ask out of interest how long everyone has contracted with LGFL 2.0 for?

 

The contract is in the public domain: http://files.lgfl.net/lgfl/policies/lgfl%202.0%20network%20services%20agreement.pdf

[hit]

Let me get this straight.... they're blocking OUTBOUND connections??!?

 

Ahhh, this makes sense why our sftp/scp client isn't connecting from our admin network to a server in the DMZ. Will cause a problem with my other schools which send data to here for parental reporting when they change over in the next few weeks! Will let you know how I get on with having the ports opened.

[sramdeen]

ahhhh, I love consistency. After getting some ports unblocked at one of my schools and thinking things were getting better, a request for exactly the same ports at another school came back this morning:

 

Unfortunately we are unable to allow any email access aside from port 25, even then that must be passed through our ECC. All email that isn't coming through the ECC will have to be accessed via webmail clients.

 

With regards to the other items listed, you will need to specify an internal and external IP, for example we wouldn't allow "off site backup" or "Filemaker Client" to *any*, we would need the IP addresses they are going to.

 

So if I interpret that correctly they are now saying that there is NO email access from email clients such as Outlook, Mail, Thunderbird etc and that everyone has to use webmail.

 

I'm just off to a corner to simultaneously cry and laugh.

[maestromasada]

rav3 does not work for students, RM Secure Net needs random ports open, MS Office Activation does nto work... buf, LGfL does bring some problems. A good thing of Webscreen 2.0 is that it tracks the users activity on the web, we may as well damp securus all together

[hit]

rav3 does not work for students, RM Secure Net needs random ports open, MS Office Activation does nto work... buf, LGfL does bring some problems. A good thing of Webscreen 2.0 is that it tracks the users activity on the web, we may as well damp securus all together

 

Interesting, how do you track individual students with webscreen 2? The only way I can see to do it is tho block the Internet completely and force users to log in with their USO to then let them into a policy.

 

I was originally told that LGfL2 would use NTLMNAuth (or similar) to get the username transparently, all that would be needed was that our usernames need to be The same as the USO ones (which makes sense to only have one username / password pair). Guess what, this didn't work either! More mis-selling I guess!

[strawberry7]

I have been following this thread with interest and appreciate all the information that has been gathered here. I am equally annoyed about the blocking of Logmein as I am going to have to spend my time setting up RAv3. Then get a CentraStage account. Then change all my clients to CentraStage which doesn't support iOS, so I've lost that. Then I can remote in an inferior way than I have been for years as I will need to establish a VPN before remoting each time. Which is a pain.

 

As for all the filtering, I am trying to gather as much information about how to turn as much of it off as possible BEFORE my schools migrate.

[sramdeen]

They can all be found at About | London Grid for Learning

 

The most recent security guidelines were updated in March after we had some discussions with LGfL (and one of the reasons for our deciding to leave).

 

The Security Guidance document located at http://files.lgfl.net/LGfL/Policies/LGfL%20Security%20Guidance%20April%202012%20v1%201.pdf makes no clear mention of blocking outbound ports. The only section regarding port blocking is:

 

6. Other

In the interests of sound security policies, requests made for the opening of firewall ports should be kept to the minimum required to permit the intended applications to function, and limit port access to the specific IP address range which is necessary.

 

IMO any sysadmin reading this would interpret it to mean incoming connections not outbound.

 

So with the Mac version of the CentraStage client still in beta, LGfL has left schools with Macs out in the cold. If they want to use a supported, sanctioned method of remote access Mac users are currently out of luck. If a school has Macs and they need their support company to gain remote access to troubleshoot a problem, what are they mean to do? Luckily there are workarounds available until a permanent solution is found...

 

With all of this heavy handed security, one question comes to mind - Just what was wrong with the LGfL1 security policy? How many security breaches were there on the old system and how many children were harmed as a result? Seems to me this new policy involves a lot of stick and no carrot. Normal end users are going to be frustrated when things don't work and network admins are going to find ways around the security measures put in place supposedly to protect the network. I for one know this is already happening at a couple of lgfl2-connected secondary schools, so the whole security policy goes out the window.

 

grump grump grump

[strawberry7]

Just what was wrong with the LGfL1 security policy? How many security breaches were there on the old system and how many children were harmed as a result? Seems to me this new policy involves a lot of stick and no carrot. Normal end users are going to be frustrated when things don't work and network admins are going to find ways around the security measures put in place supposedly to protect the network. I for one know this is already happening at a couple of lgfl2-connected secondary schools, so the whole security policy goes out the window.

 

grump grump grump

 

I totally agree with you. My schools have been using their internet with very relaxed rules for years and I have been using Logmein for years and guess what.....it was fine! No security breaches and no problems. I have just had this response from Atomwide:

CentraStage and RAv3 are not linked, CentraStage can be used like LogMeIn. You won't need RAv3 entirely set up for this to work.

 

Confused!!!

[esucmn]

The Security Guidance document located at http://files.lgfl.net/LGfL/Policies/LGfL%20Security%20Guidance%20April%202012%20v1%201.pdf makes no clear mention of blocking outbound ports.

 

*SNIP*

 

IMO any sysadmin reading this would interpret it to mean incoming connections not outbound.

 

This is my biggest problem currently - we cannot get a straight answer out of Atomwide what is and is not allowed, especially with regards to email. Having worked around the recipients per email, they then blocked the Head's PA (without notice or telling anyone) by changing her password, leaving her without email for 24 hours. This did not go down well. The reason was apparently too many recipients in X period of time.

 

To avoid this we want to run our own Exchange system with sensible limits for our school, However we have to use their email relay system. This leaves the following points:

 

1) I don't trust them to keep their systems running. Their systems are more complicated than those required for a single school and therefore more likely to fail. We want to remove this unnecessary point of failure.

2) When asked about what restrictions were placed on mail sent though their mail relays they said none

3) When pushed on what the point of these filters were given they had no restrictions they said there were to stop spam.

4) When pushed on this they refused to reveal the technical limits that would consititude "spam" or sanctions that would result from it.

 

How can you aim at a goal when you can't get an answer as to where the goalposts are?

[strawberry7]

3) When pushed on what the point of these filters were given they had no restrictions they said there were to stop spam.

 

Hmmm, it's funny how I have never had a single spam message get through my google mail in 2 years and yet they don't have these type of restrictions to accomplish that. LGFL/Atomwide are so over the top!

[Eric]

I don't particularly wish to defend Atomwide's filtering policies, or the responses which people are currently getting from Atomwide support.

 

However, I was in a session at the recent LGfL conference at which Martin Coulson (CEO of Atomwide) responded to some criticisms in this area. He made it clear that the current rate of switchovers from LGfL 1.0 to 2.0 has put constraints on the flexibility with which their support operation can respond to requests. As you can imagine, LGfL has always had problems with spammy outbound connections resulting in blacklisting of tranches of their own outbound IP address space. This is why there are messages-per-minute rate limits at their email relays. Apparently these will rise after a couple of weeks, once it is clear that a particular customer IP range isn't sending spam. Of course, the limits for a declared school mail relay should start off much higher. From the discussion, I would judge that these algorithms are being tuned at the moment and will probably need adjusting some more.

 

One of the problems with the current load on Atomwide support is that subtle problems may not be escalated to people who can do something about them (Martin.) This is clearly unsatisfactory. Maybe a direct email to Martin Coulson (probably at [email protected], or maybe [email protected]?) will do the trick for you.

 

I would observe that email message rate-limiting is a perfectly sensible approach to trying to limit outgoing spam. It's quite common amongst ISPs these days. I would also question whether a single Exchange installation is actually a reliable way to send email.

[esucmn]

As you can imagine, LGfL has always had problems with spammy outbound connections resulting in blacklisting of tranches of their own outbound IP address space. This is why there are messages-per-minute rate limits at their email relays.

 

I don't disagree with the idea of rate limiting - in fact I fully intend to implement such limits myself. If you re-read what I asked and what the answers were, you will see that they refuse to tell you want the limits and penalties are. This means that we could be in a condition where were send out an all student email via a distribution list or similar and get the entire school blocked as a spammer because we didnt realise we could only send 300 emails per hour. Of course we might not, but WE CAN'T FIND OUT!!

 

I would observe that email message rate-limiting is a perfectly sensible approach to trying to limit outgoing spam. It's quite common amongst ISPs these days.

 

I agree - not a problem with that. The problem is as stated above they won't tell us if there is a limit that leads to sanctions - like the password incident above.

 

I would also question whether a single Exchange installation is actually a reliable way to send email.

 

I would rather trust a very simple system under my own control than a huge system catering for thousands upon thousands of users any day. The more users, the more complicated the system and the more likely it is to fail. And when it does fail its more complicated to fix. In addition to this, when its under my control *I* can fix it and have control over how long it takes - which when it is me being shouted at by the staff, I infinitely prefer!

Edited May 11, 2012 by esucmn

[hit]

I would rather trust a very simple system under my own control than a huge system catering for thousands upon thousands of users any day. The more users, the more complicated the system and the more likely it is to fail. And when it does fail its more complicated to fix. In addition to this, when its under my control *I* can fix it and have control over how long it takes - which when it is me being shouted at by the staff, I infinitely prefer!

 

Which is exactly the reasons why I have been onto our suppliers this morning to sort out licencing to have our own in house exchange server. The whole LGfL staffmail package looks great on paper until you want to be able to do something sensible, like have a donotreply@ address for servers to send from, or a helpdesk@ address to integrate into your favourite helpdesk solution, that you can't have! Pfft!

[Eric]

I agree - not a problem with that. The problem is as stated above they won't tell us if there is a limit that leads to sanctions - like the password incident above.

I suggest that you contact Martin Coulson - he may be willing to tell you the email rate limits.

[Eric]

The whole LGfL staffmail package looks great on paper until you want to be able to do something sensible ...

I agree, Staffmail isn't very useful at all. It's exceptionally bad at coping with people who change roles and incapable of helping when people change their surname. It's antideluvian, which may well derive from the Microsoft technology it's based upon.

[esucmn]

I suggest that you contact Martin Coulson - he may be willing to tell you the email rate limits.

 

He was the one who refused.

[Eric]

Actually, I am not surprised. He is very opinionated.

[Fergal_Serco]

Hi

 

My first post here so bear with me!

 

I have been in contact with our account manager at LogMeIn to discuss this issue at length. We are working for a way to overcome this but our responses from LGFL has been minimal.

 

It should be noted that Serco Learning have not changed any of our remote access policies - and we were as caught blindsided by this as you were. I would advise all schools to discuss this with your ISP and we will continue to work on a technical solution with our Partner from LogMeIn.

[Nodrog]

I'm not sure about the rate limit your talking about here - I've found two ways to get outbound to work - firstly just post straight out to the main LGfL smtp outbound servers - no limit's on them - my email servers using this one along with my help desk system. Then I have a photocopier that wants to email the manufacturer when it's feeling sick which I use the email relay service which has a limit on it and is explained in the online manual

 

If it reaches the limit then the system just disables it for a hour and then starts you up again after the hour is finished which is done automatically and that’s displayed in the tab on the support site - if you over run the limit then it's worth looking at why your sending loads of emails and either fixing the problem or asking for an increase on them limit which I got or posting into your own email server. If you tell them a to and a from address you get a massive limit and if you tell them nothing then a small limit.

Edited May 18, 2012 by Nodrog