понедельник, 22 июня 2015 г.

CIFS с kerberos-авториацией

Решил окучить вопрос подключения windows-шар с использованием билета kerberos. Небезопасно как-то хранить plain-текстом доменные учётные данные, а вводить каждый раз ручками - не наш метод. В принципе, оказалось, что всё, что надо, есть из коробки. Потребуются пакеты:
sudo apt-get update 
sudo apt-get install krb5-user cifs-utils keyutils
 При грамотно настроенном DNS настройка kerberos-клиента сводится к указанию REALM домена windows по-умолчанию (рекомендуется указывать в верхнем регистре, например EXAMPLE.COM), который будет запрошен при установке и может быть изменен в /etc/krb5.conf. Если всё правильно, то с получением билет не должно возникнуть проблем:
kinit vasiliy
Password for 
vasiliy@EXAMPLE.COM:
klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: vasiliy@
EXAMPLE.COM
Valid starting       Expires              Service principal
22.06.2015 21:28:02  23.06.2015 07:28:02  krbtgt/
EXAMPLE.COM@EXAMPLE.COM
renew until 23.06.2015 21:27:57
Вывод команды klist отобразит информацию о полученном билете. Чтобы монтировать сетевую шару без необходимости прав root внесем в /etc/fstab следующую строку:
//host.example.com/development /home/vasiliy/Dev cifs rw,user,noauto,sec=krb5,username=vasiliy,domain=EXAMPLE.COM 0 0
Точку монтирования /home/vasiliy/Dev, естественно, надо создать. Также хочу указать на необходимость указания  настроек подключения cifs именно в fstab - с командой строки они браться не будут. Если не указывать username и domain, то будут использоваться из хранилища ключей (?). Т.е. строку можно будет использовать любому пользователю станции. Монтируем и отмонтируем командами, соответственно:
mount /home/vasiliy/Dev
umount /home/vasiliy/Dev
ЗЫ. Ошибка вида:
mount error(128): Key has been revoked 
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) 
решается полным завершением сеанса оболочки и повторным логином. Такое ощущение, что mount не может найти, где лежит keytab... Нужно проверять.

суббота, 23 мая 2015 г.

О дырявых роутерах...

Звонит мне, значится, сегодня друг и говорит.
Что-то с Контактом какая-то фигня. Работает-работает, бах, сваливается на страницу авторизации. А на этой странице кроме кнопки войти всё остальное не работает и выдаёт ошибку. Вчера весь день комп на предмет вирусной дряни шмонал - ничего. А сегодня заметил, что и телефон при работе через wi-fi вытворяет то же самое. Сейчас подключил напрямую Интернет без роутера - вроде бы всё нормально. Может быть проблема в роутере?
Ну тут мне вспомнился давешний пост на OpenNet. Роутер Asus RT-N10R. Попросил сделать вывод nslookup:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\User>nslookup vk.com
Server: UnKnown
Address: 178.208.81.126

Name: vk.com
Address: 178.208.81.126
А должно быть как-то так:
C:\Users\User>nslookup vk.com
Server: router.asus.com
Address: 192.168.1.1
 
Non-authoritative answer:
Name: vk.com
Addresses: 2a00:bdc0:3:103:1:0:403:901
2a00:bdc0:3:103:1:0:403:902
2a00:bdc0:3:103:1:0:403:903
87.240.131.99
87.240.131.97
87.240.131.120
Т.е. роутер отдавал клиентам сети в качестве dns-сервера 178.208.81.126 - адрес злоумышленника. При обращении к этому адресу 178.208.81.126 вылезла страничка "типа, одноклассников". В коде страницы честно присутствует:
<!DOCTYPE html>
<!-- saved from url=(0013)http://ok.ru/ -->
<html class=" an
Если запросить vk.com - вылезет страничка входа Контактика. Сброс роутера проблему временно решил. Обновили до последней прошивки. При возможности дополню.
PS. Будьте внимательны, используйте двухфакторную аутентификацию.
PS2. Аналогичный случай

воскресенье, 26 апреля 2015 г.

squid3 и неожиданно помирающая доменная авторизация

Однажды в понедельник неожиданно умерла корпоративная прокси на squid. У пользователей она съезжала на basic авторизацию, вместо доменной. В cache.log на каждый запрос сыпалось:
authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. '
 Что сбило с толку, так это то, что перезапуск сервиса на какое-то время решал проблему. Минут на 10-15. И потом всё повторялось снова и снова. В какой-то момент sudoedit руганулся на недостаток памяти, хотя df -h радовал свободным пространством. Тут-то коллега и нашёл ЭТО. У нас исчерпались inodЫ. Вывод df -i это подтвердил. И причина была та же самая. SARG, который бесконтрольно плодил свои отчёты каждый день, неделю и месяц. Найти врага можно командой:
for i in /*; do echo $i; find $i | wc -l; done
 которая покажет, в каком каталоге больше всего израсходовано inodes. Файлов было не такое количество, чтобы возникли проблемы с их удалением.

четверг, 22 января 2015 г.

SQL Server 2012 Express, VipNet и KB2992611

Как-то неожиданно помер локальный SQL Server 2012. Т.е. как сказать, помер... Служба жива, но достучаться до нее никто не мог. Ни приложение, её использующее, ни Managment Studio с однотипной ошибкой:
Подключение к серверу успешно установлено, но затем произошла ошибка при входе. (provider: Поставщик общей памяти, error: 0 - С обоих концов канала отсутствуют процессы
В журнал Windows сыпались сообщения:
 Google порадовал ссылкой на форум:
http://www.infotecs.ru/forum/index.php?showtopic=8032&st=120
Тут-то я и вспомнил, что накануне прилетели обновления, а вместе с ними и KB2992611. И VipNet есть у меня. Удалил обнову, поехало. Читаю. Найду еще какую информацию - дополню.

Продолжение истории от 14 июня 2016 года
И снова здравствуйте. После обновлений сдохло подключение по RDP c примерно следующим текстом:
Произошла ошибка при проверке подлинности.
Не удается установить связь с локальной системой безопасности
Удаленный компьютер: *****
Причиной ошибки может быть пароль с истекшим сроком действия.
Обновите ваш пароль, если срок его действия истек.
Обратитесь за помощью к вашему администратору или в службу технической поддержки.
Вместе с ним прихватило и локальный MSSQL-сервер, служба которого наотрез отказывалась даже запускаться с ворохом ошибок в журналах. В Системе: Service Control Manager 7024. В приложениях: MSSQL$SQLEXPRESS 26011, 17182, 17826, 17210 с жалобами на проблемы с библиотекой безопасности, вплоть до отсутствия security.dll и на невозможность установить SSL-соединение.
Удаление обновлений не принесло желаемого результата. На просторах Интернет предлагалось запустить cspclean.exe для вычищения хвостов CryptoPro CSP. Но мне это не помогло. Точнее как, не помогло. После ребута винда падала с синим экраном 0x000000f4. Помогал запуск последней удачной конфигурации (первый раз в жизни=), но он, понятное дело, все хвосты возвращал взад. На тот момент на компе уже не было ни крипто про, ни випнета, ни вигейта. Начал поочередно устанавливать и удалять этот софт. Что установка, что удаление випнет приводила к тому же синему экрану. А вот после установки vipnet_csp_rus_4.2.5.35526_beta указанные выше проблемы ушли.