0

Background: I have an SQL Server database running on Amazon RDS

The AWS dashboard has a section for logs and whenever I check the logs I see the following:

2018-04-27 06:10:26.00 Logon Error: 18456, Severity: 14, State: 5.
2018-04-27 06:10:26.00 Logon Login failed for user 'bwsa'. Reason: Could not find a login matching the name provided. [CLIENT: 186.52.95.67]
2018-04-27 06:10:28.17 Logon Error: 18456, Severity: 14, State: 5.
2018-04-27 06:10:28.17 Logon Login failed for user 'ps'. Reason: Could not find a login matching the name provided. [CLIENT: 186.52.95.67]
2018-04-27 06:10:30.42 Logon Error: 18456, Severity: 14, State: 5.
2018-04-27 06:10:30.42 Logon Login failed for user 'uep'. Reason: Could not find a login matching the name provided. [CLIENT: 186.52.95.67]
2018-04-27 06:10:32.73 Logon Error: 18456, Severity: 14, State: 5.
2018-04-27 06:10:32.73 Logon Login failed for user 'sa'. Reason: Could not find a login matching the name provided. [CLIENT: 186.52.95.67]

First of all I do not have any of the above users.

Secondly I tried to check where those IPs were located using: https://www.iplocation.net/ , most of them are either from Vietnam or China ,the ones above are from Uruguay. (And yes I am aware that IPs can be spoofed)

Third the database URL was never publicly available.

Question: Is my DB server being attacked by some bot or automated process ? Should I be worried . What action should I take.

  • This is what you'll see on any service that you expose to the internet. Do consider whether or not this asset needs to be exposed. – multithr3at3d Apr 27 '18 at 15:04
0

Firstly, IPs can be spoofed - but for TCP-based connections that actually log in, they can't. Or they can only with unbelievably high cost.

Secondly, is there a reason your database access is not restricted on a lower level via a packet filter for example? Usually, you would only grant connection capabilities to IP ranges that do have reason to connect to the database in the first place (instances of web applications, for example).

Thirdly, this looks like a scanning tool that tries to maybe tries to fingerprint the database. The huge delta of two seconds between the attempts may be for the dbms to recuperate and have a timing attack revealing version information - or just to not trigger an IDS. Yet, every IDS I know would/should pick up on that anyway.

So all in all: You should restrict access on Layer 3 or 4 and have that potential risk of brute forcing bots trying to login go away.

  • Yes I think I could look at restricting the access to IP ranges but from what I know AWS RDS can only restrict access to Internet and not specific ranges. – Nigel Fds Apr 29 '18 at 23:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.