LINUX.ORG.RU

Странный постучался мне в Firewall

 , , ,


1

1

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

Значит, моя сеть 10.0.0.0/8 позади обычного дешевого роутера, в составе сети сервер 10.0.0.3 и клиент 10.0.0.10. Установил на сервер Debian 8, совершенно нульсовый (там где выбирать компоненты все звёздочки убрал, решил добавить ручками по надобности), стал копаться с настройками iptables. Сам я по натуре абсолютный параноик и строки навроде iptables -P OUTPUT ACCEPT меня пугают, мягко говоря, до усрачки и я подобного никогда не писал (занимался да и поигрываю изредка низкоуровневым TCP/IP, серверы там всякие, не важно) и писать не собираюсь.

Начал обходить, ssh, samba, dns и ICMP по минимальному параноидальному сценарию с полноценной их работой заработали.

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

Провозившись несколько часов с настройкой логгинга, я понимаю в чём дело и решаю прописать «в жёсткую» в настройки iptables адреса серверов обновлений, а для того, чтобы это сделать, настраиваю логгинг «с наружи» и «изнутри» всех DROPped пакетов.

Чёрт побери, вот тут-то сердечко моё больное и ёкает. Помимо понятных серверов, заканчивающихся на debian.org, выискивается неискуемый nslookupом сервер вот такой:

Jun 4 13:29:49 creep kernel: [ 279.940080] IT-IN-Dropped: IN=eth0 OUT= MAC=00:1d:92:69:e2:b2:c8:be:19:b3:43:da:08:00 SRC=218.77.79.43 DST=10.0.0.3 LEN=44 TOS=0x08 PREC=0x60 TTL=237 ID=54321 PROTO=TCP SPT=52143 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0

Делаю whois, раз nslookup не знает, а там - здрасти, сами смотрите: https://www.nic.ru/whois/?query=218.77.79.43 . Я обновлять хочу русифицированную американскую систему с американского зеркала, а там мне «Ni xao» говорят из Хунань Телекома какого-то -.-

Узбагойте меня кто-нибудь, пожалуйста. Разве это нормально?

2) убедись, что правильно понял концепцию зеркал обновления

1) обновляйся по http(s), а не по ftp

0) не страдай фигнёй

dhameoelin ★★★★★ ()
Ответ на: комментарий от dhameoelin

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

nimzovich ()
Ответ на: комментарий от nimzovich

Фигня - то, что, не разобравшись в вопросе, поднял панику.

dhameoelin ★★★★★ ()
Ответ на: комментарий от dhameoelin

Ясно. Ну - «поднять панику» - это значит заставить кого-то ещё паниковать, тут не тот случай. Спасибо, я разобрался. Зеркала обновлений debian.org предоставляют списки пакетов обновлений где какие находятся, а не содержат собственно пакеты. Обновление какого-то пакета постучалось ко мне через закрытый firewall и напугало меня, теперь стало понятно.

Благодарю, что пояснили, последую вашим советам :)

nimzovich ()
Ответ на: комментарий от nimzovich

Нет, не разобрался, видимо. Буду разбираться, пока не посинею, потому как в этом деле таки требуется разобраться :(

nimzovich ()
Ответ на: комментарий от nimzovich

Разобраться сложно, короче. Не понимаю, с чего бы что-то должно было бы мне с Китая качаться, копаюсь полтора часа, ни одного намёка на подобное :( Кто-нибудь ткнёт носом в почитать по теме что-то? А именно - в то, что я ещё не знаю о зеркалах обновлений. Антивирусное зеркало обновлений и WSUS не в счёт, так как Linux обновляется как-то по-другому, видимо. Не просто так берёт с указанных зеркал пакеты и не просто сравнивает версии и не просто ставит, как делают все остальные.

nimzovich ()
Ответ на: комментарий от nimzovich

Зачем ты отвечаешь сам себе?

По поводу Китая - может, просто IP хоста с американским зеркалом принадлежит китайскому диапазону. Мало ли, может, он co-location использует...

dhameoelin ★★★★★ ()
Ответ на: комментарий от nimzovich

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

Ещё это может быть веб-спайдером, но это маловероятно.

с Китая качаться

А с чего ты взял что «качаться»? Посмотри тогда уж весь лог по этому айпи. Трафик вообще снимать удобнее через tcpdump/wireshark, а не париться с логгированием в iptables.

IT-IN-Dropped .. DPT=80 .. SYN

Пришёл новый пакет на 80 порт, netfilter (iptables) его зарубил и видимо трафика больше не было или же были повторные (тщетные) попытки.
Если у тебя на 80 порту ничего не висит и в iptables не было бы правил, то удалённый хост бы получил icmp сообщение о том что порт закрыт и соединение бы было прервано.
Если у тебя там веб-сервер, то ботнет (если это он) начал бы шарить всякие распространённые URLы и пробовал бы воспользоваться уязвимостями в разных сайтовых движках.

Nao ★★★★★ ()
Ответ на: комментарий от Nao

Зачем ты отвечаешь сам себе?

Потому что разговариваю сам с собой, и именно вам после «не страдай фигнёй» уже и боюсь отвечать :)

А с чего ты взял что «качаться»? Посмотри тогда уж весь лог по этому айпи. Трафик вообще снимать удобнее через tcpdump/wireshark, а не париться с логгированием в iptables.

Точно, ведь это может быть просто совпедением. Это возникло точно в тот момент, когда я делал apt-get update и проверял, откуда что идёт по iptables, это меня и заставило сделать такое заключение. В пользу этого говорит и то, что с того адреса больше не было никаких других обращений при нескольких десятках последующих повторов команды. Вот теперь, в принципе, всё стало на свои места в голове по этому поводу, а то уж не знал, о чём думать :)

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

По терминологии - вы упомянули уязвимость в «сайтовых движках» - я правильно понял, что злоумышленники направляют большую долю усилий на поиски уязвимостей именно в движках навроде wordpress или jumla (если я правильно помню, что они именно так называются), а не в http-серверах навроде apache и nginx? То есть в принципе безопаснее создавать простой сайт ручками с помощью HTML и скриптового языка программирования, а не использовать какие-либо распространённые фреймворки?

nimzovich ()
Ответ на: комментарий от nimzovich

По терминологии - вы упомянули уязвимость в «сайтовых движках» - я правильно понял, что злоумышленники направляют большую долю усилий на поиски уязвимостей именно в движках навроде wordpress или jumla (если я правильно помню, что они именно так называются), а не в http-серверах навроде apache и nginx?

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

То есть в принципе безопаснее создавать простой сайт ручками с помощью HTML и скриптового языка программирования, а не использовать какие-либо распространённые фреймворки?

Security by obscurity.
В общем да, т.к. автоматические сканеры, которые ищут известные ошибки в известных движках не смогут пробиться.
Но с другой стороны, если в разработке сайтов ты не спец, то легко допустить грубую ошибку. Эту ошибку могут найти сканеры «общего назначения».
Например они пробуют взломать сайт через формы или через GET параметры.
Ну и если за сайт возьмётся человек, то ошибку он найдёт, если она есть.

Nao ★★★★★ ()
Ответ на: комментарий от Nao

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

Ага. Через NAT. Не слишком ли сложный процесс для ботнета ? Кроме того, скажи, как можно через нат постучаться на 80 порт, если исходящие соединения, как правило, не открываются с портов менее 1024 ?

AS ★★★★★ ()

строки навроде iptables -P OUTPUT ACCEPT меня пугают, мягко говоря, до усрачки

А что в них такого ? Следи за запущенными сервисами. Если к тебе будут ломиться туда, где никого нет, зачем мешать ?

AS ★★★★★ ()
Ответ на: комментарий от AS

Не понял. Для кого NAT должен быть проблемой?
У ТС видимо 80-ый порт проброшен на сервер, раз пакет извне пришёл.
Для компа в составе ботнета не вижу проблемы со своим NAT-ом, т.к. исходящие соединения на 80-ый порт частенько разрешены.

как можно через нат постучаться на 80 порт, если исходящие соединения, как правило, не открываются с портов менее 1024 ?

У ТСа в логах написано SPT=52143, что явно больше 1024.
Или ты думаешь что локальный и удалённый порт должны быть одинаковыми?

Nao ★★★★★ ()
Ответ на: комментарий от AS

iptables -P OUTPUT ACCEPT
к тебе будут ломиться

Тебе не мешало бы подучить iptables прежде чем давать советы.

Nao ★★★★★ ()
Ответ на: комментарий от Nao

У ТСа в логах написано SPT=52143, что явно больше 1024.
Или ты думаешь что локальный и удалённый порт должны быть одинаковыми?

Перечитай ещё раз всё, и подумай, прежде, чем давать советы.

AS ★★★★★ ()
Ответ на: комментарий от Nao

Тебе не мешало бы подучить iptables прежде чем давать советы.

Подучить не мешает тебе. Но да, на OUTPUT я внимания не обратил.

AS ★★★★★ ()
Ответ на: комментарий от AS

Не пойму что тебе не понятно с ботнетом.

1) Вариант 1:
Заражённый компьютер в каком-нибудь офисе или домашний комп находятся за NAT-от от роутера. Фаерволлы не настроены.

Ботнет получает команду на скан диапазона IP-шников и например на поиск какой-нибудь уязвимости в сайтовых движках или просто на скан уязвимостей в сетевых сервисах.
Экземпляр ботнета на компе пользователя коннектится на порт 80 ТС-а, беспрепятственно проходит через свой NAT и через NAT ТС-а (т.к. у него проброшен 80-ый порт).
Далее ТС видит такое в логе:

T-IN-Dropped: IN=eth0 OUT= SRC=218.77.79.43 DST=10.0.0.3 PROTO=TCP SPT=52143 DPT=80 SYN

Потому что в iptables настроил DROP

2) Вариант 2: тоже самое, только инициатором соединения является код, внедрённый в сайтец написанный на каком-нибудь PHP.
Пользователь заходит на сайт и код выполняется.
Удалённый хост, в случае успешного заражения становится частью ботнета.
Такие я сам выковыривал из сайтов некоторых умельцев.

Nao ★★★★★ ()
Ответ на: комментарий от Nao

(т.к. у него проброшен 80-ый порт).

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

AS ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.