Who foots the bill for intruder lockouts?

0 Likes
Well... I survived Novell REDucation. This a local Novell conference held every year. Its main focus is on its partners and selling Novell solutions. So what, may you ask, is a Techie like me doing at a sales conference?
Well, it's all about networking. There are several new faces in our Novell country office including a new country manager and it was good to get to know all the new faces, see many familiar ones, and just catch up with everybody and find out where they are at in terms of Novell solutions.

A big thank you to Lauren Castelyn and all at the local Novell office for an awesome conference

The burning question on my mind today deals with "hack" attempts on e-mail accounts. Over the weekend one of my customers had their GroupWise account locked (Intruder lockout). From the log files we can track that it was done via GroupWise WebAccess and the external IP address that it came from is registered to the public APN of one of the biggest mobile data providers in South Africa. A call to the service providers support line reveals that their staff don't even know what an IP address is! Going a little further up the chain of command and they want a police case number and court order before they even start entertaining our queries regarding which customer was issued that IP address on that particular date and time. At this point I'm assuming that they even have the ability to provide that information should I get the police involved and get a court order telling them to give us that information.

The question is how far should we take this? This is one intruder lockout, probably from a disgruntled employee. Do we have the time and resources to take this through the legal system to reveal that one poor, misguided individual tried to look at his boss's e-mail? And, at the end of the day, who foots the bill?

What do you guys think and how do things work in your companies/countries?

Labels:

How To-Best Practice
Comment List
Anonymous
Parents
  • We've had cases of SSH scanning attempts against our NetWare based SSHD servers cause some users to lock out. Typically the unfortunate users are those who have been here long enough to have userID's like 'fred', or 'cindy', and are therefore in every single user-name dictionary on the planet. Because our ILO thresholds are high enough, two such scans have to arrive inside the lockout period for it to trigger. We haven't bothered looking into these since they are pure 'scanning tool' problems, and deeply non-personal. Also, our lockout periods are short enough that sometimes we don't even notice when these accounts lock.

    At an old job we had our lockout period set for 3 days. The theory being that if an account locks over the weekend, us admins would like to know about it very much. This was put into place before we really had GroupWise web-access up and running. This was in the era before web-based attacks were as automated as they can get these days.

    Once tracing access hits a public ISP of some kind (attackers in Germany are popular with us for some reason) it gets very hard to get past them. You have to prove that the IP address in question violated the ISP's terms of service in some key way, or go the legal route. And even then they may ignore you.

    Intruder Lockout serves a useful function, but at the same time it is a way to perform a Denial of Service attack against a person. The three day lockout of my old job would be very prone to this. While having a 30 minute lockout would greatly slow password guessing attempts. If a user gets continually locked out and it is traced to publicly facing services (GW-WebAcc, SSH, FTP, NetStorage, etc) it is a very good idea to make sure that user has a robust password.

    Personally, I find lock-outs to be a nuisance rather than a critical chase-it-down thing. We had similar things happen when a spam mailing forged the identity of a top level manager here, and the manager asked us to find it and stop it. Once we teach the person requesting the investigation that the best we can do is trace it off shore and out of any legal jurisdiction we might have, they've always relented.
Comment
  • We've had cases of SSH scanning attempts against our NetWare based SSHD servers cause some users to lock out. Typically the unfortunate users are those who have been here long enough to have userID's like 'fred', or 'cindy', and are therefore in every single user-name dictionary on the planet. Because our ILO thresholds are high enough, two such scans have to arrive inside the lockout period for it to trigger. We haven't bothered looking into these since they are pure 'scanning tool' problems, and deeply non-personal. Also, our lockout periods are short enough that sometimes we don't even notice when these accounts lock.

    At an old job we had our lockout period set for 3 days. The theory being that if an account locks over the weekend, us admins would like to know about it very much. This was put into place before we really had GroupWise web-access up and running. This was in the era before web-based attacks were as automated as they can get these days.

    Once tracing access hits a public ISP of some kind (attackers in Germany are popular with us for some reason) it gets very hard to get past them. You have to prove that the IP address in question violated the ISP's terms of service in some key way, or go the legal route. And even then they may ignore you.

    Intruder Lockout serves a useful function, but at the same time it is a way to perform a Denial of Service attack against a person. The three day lockout of my old job would be very prone to this. While having a 30 minute lockout would greatly slow password guessing attempts. If a user gets continually locked out and it is traced to publicly facing services (GW-WebAcc, SSH, FTP, NetStorage, etc) it is a very good idea to make sure that user has a robust password.

    Personally, I find lock-outs to be a nuisance rather than a critical chase-it-down thing. We had similar things happen when a spam mailing forged the identity of a top level manager here, and the manager asked us to find it and stop it. Once we teach the person requesting the investigation that the best we can do is trace it off shore and out of any legal jurisdiction we might have, they've always relented.
Children
No Data
Related Discussions
Recommended