Бескрайние белоснежные просторы(с)
Size: a a a
2017 December 09
2017 December 10
Университет Иннополис
2017 December 11
apt-cacher-ng или читайте мануалы
Столкнулся тут с проблемой whitelist'инга репозитория. Задача - дать пользователю возможность ходить только до выбранных конкретных адресов, в том числе и до некоторых репозиториев (kali, debian). Для ускорения работы был также установлен apt-cacher-ng. Репозиторий kali отработал на ура - было добавлено в iptables несколько адресов и всё заработало. А вот с mirror.yandex.ru не работало. nslookup однозначно резолвил его в один единственный адрес, который и был добавлен в исключения, но это не сработало. Вооружившись tcpdump я выяснил что запрос
на выходе с интерфеса принимает вид:
Обратный резолв адреса 130.89.148.12.80 дает нам dns-имя klecker2.snt.utwente.nl
Скачав исходники и грепнув их по yandex увидел файл conf/ubuntu_mirrors, где живет список зеркал debrep. Что приводит нас к директиве Remap-debrep и информации в мануале, о том что это не баг, а фича. Считается, что урлы из этого файла взаимозаменяемы и подбираются исходя из каких-то представлений acng в данной конкретной лунной фазе. Поэтому, если пользоваться acng как прокси для скачивания файла с конкретного репозитория, если он есть в списке ремапа, можно нарваться на то что вы пойдете совсем по другому адресу в конечном итоге. Я решил особо не париться и просто сделал свой субдомен mirror. Этого адреса точно нет в файлах ремапа, а значит резолв будет as is.
Столкнулся тут с проблемой whitelist'инга репозитория. Задача - дать пользователю возможность ходить только до выбранных конкретных адресов, в том числе и до некоторых репозиториев (kali, debian). Для ускорения работы был также установлен apt-cacher-ng. Репозиторий kali отработал на ура - было добавлено в iptables несколько адресов и всё заработало. А вот с mirror.yandex.ru не работало. nslookup однозначно резолвил его в один единственный адрес, который и был добавлен в исключения, но это не сработало. Вооружившись tcpdump я выяснил что запрос
wget http://172.16.5.1:3142/mirror.yandex.ru/debian/dists/stretch/Release
на выходе с интерфеса принимает вид:
20:27:31.386857 IP 192.168.114.10.38840 > 130.89.148.12.80: Flags [P.], seq 1:297, ack 1, win 457, options [nop,nop,TS val 10308598 ecr 3214247], length 296: HTTP: GET /debian/dists/stretch/Release HTTP/1.1
Обратный резолв адреса 130.89.148.12.80 дает нам dns-имя klecker2.snt.utwente.nl
Скачав исходники и грепнув их по yandex увидел файл conf/ubuntu_mirrors, где живет список зеркал debrep. Что приводит нас к директиве Remap-debrep и информации в мануале, о том что это не баг, а фича. Считается, что урлы из этого файла взаимозаменяемы и подбираются исходя из каких-то представлений acng в данной конкретной лунной фазе. Поэтому, если пользоваться acng как прокси для скачивания файла с конкретного репозитория, если он есть в списке ремапа, можно нарваться на то что вы пойдете совсем по другому адресу в конечном итоге. Я решил особо не париться и просто сделал свой субдомен mirror. Этого адреса точно нет в файлах ремапа, а значит резолв будет as is.
https://habrahabr.ru/post/344376/Feed%3A+habr%2FRuHackersNews+%28RuHackersNews+%5Bhabrahabr%5D%29
На текущий момент уязвимость существует во всех версиях Windows, начиная с Windows XP и заканчивая последней версией Windows 10 Fall Creators Update. В последней был баг, из-за которого применение Process Doppelgänging роняло систему в «синий экран смерти», но Микрософт с тех пор этот баг исправила...
... и теперь этот баг работает везде:)
На текущий момент уязвимость существует во всех версиях Windows, начиная с Windows XP и заканчивая последней версией Windows 10 Fall Creators Update. В последней был баг, из-за которого применение Process Doppelgänging роняло систему в «синий экран смерти», но Микрософт с тех пор этот баг исправила...
... и теперь этот баг работает везде:)
2017 December 13
А ваш эпл додумался до такого?
Стикеры подъехали =) хз зачем, но почему бы и нет
2017 December 14
Посмотреть назначенные externalIPs в kubernetes:
kubectl get svc --all-namespaces -o yaml|ruby -ryaml -e 'puts YAML.load($<)["items"].map{|i| i["spec"]["externalIPs"]}.compact.flatten.sort.join("\n")'2017 December 15
Вот и закончилось мероприятие Digital Skills в г.Иннополис. Наша группа представляла в нем компетенцию "Анализ защищенности информационных систем".
Не скажу что доволен проведенным мероприятием, скорее были даже моменты где налажали. Проблемы начались за некоторое время до мероприятия, когда мы узнали, что заказчик не предоставит нам на площадке оборудование. Сервер договорились все-таки сделать в облаке, но на самой площадке нужно было поставить свой коммутатор и маршрутник. Коммутатор (24p, rack) буквально перед выходом я одолжил у коллеги с работы, за что ему огромное спасибо. а вот маршрутником был Raspberry Pi 2011 года. И если с коммутатором все ок, то как оказалось rpi этого года не смотря на заявленную 100-base-t сетевуху не смог вытянуть на intervlan routing более 3 mib/s.
На площадке одной из проблем было то что группа сетевых инженеров мероприятия не имела полный доступ к управлению сетью самого университета. все необходимо было согласовывать с местными инженерами, что вносило дополнительную задержку. Правда особых проблем это не доставило, ну пожили в разных vlan несколько дней площадка участников и экспертная комната, ничего страшного. К слову ребята на общение очень приятные и реагировали на просьбы очень оперативно, за что им отдельное спасибо.
Сама компетенция состояла из 3-х этапов:
- 15 jeopardy задач на web-уязвимости (blackbox)
- восстановить уязвимый сайт из бекапа, закрыть уязвимости и описать их
- провести аудит развернутого приложения, закрыть уязвимости и описать их
Первый этап был CTF. Но, без интернета. Задумка конечно так себе, но это были условия проведения мероприятия. Изначально участникам вообще хотели дать винду, браузер и блокнот. и 15 тасков на web, мол решайте как хотите. Я настоял на добавлении в комплект Kali Linux и открыть доступ к репозиториям kali, yandex.
Начался первый этап вроде спокойно, участники анализировали задания. как вдруг стали поступать жалобы на то что они недоступны. Оказалось у хостера дедик упал в розовую смерть. На ходу было принято решение реквезировать 4-е рабоче место под сервер и в срочном порядке поднимать задания на нем. Благодаря тому что все наши таски находятся в докер репозитории, это заняло около 40 минут - на то чтобы поднять виртуалку и раскопировать конфиги. После чего самым узким местом остался только rpi, но вроде после этого жалоб от участников не поступало. Были ли они по-прежнему недовольны? Вероятно. Я не горжусь качеством данного мероприятия, но, однако, значительный процент неудач лежит на плечах людей, которые отвечали за оборудование, из-за отсутстствия которого пришлось везти свое и колхозить из того что есть.
По результатам первого этапа было понятно - решать CTF без интернета - маразм. Специалист должен понимать как работает уязвимость, но не заучивать эксплойты. Он должен суметь быстро разобраться и найти способ. В этом отношении мне нравятся write-up'ы Сергея Боброва. Он пишет честно что не знает сразу о том что за уязвимость ковыряет, но опыт и накопленные знания позволяют быстро разобраться в сути, что именно нужно искать в мануалах к продуктам и способам их эксплуатации, как результат - часто он первый или один из первых решает задачи (как например Zero Nights Hack Quest)
"1 этап после обеда". А после обеда мне пришлось ехать в аэропорт и фактически бросить стенд. Все это не потому что мне наплевать, а из-за безалаберного подхода одного из заказчиков к покупке билетов. Ну, чтож, ладно. Надеюсь, что игроки не совсем плевались от мероприятия, с учетом всех ограничений.
Кстати в компетенции учатсвовал один из авторов UFO-CTF. Он выйграл первый этап и зарешал около 5 заданий из 15.
Не скажу что доволен проведенным мероприятием, скорее были даже моменты где налажали. Проблемы начались за некоторое время до мероприятия, когда мы узнали, что заказчик не предоставит нам на площадке оборудование. Сервер договорились все-таки сделать в облаке, но на самой площадке нужно было поставить свой коммутатор и маршрутник. Коммутатор (24p, rack) буквально перед выходом я одолжил у коллеги с работы, за что ему огромное спасибо. а вот маршрутником был Raspberry Pi 2011 года. И если с коммутатором все ок, то как оказалось rpi этого года не смотря на заявленную 100-base-t сетевуху не смог вытянуть на intervlan routing более 3 mib/s.
На площадке одной из проблем было то что группа сетевых инженеров мероприятия не имела полный доступ к управлению сетью самого университета. все необходимо было согласовывать с местными инженерами, что вносило дополнительную задержку. Правда особых проблем это не доставило, ну пожили в разных vlan несколько дней площадка участников и экспертная комната, ничего страшного. К слову ребята на общение очень приятные и реагировали на просьбы очень оперативно, за что им отдельное спасибо.
Сама компетенция состояла из 3-х этапов:
- 15 jeopardy задач на web-уязвимости (blackbox)
- восстановить уязвимый сайт из бекапа, закрыть уязвимости и описать их
- провести аудит развернутого приложения, закрыть уязвимости и описать их
Первый этап был CTF. Но, без интернета. Задумка конечно так себе, но это были условия проведения мероприятия. Изначально участникам вообще хотели дать винду, браузер и блокнот. и 15 тасков на web, мол решайте как хотите. Я настоял на добавлении в комплект Kali Linux и открыть доступ к репозиториям kali, yandex.
Начался первый этап вроде спокойно, участники анализировали задания. как вдруг стали поступать жалобы на то что они недоступны. Оказалось у хостера дедик упал в розовую смерть. На ходу было принято решение реквезировать 4-е рабоче место под сервер и в срочном порядке поднимать задания на нем. Благодаря тому что все наши таски находятся в докер репозитории, это заняло около 40 минут - на то чтобы поднять виртуалку и раскопировать конфиги. После чего самым узким местом остался только rpi, но вроде после этого жалоб от участников не поступало. Были ли они по-прежнему недовольны? Вероятно. Я не горжусь качеством данного мероприятия, но, однако, значительный процент неудач лежит на плечах людей, которые отвечали за оборудование, из-за отсутстствия которого пришлось везти свое и колхозить из того что есть.
По результатам первого этапа было понятно - решать CTF без интернета - маразм. Специалист должен понимать как работает уязвимость, но не заучивать эксплойты. Он должен суметь быстро разобраться и найти способ. В этом отношении мне нравятся write-up'ы Сергея Боброва. Он пишет честно что не знает сразу о том что за уязвимость ковыряет, но опыт и накопленные знания позволяют быстро разобраться в сути, что именно нужно искать в мануалах к продуктам и способам их эксплуатации, как результат - часто он первый или один из первых решает задачи (как например Zero Nights Hack Quest)
"1 этап после обеда". А после обеда мне пришлось ехать в аэропорт и фактически бросить стенд. Все это не потому что мне наплевать, а из-за безалаберного подхода одного из заказчиков к покупке билетов. Ну, чтож, ладно. Надеюсь, что игроки не совсем плевались от мероприятия, с учетом всех ограничений.
Кстати в компетенции учатсвовал один из авторов UFO-CTF. Он выйграл первый этап и зарешал около 5 заданий из 15.
У моих студентов возникает иногда вопрос: Как мне подключиться по ssh к виртуалке? я ввожу правильный root пароль, но войти не удается.
Да, все так и есть. Дело в том, что в соврменных дистрибутивах логин от рута по паролю запрещен - сделано это в рамках безопасности. Так что же делать?
Вариантов решения несколько:
1) логиниться под непривилигированным пользователем. им-то можно. а после логина - повышать привилегии с помощью sudo.
2) залить в /root/.ssh/authorized_keys публичный ключ и логиниться под рутом без пароля
3) исправить конфиг /etc/ssh/sshd_config и в директиву
Однако, порой проблема бывает не только в пароле. В качестве бонуса - пара способов как диагностировать ssh:
1) посмотрите /var/log/auth.log -в нем пишется информация об состоянии авторизации пользвателя -успешно или неуспешно и почему.
2) запустите ssh в foreground - остановите демон ssh и запустите его вручную по команде из systemd unit, но без ключа -D
3) добавьте ключи verbose на серверной и клиентской стороне.
ну, все это описано с учетом того что вы не трогали pam, у вас точно работает и слушает ssh на верном порту, никакие iptables не блочат соединение, tcpdump ловит пакеты, а mtu пролезает в канал. да-да тут еще много всякой херни =))
Да, все так и есть. Дело в том, что в соврменных дистрибутивах логин от рута по паролю запрещен - сделано это в рамках безопасности. Так что же делать?
Вариантов решения несколько:
1) логиниться под непривилигированным пользователем. им-то можно. а после логина - повышать привилегии с помощью sudo.
2) залить в /root/.ssh/authorized_keys публичный ключ и логиниться под рутом без пароля
3) исправить конфиг /etc/ssh/sshd_config и в директиву
PermitRootLogin записать значение yes. Перезапустить демон ssh: systemctl restart ssh и логиниться под рутом с паролем.Однако, порой проблема бывает не только в пароле. В качестве бонуса - пара способов как диагностировать ssh:
1) посмотрите /var/log/auth.log -в нем пишется информация об состоянии авторизации пользвателя -успешно или неуспешно и почему.
2) запустите ssh в foreground - остановите демон ssh и запустите его вручную по команде из systemd unit, но без ключа -D
3) добавьте ключи verbose на серверной и клиентской стороне.
ну, все это описано с учетом того что вы не трогали pam, у вас точно работает и слушает ssh на верном порту, никакие iptables не блочат соединение, tcpdump ловит пакеты, а mtu пролезает в канал. да-да тут еще много всякой херни =))
2017 December 19
я вот тут такой подумал, у любителей терминала guake, если у вас кнопка print screen находится рядом с F12, то в Pictures можно столько всего интересного найти...
#мысли
#мысли
МАСКИ И ПОДСЕТИ
Опыт сегодняшнего дня еще раз подтвердил, что необходимо рассказывать о базовых вещах простым языком. Но даже в этом случае нет гарантии, что в голове у студента информация останется. В этом посте я попробую доступно рассказать про маски и подсети (а вторая картинка вам в помощь).
На заре развития IP сетей масок не было, существовала только классовая адресация. В те далекие времена, первые 4 бита рассказывали о размере подсети, деля все возможное пространство на 5 классов. Гибкости в таком подходе нет, а адреса расходуются очень быстро. Вот и придумали инженеры-сетевики второй параметр - маску, чем сильно усложнили жизнь моим студентам.
Маска - это последовательность из 32 бит, в начале которой идут 1, а в конце 0. Основное ее назначение отделять изменяемую часть IP адреса от неизменяемой. Поскольку маска запрещает изменять часть IP адреса, она ограничивает допустимый набор значений для него. Такое ограничение принято называть сетью или подсетью.
Изменения в правой части формирую диапазон возможных IP адресов. Последний и первый адреса из диапазона служебные, остальные может использовать инженер. Первый адрес принято называть "Адресом подсети" и записывать его в документации вместе с маской для задания диапазона. Последний адрес называют "Широковещательным" (Broadcast) и используют для доставки информации всем узлам сети.
Записывать маску в полном виде долго, и тогда ленивые инженеры придумали краткий вид записи. В кратком виде необходимо записать только количество единиц в левой части маски, отсекая такую информацию косой чертой.
Дальше переходим к практике, ну а если вопросы, то вам сюда - https://habrahabr.ru/post/129664/ (очень подробное объяснение).
#mokando #mokando_life
Опыт сегодняшнего дня еще раз подтвердил, что необходимо рассказывать о базовых вещах простым языком. Но даже в этом случае нет гарантии, что в голове у студента информация останется. В этом посте я попробую доступно рассказать про маски и подсети (а вторая картинка вам в помощь).
На заре развития IP сетей масок не было, существовала только классовая адресация. В те далекие времена, первые 4 бита рассказывали о размере подсети, деля все возможное пространство на 5 классов. Гибкости в таком подходе нет, а адреса расходуются очень быстро. Вот и придумали инженеры-сетевики второй параметр - маску, чем сильно усложнили жизнь моим студентам.
Маска - это последовательность из 32 бит, в начале которой идут 1, а в конце 0. Основное ее назначение отделять изменяемую часть IP адреса от неизменяемой. Поскольку маска запрещает изменять часть IP адреса, она ограничивает допустимый набор значений для него. Такое ограничение принято называть сетью или подсетью.
Изменения в правой части формирую диапазон возможных IP адресов. Последний и первый адреса из диапазона служебные, остальные может использовать инженер. Первый адрес принято называть "Адресом подсети" и записывать его в документации вместе с маской для задания диапазона. Последний адрес называют "Широковещательным" (Broadcast) и используют для доставки информации всем узлам сети.
Записывать маску в полном виде долго, и тогда ленивые инженеры придумали краткий вид записи. В кратком виде необходимо записать только количество единиц в левой части маски, отсекая такую информацию косой чертой.
Дальше переходим к практике, ну а если вопросы, то вам сюда - https://habrahabr.ru/post/129664/ (очень подробное объяснение).
#mokando #mokando_life
