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.

1
  • 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. Commented Apr 27, 2018 at 15:04

1 Answer 1

1

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.

1
  • 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
    Commented Apr 29, 2018 at 23:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .