Блокирование логина после троекратного неправильного ввода парол

← →
serg_newone (2004-09-20 14:21) [0]

Доброго времени суток!
MSSQL2000, SQL Server Authentication. Нужно научиться какими-либо средствами блокировать (или по крайней мере отслеживать) логин при троекратном неправильном вводе пароля. Уважаемые посетители форума подскажите куда копать, как делать. Может быть написать обертку для длл-ки (если такова есть), к-рая проверяет соответствие логин/пароля или же как-нибудь надругаться над syslogins. Вообщем приветствуются любые идеи, а лучше всего штатные средства:). Да, способ идентификации изменить нельзя. Заранее спасибо.

← →
panov © (2004-09-20 14:24) [1]

Категорически нельзя этого делать - обеспечивает злоумышленнику дополнительные возможности.

← →
serg_newone (2004-09-20 14:33) [2]

Для поддержания темы и из личного интереса спрошу, - а почему?
На самом же деле сие есть требование "заказчика", к-рое в любом случае необходимо делать.

← →
serg_newone (2004-09-20 15:14) [3]

Вопрос снят, решение найдено.

← →
Ega23 © (2004-09-20 15:20) [4]

На уровне клиента это делается. Но ни в коем случае не на уровне сервера.

← →
сергей1 (2004-09-20 15:57) [5]

ну почему только на клиенте, как раз, если безопасность является приоритетной вещью в разработке базы, ограничения на число попыток только на клиенте ничего полезного не даст. Что-бы реально оградить себя от таких проблем, надо отключать логин пользователя после ,например, 3 неудачных попыток. И подсчет таких попыток вести именно на сервере, т.е. клиент неудачно вводит пароль - увеличивем счетчик в какой-нибудь запрятанной таблице. Лимит превысили - вырубаем пользователя процедурой sp_revokedbaccess. А на клиенте такой подсчет вести бесполезно - мне ничто не помешает использовать на одну попытку меньше, затем перезагрузить программу - и у меня снова есть 3 попытки !

← →
KSergey © (2004-09-20 16:06) [6]

> [5] сергей1 (20.09.04 15:57)
> И подсчет таких попыток вести именно на сервере, т.е. клиент
> неудачно вводит пароль - увеличивем счетчик в какой-нибудь
> запрятанной таблице

А просветите, как на стороне сервера отловить попытку логина?

← →
Ega23 © (2004-09-20 16:06) [7]

сергей1 (20.09.04 15:57) [5]

Ну в случае таких параноидальных требований - это хорошее решение :о)
Лично я, например, информацию о пользователях держу непосредственно в самой базе, а не на уровне средств сервера. Т.е. все потльзователи с точки зрения сервера входят в одну и ту же роль. А вот на клиенте - в зависимости от введённого логина-пароля клиент получает разрешённые ЛИЧНО ЕМУ операции.

← →
Ega23 © (2004-09-20 16:10) [8]

А просветите, как на стороне сервера отловить попытку логина?

Дык, всё через ХП...
Типа:
Print "S_PasConnect - процедура соединения с БД" go if exists (select * from sysobjects where id = object_id(N"[S_PasConnect]") and OBJECTPROPERTY(id, N"IsProcedure") = 1) drop procedure [S_PasConnect] GO --example S_PasConnect @mode=0, @Login="00", @PCNAM="kedr106", @debug=1 --select * from worksts persons logins CREATE PROCEDURE S_PasConnect @mode int=-1, -- Input: 0 - Disconnect -- 1 - DB connect @Login varchar(32) = "", -- users LOGIN @Passwd varchar(32) = "" , -- users password @PCNAM varchar(32) = "" , @modCod int=1, -- модуль, к которому коннект (по умолч. - БП) @debug int=-1 AS SET NOCOUNT ON --internal vars declare @PersId int, @PersId2 int, @PersNam varchar(64), @ProfCod smallint, @PersMsk smallint, @WCFGNAM varchar(64), @WCFGID smallint, @ProfNam varchar(64), @i int, @p int, @cnt int, @cod int, @usedisp int, @mess varchar(64), @worknam varchar(64), @WorkCod smallint , -- @PCNam varchar(32),-- = "?" @SysNam varchar(64), @SysVer varchar(64), @SysAddr varchar(255), @disabledopers varchar(8000), @ss varchar(8000), @sd varchar(8000), @si varchar(8), @dt datetime, @WORKIP varchar(16), @WSID int, @cardcod int, @pincod int, @DISPIP varchar(32), @DISPPORT int, @info varchar(1024), @result int -- Preset set nocount on set @result=-1 set @mess ="Ошибка соединения" set @disabledopers="" set @DISPIP="" set @DISPPORT=4200 if @PCnam="" select @PCnam=convert(char(16), isnull(host_name(),"?") ) if @mode < 0 Goto FIN set @mess ="Пользователь не зарегистрирован" select @PersId=L.PersId, @dt=L.Logdatout, @PersNam=P.PersNam1+" "+P.PersNam2+" "+P.PersNam3, @Profcod=pr.profcod,@Profnam=pr.profnam, @WCFGID=WC.WCFGID, @WCFGNAM =WCFGNAM from logins L , Persons P, Profs Pr,WorkCfgs WC where upper(L.Login)=upper(@Login)and upper(L.Passwd)=upper(@Passwd) and L.LogMsk>0 and l.modcod in (0,1) -- @@2002-25-01 @@2002-05-28 and L.LogDatOut>getdate()--13.09 recovered and Pr.Profcod=P.profcod and L.PersId=P.Persid and Pr.WCFGID=WC.WCFGID if @persid is null begin if @debug<>-1 select PersId=@PersId GoTo Fin end if @WCFGID=0 begin set @mess =@Profnam+ " не может быть пользователем системы." GoTo Fin end set @mess ="Срок Вашей регистрации в системе истек." if @dt < getdate() begin if @debug<>-1 select PersId=@PersId, dt=@dt GoTo Fin end --....... Пользователь хороший !! select top 1 @sysnam=ObjNam,@sysAddr=ObjAddr,@sysver=sysver from ParamsGlb --== РЕГИСТРАЦИЯ РАБОЧЕЙ СТАНЦИИ --Check if the Workstation registred --select * from s_softtbl select * from s_compstbl worksts set @WORKCOD=null select @WORKCOD=WORKCOD from worksts where upper(ltrim(rtrim(PCNAM)))=upper(ltrim(rtrim(@PCNAM))) --and WORKCOD>0 set @WSid=null set @WorkIp="" -- after @@24-12-2001 select @WSid=s.UID, @WorkIp=c.CMIPAddr from s_compstbl C, s_softtbl s, s_softtypestbl t where upper(ltrim(rtrim(c.CMNetName)))=upper(ltrim(rtrim(@PCNAM))) --and WORKCOD>0 and s.SFCmpID=c.UID and t.uid=s.sftypeid and (upper(ltrim(rtrim(t.StName))) in("PSOWS","SSAWS") ) and s.SFIsActive=1 if @WSid is null begin set @mess ="Рабочая станция "+@PCNAM+" не зарегистрирована." --FUCK !!! GoTo Fin end .......

← →
KSergey © (2004-09-20 16:15) [9]

> [8] Ega23 © (20.09.04 16:10)

Я немного не понял: а как пользователь к серверу-то логинится? Или у всех логинов как таковые права на все отключены? Или как? Я что-то не смог понять... Здесь по сути (если я верно понял) лишь настройка собственной авторизации - и все.. Т.е. доступ средствами именно SQL-сервера фактически и не используется. Верно?

← →
сергей1 (2004-09-20 16:21) [10]

2 Ksergey

очень просто, например, приложение клиента получило отказ в доступе, ты высветил матерное окно, а одновременно update"нул таблицу на серваке, обновив счетчик напротив данного пользователя. (доступ к этой таблице разрешить для всех клиентов без ввода пароля разумеется, они не должны даже подозревать о ней)
а на таблицу поставить триггер, который все что нужно сделает при превышении лимита.

2 ega23
в принципе для какого-нибудь банка не так-уж и пароноидально. А ты знаешь, что на MSSQL есть возможность использовать так называемые роли приложений, т.е. пользователь вошел в систему, под своей ролью, а приложение запускает ХП sp_setapprole, после чего все права пользователя аннулируются, и он получает только полномочия приложения. Это действует на всем протяжении подключения. Наверно, это удобней, но я никогда таким не пользовался, так как в паронаидольном банке не работаю :)

← →
Ega23 © (2004-09-20 16:22) [11]

Здесь по сути (если я верно понял) лишь настройка собственной авторизации - и все.. Т.е. доступ средствами именно SQL-сервера фактически и не используется. Верно?

Угу. Так точно!

← →
KSergey © (2004-09-20 16:40) [12]

> [11] Ega23 © (20.09.04 16:22)
> Здесь по сути (если я верно понял) лишь настройка собственной
> авторизации - и все.. Т.е. доступ средствами именно SQL-сервера
> фактически и не используется. Верно?

А если я возьму EnterpriseManager? Да даже просто Excel?? Не, это странная защита на мой вкус. Тогда уж просто все на клиенте делать, а иначе не понятно зафиг вообще сервер тут припрягать.. Или я что-то не понял? Я не вижу как такая схема может мне помешать сделать выборку из какой-либо таблицы...

> [10] сергей1 (20.09.04 16:21)
> очень просто, например, приложение клиента получило отказ
> в доступе, ты высветил матерное окно, а одновременно update"нул
> таблицу на серваке, обновив счетчик напротив данного пользователя.

И что толку? Для этого я должен уже залогиниться к серверу!!! А потом аксес в зубы - и впред!

> Наверно, это удобней, но я никогда таким не пользовался,
> так как в паронаидольном банке не работаю :)

Вот какие косяки при данном подходе: для этой роли можно разрулить права только в пределах одной базы, в остальные она идет с правами guest"а.
Т.е., к сожалению, guest"а приходится наделять слишком большими правами.
Что, в прнципе, при грамотном администрировании можно обрулить - но в случае ошибок результат может быть печален.
Однако это (по-моему) единственный способ не дать свободного доступа к серверу сторонними приложениями кроме определенных лиц (имеется в виду не физический доступ, понятно).

← →
Mystic © (2004-09-20 16:42) [13]

Нужно научиться какими-либо средствами блокировать логин при троекратном неправильном вводе пароля.

Вот это по-нашему! Получил список всех пользователей и заблокировал систему :)

← →
Ega23 © (2004-09-20 16:55) [14]

А если я возьму EnterpriseManager? Да даже просто Excel?? Не, это странная защита на мой вкус. Тогда уж просто все на клиенте делать, а иначе не понятно зафиг вообще сервер тут припрягать.. Или я что-то не понял? Я не вижу как такая схема может мне помешать сделать выборку из какой-либо таблицы...

На клиенте нет ЕМ. И Excel тоже нет. Если тебя интересует, зачем это так сделано, то милости прошу на egorov@dedal.dubna.ru - пообщаемся.

← →
сергей1 (2004-09-20 16:57) [15]

2 ksergey
>И что толку? Для этого я должен уже залогиниться к серверу!!!

ты логинишься другим коннектом, используя специальный логин и пароль, зашитый в клиентское приложение. Т.е. юзер ввел неверный пароль - сервер его послал подальше - в тайне от юзера запускается другой коннект с верным логином и паролем - апдейтит таблицу - отключается. Я сам это не делал, но причин для проблем не вижу

← →
Ega23 © (2004-09-20 16:59) [16]

ты логинишься другим коннектом, используя специальный логин и пароль, зашитый в клиентское приложение. Т.е. юзер ввел неверный пароль - сервер его послал подальше - в тайне от юзера запускается другой коннект с верным логином и паролем - апдейтит таблицу - отключается. Я сам это не делал, но причин для проблем не вижу

Так точно! У нас именно так и реализовано.

> [14] Ega23 © (20.09.04 16:55)
> На клиенте нет ЕМ. И Excel тоже нет

Гы ;) Ну поставить ЕМ - это не долго ;) Не, можно конечно и на клиенте грамотно администрировать, но опять получаем, что защита-то не на SQL-сервере! Вот в чем штука.

> 3 неудачных попыток. И подсчет таких попыток вести именно
> на сервере, т.е. клиент неудачно вводит пароль - увеличиваем
> счетчик в какой-нибудь запрятанной таблице.

Выделенное я понял именно как обработку при логине... А все остальное - понятно что можно наворотить, но останется узкое место, и опять защита по сути не будет сосредоточена в одном месте... и даже на сервере...

> [13] Mystic © (20.09.04 16:42)

Хм, а я о том как-то и не подумал ;))

>KSergey © (20.09.04 17:01) [17]
И не просто заблокировал систему, а заблокировал логин администратора (а пусть локти кусает), а сам в это время что-нибудь делаю...

> [18] panov © (20.09.04 17:03)
> >KSergey © (20.09.04 17:01) [17]
> И не просто заблокировал систему, а заблокировал логин администратора
> (а пусть локти кусает), а сам в это время что-нибудь делаю...

Ну совсем так не получится, видимо (я пока не увидел здесь технических возможностей; в теории понятно).
Да, я имею в виду админа в понимании SQL-сервера, а не некоего прикладного, проходящего через эту защиту.

← →
сергей1 (2004-09-20 17:53) [20]

> И не просто заблокировал систему, а заблокировал логин администратора

а для таких вещей есть профайлер, там можно настроить аудит неудачных логинов. Если много раз пытались залогиниться под админа - надо меры предпринимать. Возможно, есть способ эту инфу как-нибудь автоматически анализировать, тогда и навороты с дополнительным коннестом не потребуются

serg_newone - Как ты решил этот вопрос ? (Я знаю решение только для Oracle). Плз - напиши, а то мастера всякую ерунду предлагают.

← →
сергей1 (2004-09-20 20:35) [22]

все, кажется нашел нормальный способ аудита неудачных подключений.

-Запускаем sql profiler
-выбираем new trace
-на вкладке general указываем Save to table, указываем желаемую таблицу для аудита (например, я указал таблицу myaudit
в базе master)
-переходим на вкладку events
-так как нас интересуют неудачные подключения, в поле selected event classes удаляем все события
-из вкладки available event classes выбираем узел security audit, а в нем отмечаем audit login failed
-добавляем его в правое поле
-жмем run

профайлер можно свернуть, но не закрывать, а то процесс уничтожиться

Теперь, в качестве эксперимента, из дельфи, в настройках строки подключения для connection, указываем левый логин и
пароль (я написал логин haker), тестим соединение, нас посылают в жопу.

идем в query analyzer, запускаем следующий скрипт:

use master
select LoginName from myaudit where LoginName is not null

в резалт сете видим слово haker (если несколько раз будем коннектиться, таких строк будет несколько)
(для интереса можно написать select *, там всякая доп. инфа)

теперь если все это хозяйство поставить в расписание (в виде ХП), например каждые 10 мин., то можно легко анализировать
количество неудачных подключений, и при необходимости отключать логин, или пойти постучать этому хакеру по морде

← →
сергей1 (2004-09-20 21:26) [23]

в смысле триггер конечно, какое расписание.

Блокирование логина после троекратного неправильного ввода парол Найти похожие ветки