New answers tagged security
As implied by Anti-weakpasswords's answer, if your machine really has been pwned, and the replacement is recurrent, it may be happening in an Agent job, or a Windows scheduled task!
If those two databases are on the same cluster (beware of the PostgreSQL terminology, it's a name for an instance or installation or whatever you want), then you cannot prevent the users from logging in. All databases on a single cluster share the same users: Database roles are conceptually completely separate from operating system users. In practice it ...
Superusers are always exempt from lowly permission checks. The documentation: superuser status A database superuser bypasses all permission checks, except the right to log in. This is a dangerous privilege and should not be used carelessly; ... To see whether your current user is a superuser: SHOW IS_SUPERUSER; To list all superuser roles: ...
All these questions are basically answered in the documentation. To be specific: A role is an entity that can own database objects and have database privileges; a role can be considered a "user", a "group", or both depending on how it is used. That implies that internally there is no difference between these, except the LOGIN option. If you specify ...
The server has already been scanned with several tools and all the main password (administrator, sa of SQL Server) has been changed. If the SQL Server service account user is an administrator on the local machine, then you need to build a new machine from the ground up to replace it using long (14 character plus) cryptographically random passwords, and ...
SQL Injection is hard to track from SQL Server side. Instead of looking at sql server, you should look at your web server IIS logs. Use Log Parser to parse your IIS Logs to track down the source of sql injection. e.g. logparser.exe -i:iisw3c -o:Datagrid -rtp:100 “select date, time, c-ip, cs-uri-stem, cs-uri-query, time-taken, sc-status from ...
You cannot block or remove the root user. This is the administrator user for your MySQL. The best way is to password protect the user Root and allow it to login using the local computer (127.0.0.1) Some of the tables can be a temporary table which will be generated on the fly and deleted on a system specified rule.
Do you want to remove the anon users? You can just use DROP USER to remove them. They shouldn't have any special privileges, as stated in the MySQL Docs and should not be a major problem as they're only in the localhost. If, even removing, you still can login or something, check out this other question.
You can use the first option "Not be made with" a login mapping like below: Here's the result with the mapped login: And here's what happens with another account
As of January 29th, Microsoft SQL Server supports TLS 1.2 for SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 and SQL Server 2014 and major client drivers like Server Native Client, Microsoft ODBC Driver for SQL Server, Microsoft JDBC Driver for SQL Server and ADO.NET (SqlClient). Blog post about the release: ...
[https://mariadb.com/kb/en/mariadb/roles/](MariaDB 10.5 has Roles); see if they provide what you desire. (Yes, MariaDB is essentially compatible with MySQL; Roles is an extra feature.)
If I'm not mistaken, the fingerprint is a hexadecimal number. That means you could store it as a binary number, since two hexadecimal characters can be represented by a single byte, making a 32-character hexadecimal string = 16 bytes. Here's the documentation on binary and varbinary data types for MySQL 5.7 (I don't have a test environment handy). I do ...
I found, even with SQL 2014 SP1 CU1, I had to use separate boxes for IIS and SQL. I ran into a few apparently-related problems along the way, and detailed the steps in this post. The key points are: Put IIS and SQL on separate boxes Disable incoming TLS1.0 and enable outgoing TLS1.0 on the IIS box Enable TLS1.0 both ways on the SQL box.
I've resolved my problem. Not sure if all of the hurdles are things DBAs would normally encounter, but since people are often interested in resolving the whole problem, and this seemed like a series of issues others might encounter (given the various sources of the problems), here goes: Put IIS on a separate box. This allows IIS to have TLS1.0 disabled ...
Oracle Database Vault was designed for that exact purpose. Documentation link here.
The real answer is it depends, but most of the time this probably isn't a good idea. SELECT while it is less nefarious than other the other CRUD commands still carries risk. Why this is probably a bad plan Most applications with databases have some concept of an authenticated user vs a non-authenticated user. If I have unrestricted SELECT only access to ...
The Linux postgres user is entirely different from the postgres database user. It's created via the rpm package. When you're logged in as the system postgres user, it assumes the database user and database name that you're wanting to connect to is the same as the operating system user that you're attempting to connect from. That's why a simple psql works, ...
This restriction of 'instant file initialization' (aka. SetFileValidData) is documented: Note The file cannot be a network file, or be compressed, sparse, or transacted.
Its a blunder to restore a BIG database on SQL Server with no instant file initialization enabled. The amount of time taken to restore with no IFI is MUCH larger than amount of time taken to restore with IFI enabled. When IFI is enabled what it does is this permission keeps SQL Server from "zeroing out" new space when you create or expand a data file. This ...
Top 50 recent answers are included