Database question

[Seraph]

Currently my websites are being attacked, by the same punk who's done it before.

I noticed as well that about 100 emails came through my form with a very odd format, and upon Googling, it looks like he's trying to get into my database.

So I'm backing everything up (as both sql and xml), but does anyone have any tips on how to spot if he DOES get in or not, or changes anything?

[emax4]

I wonder if you can set up a spoof database in a DMZ, see if he tries that, and see if you can do a traceroute back to it.

[Pedersen]

Without more technical details, it's pretty difficult to tell what's going on. However, my first guess is going to be that the database is running MySQL. From what you've said, he's also probably running a tool he downloaded from somewhere trying to penetrate it.

Here's where things get dicey, though: He's using web URLs to get at the database, so the question to ask is this: Where did the pages running those URLs come from? From Ex-Coder? From the company you most do business with?

The reason I ask is because that will tell you how secure you are by default. If it's ex-coder, you have much more worry than if it's from the company.

Now, as for detecting problems, or successful penetrations? That's harder to do. Your single best bet is going to be to make frequent backups, and keep a *lot* of them. Especially if you don't have full control over the servers (and I don't *think* you have that), you're not going to be able to view enough of the logs to tell what happened or when.

Your backups are going to be the only thing to save you. Keep them, and keep them safe. I wish I had more, I really do.

[It's me]

If the database security is designed correctly, no one should be able to damage it, even if the front-end (web application code) lets a SQL injection attack through. Attacker might be able to read or update data though... whatever permissions the web app has in the database.

Also if the DB is designed correctly andychanges to stuff that matters should be logged so their is an audit trail.

That said you should make sure:
--All access to the DB is through correctly written stored procedures
--The web app does not have permission to directly access tables and must use the stored procedures
--The web uses a secured session (HTTPS)
--The web app does not expose the user's credentials by using something easy to guess & easy to spoof like relying on integer passed from client to server using PUT or POST.

[Seraph]

I'm not going to lie, haven't the foggiest what half of this stuff means.

But, and I don't know if this is a stupid idea or not. I'm backing up a lot, and have been checking the files on my server, to see if anything suddenly pops up with a really new modified by date, past the time when I backed up.

...Would that possibly work?

[Der Cute]

I'm not going to lie, haven't the foggiest what half of this stuff means.

But, and I don't know if this is a stupid idea or not. I'm backing up a lot, and have been checking the files on my server, to see if anything suddenly pops up with a really new modified by date, past the time when I backed up.

...Would that possibly work?

That's part of it, keeping a trail as said (audit) so you know.
It's Me is saying there should be a very tight connection between the web page and the db. [DB]--[https connection encrpyted]---[webpage].

Pederson - would a honeypot work?