October 5, 2020 at 12:00 am
Comments posted to this topic are about the item Detecting Logins
October 5, 2020 at 3:15 pm
That's odd! For once, I feel proud of my shop!
Yes, I detect every single strange login added to our instances. And we do get those! (Because we are using a hosting company with very limited understanding of what "security" means, so they regularly have someone doing stuff on clients' servers without informing the clients about it beforehand!!)
Funny part is: I use Redgate Source Control to do this. So it is not a part of some extra work-procedure that may sometimes be skipped. Unauthorized logins added are simply flagged every time I boot up SSMS. Of course, that's not 24/7... But on the other hand: That's why we are paying bucks to a hosting company in the first place... I get to know about them immediately, every time I get to work. That's good enough frequency for me, given that we are not facing the really nasty people of the internet, but merely the really lazy people of the company + associates.
October 5, 2020 at 3:26 pm
That's cool to hear.
Is there some way you use to determine if they are valid?
October 5, 2020 at 3:52 pm
A few years back, I wrote a PowerShell script that queries login and permissions across 100+ servers. It's scheduled daily summarizes the data into SCD2 type tables for use in a dashboard report.
The situation where a malware would create a 'default' login account is strange. The malware would require SYSADMIN access to create the login in the first place, so what would it need with a new account? If it knows the password for 'SA', then it has everything it needs, and could also do it's thing more covertly than if it used a strange new account.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 6, 2020 at 11:01 am
Well, mostly the good ol' tried-and-tested method of "asking around". My specialty is to "not stop asking until I get a satisfying answer".
Usually, we trace it down to some application that someone in a senior management panel decided they would have - and when the technicians got to work, it turns out that the design of said application is wanting: it can't run without centralized anonymous logins (without supervision!) are added to all the clients' instances... Then it is merely a matter of writing up the case and hand it over to (other) managers to take action on - or not. Then add the intel to our documentation for future reference.
Every now and then, nobody can come up with an acceptable excuse for adding it. In which case, I merely delete it again. My way of thinking is: Stupid developers and admins may be hurt. Their problem. They should know better. Innocent users of an application get hurt. My problem. Their managers should know better - but that's for managers to handle. I can't go around reverting decisions made on the top floors. But everything we have needs to be understood and properly labelled; responsibility assigned.
So to recap: I'm not handling 100+ of databases and instances, but the approach is the same:
And of course: Suspicious activity is blocked right away! I am talking about acceptable activity which just isn't understood by anyone but the one who created the login. We can't have that - but it is more like an everyday cleaning activity than a specific security breach handling. That, of course, begs the question What is suspicious?, but that comes from context, experience and talking with peers. I train juniors to ask more questions rather than fewer.
My approach would change, if we were 'attacked' daily, because then it wouldn't be manageable this way.
October 6, 2020 at 2:40 pm
Thanks, that makes sense and likely what I'd do as well.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply