Вопросы по домену AD

Сообщения
10
#1
1. В win при первом входе пользователя в домен AD его пароль кешируется в SECURITY\Cache и у пользователя есть возможность логиниться при недоступном контроллере домена.
Как это реализовано в AstraLinux?

2. При входе пользователя с доменной учёткой пользователь не может зайти первые несколько минут (вероятно долго происходит подключение к контроллеру домена).
Какие есть решения?

3. В окне логона в систему поля логина и пароля очень маленькие, при вводе доменной учётки её начало пропадает.
Как увеличить длину полей?
 
Сообщения
66
#2
1. Не должны они кэшироваться по логике вещей и месту применения SE-редакции. В Win как бы тоже, чтобы не нарваться на mimikatz, ага...
2. Домен явно работает неустойчиво. Возможно, проблема на сетевом уровне, а не уровне ОС...
3. Пишите в техподдержку, чтобы расширили свойства полей в следующей сборке fly. Шансов на успех, правда, маловато...
 
Сообщения
10
#3
1. На ПК в том числе хранится пароль локального админа. Чем опаснее хранить на нём пароль простого пользователя домена? Кешировать или нет должно определяется в Group Policy домена. Полагаю, что данного функционала в AstraLinux просто нет? Если бы он был, то и проблемы N2 может быть не было.
 
Сообщения
863
#4
На ПК в том числе хранится пароль локального админа.
В Linux на компьютере нигде не хранится ни один пароли ни единого зарегистрированного пользователя.
Именно поэтому, никакой админ, никакой root, с любыми неограниченными правами - не может восстановить забытый пароль любого пользователя.
 
Сообщения
10
#6
В Linux на компьютере нигде не хранится ни один пароли ни единого зарегистрированного пользователя.
Именно поэтому, никакой админ, никакой root, с любыми неограниченными правами - не может восстановить забытый пароль любого пользователя.
Пароли пользователей хранятся в зашифрованном виде в файле /etc/shadow. Я не понимаю в чём проблема хранить там же пароли от доменных пользователей.
 
Последнее редактирование:
Сообщения
66
#7
to Learjet
По-хорошему, локальный админ должен быть заблокирован при первом же обновлении GPO. Но вы правы, тут должна иметься вариативность. Да и вопрос ушел в другую степь...
В старых nix пароль хранился непосредственно в /etc/passwd (было время, в открытом виде). Потом в хэш-виде+соль в /etc/shadow. Сейчас в большинстве случаев уже не в /etc/shadow (это "обманка")...
Вообще, надо ждать, когда допилят ALD. С поддержко "автономки", с "горячим резервированием" (из соседней ветки форума), с прочими радостями централизованного администрирования. С интерфейсом, понятным каждому "переезжающему" администратору...
Тов. Olej не слушайте. Он john в руках не держал, а rainbow table переводит не иначе как "настольная радуга", ага...
 
Сообщения
863
#8
Пароли пользователей хранятся в зашифрованном виде в файле /etc/shadow.
Ерунду пороть изволите. :eek: Никогда там паролей не было.
Конспектируйте ;): в UNIX сами пароли пользователей хранятся только в одном единственном месте - в голове у этих пользователей. В самой системе паролей, ни в открытом виде, ни как бы то ни было зашифрованных - нет.
 
Последнее редактирование:
Сообщения
426
#9
я хз, конечно, что там где хранится, но некоторое содержимое дублируется
cat /etc/passwd
user:$6$zy8qmfn5$p2PVWzwWiJaCKmGMvHeqc5o8ghh7hd/iacUeakWZV8ggCLyrGzLOwvVnLnbuZpNJF/EyMy2HFVu19Oo9b1ijy.:18092:0:99999:7:::

cat /etc/shadow
user:$6$zy8qmfn5$p2PVWzwWiJaCKmGMvHeqc5o8ghh7hd/iacUeakWZV8ggCLyrGzLOwvVnLnbuZpNJF/EyMy2HFVu19Oo9b1ijy.:18092:0:99999:7:::
 
Сообщения
863
#10
но некоторое содержимое дублируется
Ещё раз, для лучшего усвоения :p: самих паролей ни там (/etc/passwd) ни там (/etc/shadow) - нет.
По тем символьным последовательностям, что вы привели в примеры, обратная задача - восстановление вида пароля - не решается (даже зная алгоритм и то с чем сворачивался пароль при хэшировании).
 
Последнее редактирование:
Сообщения
426
#11
Ещё раз, для лучшего усвоения :p: самих паролей ни там (/etc/passwd) ни там (/etc/shadow) - нет.
Надо об этом рассказать составителям первой части руководства администратора (РУСБ.10015-01 95 01-1). А то понапишут фигни всякой, вводящей в заблуждение:
- /etc — содержит конфигурационные файлы ОС. Здесь находится файл паролей passwd
При добавлении пользователя в файл /etc/passwd вносится учетная запись в форме: login_name: encrypted_password: user_ ID: group_ ID: user_ information: login_directory: login_shell
Пароль будет зашифрован и внесен в файл /etc/shadow.
 
Сообщения
863
#12
Надо об этом рассказать составителям первой части руководства администратора (РУСБ.10015-01 95 01-1). А то понапишут фигни всякой, вводящей в заблуждение:
И, боже вас сохрани, не читайте до обеда советских газет. ... Пациенты, не читающие газет, чувствуют себя превосходно. Те же, которых я специально заставлял читать «Правду», теряли в весе.
© М.Булгаков
 
Сообщения
66
#13
*в сторону*
Ставлю точку в вопросах верю не верю, буду не буду, хранятся или не хранятся и, особенно, вот в этом перле:

По тем символьным последовательностям, что вы привели в примеры, обратная задача - восстановление вида пароля - не решается (даже зная алгоритм и то с чем сворачивался пароль при хэшировании).
Использовал:
  • Astra Linux Special Edition 1.6 с конфигурациями по умолчанию;
  • программа взлома Unix-паролей john (всеми любимый John the Ripper)
  • Debian 9 x64 (VirtualBox-контейнер) со стандартным репозиторием, в котором john, собственно, имеется (подключать репу к Astra SE моветон - она мне "чистой" нужна, ага);
  • учетную запись root под Astra Linux SE 1.6 с паролем 12qwASZX (для наглядности и ускорения процесса).

А теперь, внимание, уважаемые знатоки, спойлер! Все комментарии за символом # (классика, ага):
# убеждаемся, что у нас именно Astra Linux Special Edition 1.6
root@astra:~# cat /etc/issue.net
Astra Linux SE 1.6 (smolensk)


root@astra:~# cat /etc/shadow
root:$6$zR/78t/3$0ibPGyRMiflAnMJkBk4ghSIwFPEI7bGDnZeN3yATS2h9ofMz3uFBOIRHqsjxJ3LLXEm6TMoYBCMXc1cJ8IZ560:18096:0:99999:7:::

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

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

root@debian-9-64 ~ # cat /root/words.lst
12345678
87654321
12qwASZX
12qw#$ER
1q2w#E$R
18273645


# переносим на эту же машину наш выхлоп cat /etc/shadow в файл /root/rules.lst, из которого john будет читать хэш
root@debian-9-64 ~ # cat /root/rules.lst
root:$6$zR/78t/3$0ibPGyRMiflAnMJkBk4ghSIwFPEI7bGDnZeN3yATS2h9ofMz3uFBOIRHqsjxJ3LLXEm6TMoYBCMXc1cJ8IZ560:18096:0:99999:7:::


# скармливаем результаты john'у и наслаждаемся результатом брута по словарю
# для тех, кто в танке, выловленный пароль специально выделил, ага

root@debian-9-64 ~ # john --wordlist=/root/words.lst --rules /root/rules.lst
Loaded 1 password hash (crypt, generic crypt(3) [?/64])
Press 'q' or Ctrl-C to abort, almost any other key for status
12qwASZX (root)
1g 0:00:00:00 100% 16.66g/s 183.3p/s 183.3c/s 183.3C/s 12345678..1q2w#$r
Use the "--show" option to display all of the cracked passwords reliably
Session completed

Выводы по результатам:
  1. Очень жаль, что Astra Linux SE 1.6 по умолчанию юзает алгоритм хэширования, аналогичный Debian 9 - SHA-512. Могли бы и GOST-2012-256, и свой Parsec-алгоритм прикрутить "из коробки" - это бы усложнило задачу john'у. Или хотя бы добавить требование в Руководство или в RedBook. Насколько такой подход допустим - опустим (холивар в тему SecurityThrouObscurity, надеюсь, не разгорится)...
  2. SHA-512 что в Astra, что в Debian отличается от стандарта - длина результирующего хэша меньше, чем положено. Это результат применения "соли" (в приведенном примере - zR/78t/3) и особенностей применения алгоритма (по умолчанию, 5000 циклов). В частности, стандартные online-сервисы такой хэш с "солью" не переваривают. Утилита hashcat тоже, хотя нормально проверить ее работу не удалось - Win-версия отказалась кушать "соль", а nix-версия под VirtualBox не принимает параметров ни GPU (по понятным причинам), ни CPU (что странно)...
  3. Брут по словарю или без - единственный вменяемый вариант взлома связки хэш-пароль-с-"солью" ("терморектальный криптоанализ", продуктивнее, но сложнее в реализации, ага). "Радужные таблицы" помогут только в исключительно малом проценте случаев ("соль"-то псевдослучайная, ага). Чем полнее словарь или чем больше вычислительных ресурсов для брута, тем он быстрее и продуктивнее (спасибо, Капитан!)...
ЗЫ Тов. Olej может возразить, что у него была семантическая ошибка в приведенных выше безапелляционных высказываниях, но... мне, собственно, плевать, потому что уже привык к его пустословию результат говорит сам за себя: восстановить значение пароля любого пользователя в nix возможно, имея на руках хэш пароля и "соль" и обладая правами доступа к нужному файлу их хранения (как правило, /etc/shadow). Узкие места, влияющие на скорость восстановления: длина и сложность пароля, достаточность словаря и/или вычислительного ресурса...
 
Сообщения
426
#14
*в сторону*
Ставлю точку в вопросах верю не верю, буду не буду, хранятся или не хранятся и, особенно, вот в этом перле:



Использовал:
  • Astra Linux Special Edition 1.6 с конфигурациями по умолчанию;
  • программа взлома Unix-паролей john (всеми любимый John the Ripper)
  • Debian 9 x64 (VirtualBox-контейнер) со стандартным репозиторием, в котором john, собственно, имеется (подключать репу к Astra SE моветон - она мне "чистой" нужна, ага);
  • учетную запись root под Astra Linux SE 1.6 с паролем 12qwASZX (для наглядности и ускорения процесса).

А теперь, внимание, уважаемые знатоки, спойлер! Все комментарии за символом # (классика, ага):
# убеждаемся, что у нас именно Astra Linux Special Edition 1.6
root@astra:~# cat /etc/issue.net
Astra Linux SE 1.6 (smolensk)


root@astra:~# cat /etc/shadow
root:$6$zR/78t/3$0ibPGyRMiflAnMJkBk4ghSIwFPEI7bGDnZeN3yATS2h9ofMz3uFBOIRHqsjxJ3LLXEm6TMoYBCMXc1cJ8IZ560:18096:0:99999:7:::

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

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

root@debian-9-64 ~ # cat /root/words.lst
12345678
87654321
12qwASZX
12qw#$ER
1q2w#E$R
18273645


# переносим на эту же машину наш выхлоп cat /etc/shadow в файл /root/rules.lst, из которого john будет читать хэш
root@debian-9-64 ~ # cat /root/rules.lst
root:$6$zR/78t/3$0ibPGyRMiflAnMJkBk4ghSIwFPEI7bGDnZeN3yATS2h9ofMz3uFBOIRHqsjxJ3LLXEm6TMoYBCMXc1cJ8IZ560:18096:0:99999:7:::


# скармливаем результаты john'у и наслаждаемся результатом брута по словарю
# для тех, кто в танке, выловленный пароль специально выделил, ага

root@debian-9-64 ~ # john --wordlist=/root/words.lst --rules /root/rules.lst
Loaded 1 password hash (crypt, generic crypt(3) [?/64])
Press 'q' or Ctrl-C to abort, almost any other key for status
12qwASZX (root)
1g 0:00:00:00 100% 16.66g/s 183.3p/s 183.3c/s 183.3C/s 12345678..1q2w#$r
Use the "--show" option to display all of the cracked passwords reliably
Session completed

Выводы по результатам:
  1. Очень жаль, что Astra Linux SE 1.6 по умолчанию юзает алгоритм хэширования, аналогичный Debian 9 - SHA-512. Могли бы и GOST-2012-256, и свой Parsec-алгоритм прикрутить "из коробки" - это бы усложнило задачу john'у. Или хотя бы добавить требование в Руководство или в RedBook. Насколько такой подход допустим - опустим (холивар в тему SecurityThrouObscurity, надеюсь, не разгорится)...
  2. SHA-512 что в Astra, что в Debian отличается от стандарта - длина результирующего хэша меньше, чем положено. Это результат применения "соли" (в приведенном примере - zR/78t/3) и особенностей применения алгоритма (по умолчанию, 5000 циклов). В частности, стандартные online-сервисы такой хэш с "солью" не переваривают. Утилита hashcat тоже, хотя нормально проверить ее работу не удалось - Win-версия отказалась кушать "соль", а nix-версия под VirtualBox не принимает параметров ни GPU (по понятным причинам), ни CPU (что странно)...
  3. Брут по словарю или без - единственный вменяемый вариант взлома связки хэш-пароль-с-"солью" ("терморектальный криптоанализ", продуктивнее, но сложнее в реализации, ага). "Радужные таблицы" помогут только в исключительно малом проценте случаев ("соль"-то псевдослучайная, ага). Чем полнее словарь или чем больше вычислительных ресурсов для брута, тем он быстрее и продуктивнее (спасибо, Капитан!)...
ЗЫ Тов. Olej может возразить, что у него была семантическая ошибка в приведенных выше безапелляционных высказываниях, но... мне, собственно, плевать, потому что уже привык к его пустословию результат говорит сам за себя: восстановить значение пароля любого пользователя в nix возможно, имея на руках хэш пароля и "соль" и обладая правами доступа к нужному файлу их хранения (как правило, /etc/shadow). Узкие места, влияющие на скорость восстановления: длина и сложность пароля, достаточность словаря и/или вычислительного ресурса...
А по приведенной мной мной строчке из shadow и passwd сможете пароль расшифровать?
 
Сообщения
863
#15
А по приведенной мной мной строчке из shadow и passwd сможете пароль расшифровать?
Товарисч (хотя какой он нам нахер товарисч?) oko вам опять подбрасывает своё говно на ваш вентилятор: известная (и достаточно убогая) программа John The Ripper (дословно "Джон-потрошитель" - прям куда там?) применяется для вскрытия (или аудита) слабых паролей в UNIX системах путём перебора возможных вариантов.
Тупой перебор наугад всех возможных вариантов отличается от алгоритмического восстановления пароля примерно так же, как решение задачи на экзамене по математике отличается от тупого угадывания ответа в тестах - по выражению лица преподавателя ... или как палец отличается ... ну, от известного вам органа только своим внешним сходством. o_O

P.S. И что особенно характерно, популяризируют, описывают и распространяют John The Ripper, "серебряную пулю", на тысячах сайтов, подавляющим образом, юные прыщавые выньдауны-кулцхакеры, в формате .exe программы, которой они собираются "вскрывать тот UNIX" (которого они, в большинстве, и в глаза свои не видели). Такой вот моветон никого из присутствующих не смущает?
 
Последнее редактирование:
Сообщения
863
#16
А по приведенной мной мной строчке из shadow и passwd сможете пароль расшифровать?
Вы всё прекрасно поняли, Montfer: вот и проверьте oko на вшивость вскрытием вашего, наверняка самого простейшего, примитивного пароля (кто же при инсталляции указывает более-менее серьёзный пароль? :p). И с указанием за какое время ему это удастся, если когда-нибудь ему вообще такое удастся...

P.S. Хотя вы, любой желающий, может всё это легко проверить самостоятельно, установив без труда в Astra Linux CE с элементарно подключенным репозиторием Debian:
Код:
olej@astra:~$ aptitude search john
p   fonts-johnsmith-induni                                                - OTF fonts with exhaustive set of Roman characters                              
p   golang-github-benbjohnson-tmpl-dev                                    - Command line interface to Go's text/template library - dev package            
p   john                                                                  - active password cracking tool                                                  
p   john:i386                                                             - active password cracking tool                                                  
p   john-data                                                             - active password cracking tool - character sets
Установите и репетируйте - упирайтесь рогами в своё удовольствие... :cry:
 
Последнее редактирование:
Сообщения
426
#17
Товарисч (хотя какой он нам нахер товарисч?) oko вам опять подбрасывает своё говно на ваш вентилятор: известная (и достаточно убогая) программа John The Ripper (дословно "Джон-потрошитель" - прям куда там?) применяется для вскрытия (или аудита) слабых паролей в UNIX системах путём перебора возможных вариантов.
Тупой перебор наугад всех возможных вариантов отличается от алгоритмического восстановления пароля примерно так же, как решение задачи на экзамене по математике отличается от тупого угадывания ответа в тестах - по выражению лица преподавателя ... или как палец отличается ... ну, от известного вам органа только своим внешним сходством. o_O

P.S. И что особенно характерно, популяризируют, описывают и распространяют John The Ripper, "серебряную пулю", на тысячах сайтов, подавляющим образом, юные прыщавые выньдауны-кулцхакеры, в формате .exe программы, которой они собираются "вскрывать тот UNIX" (которого они, в большинстве, и в глаза свои не видели). Такой вот моветон никого из присутствующих не смущает?
И всё таки эксперимент oko показал, что пароль хранится и он зашифрован. Получается, что топик-стартер и РУСБ.10015-01 95 01-1 не врут...
 
Сообщения
66
#20
to Montfer
Пароль ни в открытом, ни в шифрованном виде не хранится. Уже писал выше: в /etc/shadow (зачем-то в Astra и в /etc/passwd) хранится ХЭШ пароля, полученного применением определенного алгоритма выработки хэш-функции (по умолчанию, SHA-512) к результирующему значению операции конкатенации пароля и "соли". "Соль" - псевдослучайная последовательность "символов" (те самые zR/78t/3 ), которая также хранится в /etc/shadow. Хэш - результат выполнения однонаправленной (в теории) функции...
При авторизации пользователя в nix - читай, ввод пары "логин и пароль" - система:
  • ищет введенный "логин" по списку /etc/passwd;
  • при нахождении "логина" система ищет в /etc/shadow (/etc/passwd) строку "соль"+хэш (и доп.данные, которые в данном контексте не интересуют);
  • там же система определяет алгоритм хэширования ($6$ в приведенном примере - SHA-512);
  • получив указанные сведения, система берет введенный пользователем пароль, добавляет к нему известную "соль", проводит хэширование по указанному алгоритму и сравнивает результат с хэшем, приведенным в /etc/shadow (/etc/passwd);
  • при совпадении результирующей строки с хэшем система подтверждает авторизацию, иначе - запрещает.
Для части алгоритмов хэширования имеются известные уязвимости, связанные с поиском коллизий на ошибки 1 и 2 рода. Грубо говоря, на выходе применяемого алгоритма (в частности, MD5, который на заре времен в nix тоже применялся) возможно получить один и тот же хэш для двух и более разных введенных паролей (строк). SHA-512 такими проблемами пока "в открытую" не страдает, поэтому он и применяется в nix по умолчанию...

Вскрыть хэш (любой) возможно путем грубого перебора (bruteforce-атака), что, собственно, выполняет john и демонстрировал мой пример. Для упрощения атаки, повышения ее скорости и наглядности был использован словарь - атака-по-словарю, являющаяся подмножеством bruteforce-атак. В общем случае при bruteforce атакующий последовательно перебирает все возможные комбинации вводимых данных, применяя к ним известный алгоритм хэширования и известную "соль". Потом сравнивает результат с известным хэшем неизвестного пароля и повторяет процедуру, если результат не совпал...
Имеется ряд математических выкладок, подтверждающих невозможность успешной bruteforce-атаки для "сложных" паролей определенного типа + определенного алгоритма хэширования (тот же SHA-512) + при отсутствии такого "сложного" пароля в словаре атакующего (т.е. перевод bruteforce-атаки в полный случай, а не частный) - за допустимое время на текущем уровне развития и доступности технологий. Постараюсь перевести так, чтобы все поняли:
  • если пароль пользователя "сложный" (для примера нечто подобное: $7cm2@*9c!N#$%XS);
  • если этот пароль отсутствует в словаре атакующего (т.е. придется "брутить" последовательно и посимвольно);
  • если длина пароля атакующему неизвестна;
  • если используется алгоритм хэширования, устойчивый к поиску коллизий;
  • если нарушитель не обладает неограниченной вычислительной мощностью;
  • тогда и только тогда пароль невозможно будет восстановить из его хэша за время, доступное нарушителю для проведения атаки.

Могу проверить и ваш пароль, но для этого потребуется время, потому что:
  • неизвестна длина;
  • неизвестны примененные правила "сложности";
  • вычислительный ресурс - виртуальная ОС на 1024 Мб ОЗУ и 2 потока ЦП i7-4700.
При таких исходных данных поставлю на ночь, утром поглядим результат.


to Olej
Вы заявляли буквально следующее:
<в UNIX сами пароли пользователей хранятся только в одном единственном месте - в голове у этих пользователей. В самой системе паролей, ни в открытом виде, ни как бы то ни было зашифрованных - нет. >
Это не вся правда. Формулировка должна быть другой: "в nix отсутствует хранение паролей в открытом/шифрованном виде, но присутствует хранение их хэш-значений в соответствующих файлах"...

<По тем символьным последовательностям, что вы привели в примеры, обратная задача - восстановление вида пароля - не решается (даже зная алгоритм и то с чем сворачивался пароль при хэшировании)>
Это тоже только часть правды. Нужная формулировка: "при соблюдении ряда условий (см. перечень, приведенный выше) задача unhash(hash(passwd) не имеет решений; большинство атак сводятся к lim(hash[passwd1, passwd2, passwd3 ... passwdN]) <> hash(passwd) при N -> бесконечность"...

<Именно поэтому, никакой админ, никакой root, с любыми неограниченными правами - не может восстановить забытый пароль любого пользователя>
Это неправда, проведенный выше эксперимент показал, что восстановить пароль возможно. Сейчас вы пытаетесь прикрыть свою задницу, уточняя, что под "восстановить" понимали иное: <Тупой перебор наугад всех возможных вариантов отличается от алгоритмического восстановления пароля>. С такой формулировкой никто не спорит - хэш-функция однонаправленная, да -, но ее следовало уточнить вначале. Вводя подобный аргумент сейчас, вы либо расписываетесь в собственной неграмотности, либо признаетесь в том, что смотрите на всех участников форума как на говно (что еще хуже)...

<И что особенно характерно, популяризируют, описывают и распространяют John The Ripper, "серебряную пулю", на тысячах сайтов>
Здесь опять перл для фонда хреновых цитат. John - общепризнанный инструмент, появившийся в те времена, когда появилось хэширование паролей в nix. Никто никогда его не называл "серебряной пулей" - только вы и только сейчас...

Резюмируя:
Тов. Цилюрик, от ваших 8 сообщений в этой теме пользы нет от слова никак, зато вони... Понимаю, что возраст, что геморрой уже, небось, с кулак вырос, энергию девать некуда (+100500 тем и ответов самому себе на форуме rus-linux.net это подтверждают), но... зачем тащить это в другие места, через раз поминая какие-то тысячи сайтов и каких-то виндузятников? Если знаете "как надо", напишите или сделайте, чтобы вопрошающие поняли суть. Если не знаете или не хотите - не вякайте из-за унитаза, надувая щеки и строя из себя гуру...
 
Последнее редактирование: