2005 getting brute forced 1

[adamroof]

Testing 2005, and turned on external connections and looked at event log this morning, and flooded with security failures...

Login failed for user 'sa'. [CLIENT: 208.101.198.171]

Login failed for user 'root'. [CLIENT: 208.101.198.171]

Login failed for user 'admin'. [CLIENT: 208.101.198.39]


seeems most are same ip range. is this a worm doing this or program someones running? Is there anything in SQL 2005 i can do to lock this down?

 

[SQLBill]

It looks like someone found your system and is trying to force their way in. I would report this to your network security person. Do you have someone who does intrusion detection? If it was only SA being used, I would guess that it is an application trying to connect. But with root and admin also being tested - that leads me to a hacker or malicious code.

Consider having your firewall team block the 208.101.198.xxx set of IPs. Also, have your network people make sure your anti-virus is up-to-date and scan all the systems.

Background: I worked for 5 years with a company that provided intrusion detection to a U.S. government organization. I ran the database that collected the data and had to work closely with the Computer Incident Response Team.

-SQLBill

Posting advice: FAQ481-4875

 

[adamroof]

well, thats me...ive already blocked the range, there are over 5000 events since last night, i kicked this guy harder than Pele could. im all about intrusion PREVENTION!

Is there anything in the new SQL2005 version that i can setup that can lock out specific users/ips within SQL. this box is a honeypot right now, so im testing out what i can do to strip these guys of their manhood before i go live.

Any new hardening practices available? This db will need external connections from offsite users with dynamic ips so i'll have to leave external connection on, or at least i did with sql2K

 

[Catadmin]

It's probably a bot rather than one person sitting at their keyboard. Lot easier to make a bot do all the smashing than typing all that yourself. Additionally, the bot could potentially be spoofing another IP address or have inhabited someone else's (a legit user) box.

SQL Server 2005 has something called EndPoints with it. I haven't played with it myself, but I believe you might be able to use it to limit the amount of traffic you're getting it by having it actually set up to only use those valid EndPoints (check BOL for more info).

Additionally, I read something somewhere where you can actually limit connections via the network protocols to certain machines, I would guess via IP, but I'm not sure if you could do it by IP range.

It's been over 7 months since I read all that, though, so you'll want to double-check it. Still, I think it'll give you someplace to start.



Catadmin - MCDBA, MCSA
"No, no. Yes. No, I tried that. Yes, both ways. No, I don't know. No again. Are there any more questions?"
-- Xena, "Been There, Done That"

 

[MDXer]

the ip resolves back to

Name: cablepool6-170.elberton.net
Address: 208.101.198.171

Appears to be a broadband provider in Georgia USA

[URL unfurl="true"]http://elberton.net/[/url]

Might want to contact them and see if they will put a smash on the user doing this. After all it isn't good for business to have these types of customers.

Shoot Me! Shoot Me NOW!!!
- Daffy Duck

 

[adamroof]

yeah, been to their site, its the City of Elberton, GA.

its either a compromised pc or a script kiddie (hopefully) running a pw cracker.

re: sec issues
im checkin out the endpoints and seeing if i can setup using the Via protocol for the needed odbc connections.

 

[mrdenny]

The endpoints won't be able to help you any. You have to log in before the endpoint can grant you access.

You should block all access to the SQL Servers except the specific access from the net that is required (which should be none).

I used to run a hosted SQL Server for a company and when I got there the entire world could connect to the SQL Server. I quickly had that locked down so that they had to use the web version of Enterprise Manager to connect.

Within SQL there isn't anything you can do to prevent this. It has to be done at the network layer.

Denny
MCSA (2003) / MCDBA (SQL 2000) / MCTS (SQL 2005) / MCITP Database Administrator (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[adamroof]

I agree mr d

im running a couple of contact management databases, and im heading into writing out the reports in .net, but now they use ms word with form letters and labels, and connect with an odbc connection i setup for them.

in sql 2k, i thwart would be connections by solely using windows firewall allowing only the limited subnet of their home ips odbc access. All other connections must be initiated from my web server in my datacenter.

so if a couple of my employees got smart, they could connect through EM, or if an attacker happened to be from the same isp and got lucky to be in that range, i'll still see the access attempts, and confirm the user ip that it should be, then hopefully drop it.

so, yes...after a little more intelligent architecture, ill drop all remote connections completely. 05 surface configuration is still pretty cool although limited to a couple of radio buttons. Maybe SQL 2010 will have embedded network layer controls.

Thanks all for your comments.

 

[mrdenny]

I'd setup a VPN server and force them to VPN in. Then all connections will be secured and from within the network.

Denny
MCSA (2003) / MCDBA (SQL 2000) / MCTS (SQL 2005) / MCITP Database Administrator (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com