Инструменты, которые нам встречались.

telnet

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

Когда изобрели интернеты, то есть когда связаться через тцп ип стало удобней чем с помощью модема и компорта, задумались о перенесении всего этого в сеть. Основная потребность -- выполнять команды на удаленном компьютере. Первым был rsh. Он приводил к тому, что те команды, которые вы к нему складывали, он запускал на удаленной машине. Запуск посредством подключения по сети шелла на удаленной машине и передачу ввода-вывода с удаленной машины к вам. Атака Митника была осуществлена именно на рсх -- беспарольный, удаленный из пор рута.

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

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

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

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

По сравнению с рсх в протокол телнет ввели полезные для удаленной работы вещи как тип терминала. Это штука еще не окончательно канувшая в вечность, но сегодня достаточно экзотичная ситуация когда вы с этим сталкивались, но вте времена терминалы были экзотичными. Производители производили электронные печатные машинки и иногда изобретали совершенно удивительные вещи. Поэтому важно, чтобы когда вы подключаетесь удаленная машина знала тип вашего терминала. Даже клавиша перевода строки могла возвращать не тот символ, который у всех. Когда терминал подключен проводами, можно прописать в соотв строчке getty тип терминала на таком то компорте. А вот по телнету так сделать нельзя, поэтому происходил обмен информацией о некоторых переменных среды, например $TERM.

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

Нелишне сказать, что ни телнет, ни рсх не предполагали никакой защиты передаваемой информации, и пароль по телнет передавался открытым текстом. И, в силу архитектуры, телнет плохо подходил для защищенной передачи.

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

rsh

netcat

Половина ее функций состоит в том, чтобы подключиться тцпсоелинением к какому нибудь порту и все вваливать либо туда, либо оттуда. Можно сказать:

И начать туда вводить команды GET и так далее.

Большинство старых протоколов FTP, HTTP, SMTP -- текстовые, и ими можно пользовтаься так.

Это подключени к порту в качестве клиента.

netcat может цепляться и к сокетам, работать по UDP.

Просто так взять иначать писать в сокет с помощью перенаправления ввода-вывода нельзя, а вот с помощью нетката -- можно.

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

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

-i -- задержка между отправляемыми строками

-w -- отключаться, если заданное время нет активности

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

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

stunnel

Неткат с сслем и разными возможностями делать над этим сслем извращения -- тот сертификат показать, этот показать этот, повесить демона.

Что еще может понадобится? Утилита для добычи информации из интернета

wget

Инструмент универсального скачивания по разнообразным протоколам, прежде всего хттп и фтп.

curl

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

lftp

ftp на стероидах. Такой шелл. Есть работа с торрентами. Славен еще тем, что у него есть командочка pget -- параллельное скачивание.

tcpdump

Штука для дампа трафика, в особенности тцпшного. Главная проблема эффективного разбора сетевого трафика - какбы не начать разбирать весь трафик в вашей сети и не подаваиться этим, поэтому основная сложность работы -- указать фильтры, которые вас интересуют. Причем эзернет карточка скорее всего будет переведена в неразборчивый режим. А дальше на языке фильтров pcap надо указывать какой протокол вас интересует, какие отправитель и получатель, и тд.

Умеет превращать трафик, который подглядела в файл и прямо в этот файл записывать.

pcap пользуется и волшебная программа dsniff, которая вынимает логин и пароль из траффика, елси они вдруг там засветились.

Как правильно готовить виртуалбоксы, чтобы ими было удобно пользоваться

Образ можно просто проимпортировать.

Что на сайте не написано. Как работает сеть в виртуалбоксе.

Вот у вас есть виртуальная машина. Она совершенно виртуальная. У неё внутри виртуальный сетевой интерфейс.

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

Как можно еще? NAT. Чем метод NAT хорош -- вам вообще ничего не надо делать для настройки сети. Чем плох? Вы не сможете подсоединиться к этой машине, например, по ссх.

Как преодолеть? При настройке виртуальной машины есть проброс портов. Можно проборосить порт 2201 локалхоста на 22 порт виртуальной машины.

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

Сейчас в дз сеть устроена так -- в каждой машине по два интерфейса, один из которых нат, а другой внутренний. У сервера дефолт роут в интернет, а по второму интерфейсу он раздает дхцп клиенту. Клиент ходит дефолт роутом на сервер.

Шифрование, gpg, ssh

Разговор про гпг имеет достаточно косвенное отношние к сетям, но это довольно часто встречающийся механизм использования электронной подписи.

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

gpg -- gnu реализация pgp.

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

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

Надо понимать, что если есть эцп, то совершенно необязательно сообщение шифровать, это две разные задачи.

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

В случае эцп не так все страшно, елси речь идет о некритичных данных. Используете эцп для переписки. У вас большая группа абонентов, которые так делают. Почти наверняка случится так, что есть люди, в аутентичности ключей которых вы не убедились лично. Что делать?

  1. таки добиваться, чтобы люди фингерпринт продиктовали
  2. просить тех людей, относительно подписи которых вы уверены подписать этот ключ.

Поскольку речь идет не о сайтах, а о людях, ситуация намного менее печальна. После чего ключ и его подписи публикуются на специальных серверах. Уровень доверия 0 -- вы сами подписали. 1 -- подписал кто-то, кому подписали вы. И так далее.

ssh

10 минут. Почти соревнования моложых отцов по чтению сказок на ночь на скорость.

Как было сказано, телнетд не надо пользоваться вообще.

Пользоваться надо неткатом или ssh.

ссх -- защищенный терминальный сервис. Основная, но не единственная функция которого -- предоставить вам защищенный санс удаленной работы.

Логин пароль, получение шелла, работа, разлогинивание.

Как это устроено?

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

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

Следующий этап -- ключи пользователя. Запомнить 18 хороших паролей -- анриал. Поэтому можно сгенерировать себя ассиметричный ключ, собственный. азложить на машины открытую часть, и заставить у ссх демона спрашивать у ссх утилиты не логин и пароль, а ключ.

Ключ, правда, тоже надо защищать паролем. Хорошим. Но зато этот пароль один.

Предположим, вы все время так делаете. Скрипт написали, который вебсервера перезагружает. Каждый раз вводить хороший пароль утомительно. Появляется следующий персонаж -- агент. Это программа, которой вы скармливаете свой ключ. Она запущена только на вашей машине и держит у себя в памяти ключ. После этого любой подключение происходит без пароля, потому что ключ ссх рассказывает агент Агента можно пробрасывать дальше для последовательных соединений.

Проблема -- рут на удаленной машине может ходить вашими ключами.

Есть инструмент ask pass. Если он включен, то каждый акт авторизации и подключения будет выбрасывать оповещательое полотенце с информацией кто куда хочет подключаться и спрашивать "давать или не давать".

От рута на своей машине защититься гораздо сложнее, потому что он вам может перекомпилить ссх.

Еще один выход -- шифрование на отдельной железке.

Еще одна важная функция ссх -- при подключении между клиентом и сервером образуется защищенный тунель. Хотелось бы егокак-то еще утилизировать кроме того тчобы шелл гонять. Что приходит в голову? Запустить неткат с обоих сторон. Делать так не надо, потому что у ссх есть ключики -l и -r -- проброс оттуда сюда и отсюда туда соответственно.

Забанили у вас вконтактик -- а вы говорите -- пробросьте мне 80 на 443

Обратная ситуация -- зафаерволили вас. А вам хочется по ссх ходить. Пишите ssh -r порт на удаленной машине:порт srv

Не забыть сказать port gateway enable sshd.

LecturesCMC/LinuxNetwork2013/Conspects/10 (last edited 2013-12-30 21:28:26 by Allena)