Как заблокировать ip диапазон посредством iptables?

#debian #iptables

Я хотел бы заблокировать исходящий трафик на все ip-адреса, начинающиеся на 115. 

Нужно заблокировать все ip вида:

115.*.*.*


Debian 6.0

Как это можно сделать?
    

Ответы

Ответ 1

Заблокировать и сохранить:

sudo  iptables  -A OUTPUT  -d 115.0.0.0/8  -j DROP
sudo  iptables-save > /etc/iptables/rules.v4


Потом восстановить из сохраненного, если понадобится:

sudo  iptables-restore < /etc/iptables/rules.v4


Для Debian начиная с 6.0 есть утилита автозагрузки сохраненных правил "iptables-persistent".
Её достаточно установить:

sudo  apt-get install iptables-persistent


Warning Играя с iptables вы легко можете потерять доступ к серверу. Даже когда, казалось
бы, «что может пойти не так?!» – ошибки совершаются. Наступал на эти грабли n раз.
Поэтому не рвите SSH сеанс с сервером, пока не убедитесь, что всё ещё можете до него
достучаться хотя бы по SSH в новом параллельном сеансе.

Как обмануть сканер портов?

#linux #iptables

Возможно ли сканерам портов вернуть будто порт закрыт, но на самом деле он открыт??
    

Ответы

Ответ 1

Вынесено из комментария



Один из вариантов скрытия портов от утилит сканирования и несанкционированных подключений
- механизм port knocking.
Суть его в том, что изначально порт защищаемого сервиса закрыт файрволом, демон port
knocking'a ожидает получения пакетов на определенные порты в заданной последовательности,
после чего открывает порт сервиса для доступа извне.

Мануалы по настройке:


https://wiki.archlinux.org/index.php/Port_knocking
http://ashep.org/2010/zashhita-sistemy-pri-pomoshhi-port-knocking/


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

Основные неудобства в использовании:


Требуется клиент для предварительной отправки последовательности пакетов перед подключением.
Нет прямой поддержки в ядре Linux (хотя есть варианты решения целиком на iptables).
Демон port knocking'a - это точка отказа, проблемы функционирования демона приведут
к проблемам с доступом к защищаемым сервисам.
Рекомендуется периодически менять последовательность "стуков".


Ответ 2

Такое возможно. Nmap, например, использует различные техники сканирования (через
zombie, xtree), кроме того сами сервисы могут отличаться поведением или ждать специальных
пакетов, поэтому nmap может допускать false-positive ошибки. Много зависит от глубины
анализа nmap. См. также статью

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

iptables https перенаправление на nodejs (правило)

#linux #nodejs #iptables #маршрутизация

Здравствуйте! подскажите как указать правило для iptables перенаправлять все https
запросы на nodejs?

для http сделано так

iptables

sudo iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:3000


nodejs

app.route('/*').get(function(req, res) {
  logreq(req);
  //res.send("");
});

function logreq(req){

  var method  = req.method
    , len = 10 - +method.length
    , met = new Array(len).join(" ");

  console.log("\n \033[32m ",me+met,"\033[42m\033[0m",
              "\033[33m hostname: \033[42m\033[0m",req.headers.host,
              "\033[32m Pathname: \033[42m\033[0m",req.url)
};

var server = app.listen(3000, '127.0.0.1', function(){

});

    

Ответы

Ответ 1

Проблема в том, что nodejs будет слушать порт не по ssl, а подключение будет подразумевать
использование ssl-шифрования. И браузер будет выдавать ошибку ssl, поскольку будет
ждать ssl-handshake, но его не получит. Е

Если вам необходимо слушать именно https, то ознакомьтесь с примером в документации:
https://nodejs.org/api/https.html

Входящие соединения для приложения

#iptables

Имеется сервер на Ubuntu Linux. На сервере крутится демон с именем, например, daemon_bin.
Демон слушает сетевой порт, но этот порт в общем случае неизвестен. Можно считать,
что прослушиваемый порт открывается по запросу и имеет случайный номер.

Можно ли добавить в iptables правило, которое будет пропускать входящие соединения
только в том случае, когда они адресованы этому демону?

P.S. Предложения дать демону определённый диапазон портов и разрешить входящие для
этого диапазона не предлагать. Отключение файрвола также не вариант.
    

Ответы

Ответ 1

Если я понял, то доступа к сорцам скрипта нет. Поэтому, нужно действовать в обход.
 Для начала берем ltrace (или, возможно, strace) и запускаем приложение под ним. Если
только там ничего не перестарались, то приложение будет дергать библиотечнык функции
для открытия/закрытия сокетов. Убеждаемся, что вызовы проходят. Например, для бинда
порта ожидается увидеть где то такое

bind(3, 0x7ffd828bc018, 16, 8080)  = 0


теперь нужно будет найти "парные вызовы". Скорее всего это будет listen/close или
bind/close.

Следующий этап - код. Берем любой пример, который показывает, как перехватывать вызовы
к сокетам, я нашел здесь и оставляем только нужные нам вызовы. В "открывающей функции"
можно подсмотреть номер порта и дескриптор сокета (это первое число). Сохраняем эту
пару где нибудь себе (в хеш, в файл, в базу) и вызываем iptables, что бы он открыл
нужный порт. В закрывающей функции по дескриптору находим порт и закрываем правило
в iptables.
В результате будет одна so'шка, которая будет подгружаться через LD_PRELOAD.

Проброс реального ip-адреса в виртуальную машину за nat

#linux #iptables

Есть вэб-сервер на виртуальной машине.

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

Мой iptables:

iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o vmbr0 -j SNAT --to-source 'x.x.x.x
iptables -t nat -A POSTROUTING -o vmbr1 -j SNAT --to-source 192.168.0.1

iptables -t nat -I PREROUTING -p udp -m udp --dport 60000:61000 -j DNAT --to 192.168.0.200:60000-61000

iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 18180 -j DNAT --to
192.168.0.200:22
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 17172 -j DNAT --to
192.168.0.102:22
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 17171 -j DNAT --to
192.168.0.101:22
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 3000 -j DNAT --to
192.168.0.101:3000
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 443 -j DNAT --to
192.168.0.200:443
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 80 -j DNAT --to
192.168.0.1:80

iptables -A PREROUTING -t nat -i vmbr0 -p tcp -s y.y.y.y -d 'x.x.x.x --dport 8080
-j DNAT --to 192.168.0.102:80
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -s y.y.y.y -d 'x.x.x.x --dport 8081
-j DNAT --to 192.168.0.102:8081

iptables -A INPUT -p TCP --dport 80 -j ACCEPT
iptables -A OUTPUT -p TCP --dport 80 -j ACCEPT
iptables -A INPUT -p TCP --dport 443 -j ACCEPT
iptables -A OUTPUT -p TCP --dport 443 -j ACCEPT

iptables -A INPUT -s y.y.y.y -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#iptables -I INPUT 1 -p udp --dport 60000:61000 -j ACCEPT
#iptables -A INPUT -p icmp --icmp-type echo-request -j REJECT --reject-with icmp-host-prohibited
iptables -P INPUT DROP

    

Ответы

Ответ 1

как я понял, подразумевается трафик, приходящий на интерфейс vmbr0 на адрес x.x.x.x.


вот эти правила надо «привести к общему знаменателю»:

iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 443 -j DNAT --to
192.168.0.200:443
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 80 -j DNAT --to
192.168.0.1:80


если целевая виртуальная машина имеет ip-адрес 192.168.0.200, то и во втором правиле
должен фигурировать этот ip-адрес.
а это правило надо убрать:

iptables -t nat -A POSTROUTING -o vmbr1 -j SNAT --to-source 192.168.0.1

на целевой виртуальной машине шлюзом по умолчанию должен быть назначен ip-адрес,
который присвоен сетевому интерфейсу (на машине, правила netfilter-а которой приведены
в вопросе), «смотрящему» в локальную сеть. насколько я понял — 192.168.0.1.

Раздать интернет

#linux #iptables #lan #route #модемы

Почему

$ ping ya.ru
ping: unknown host ya.ru

Комп1 (принимающий инет)

$ ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr b8:03:05:c9:3e:c5  
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::ba03:5ff:fec9:3ec5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33086 errors:0 dropped:0 overruns:0 frame:0
          TX packets:62823 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2797459 (2.7 MB)  TX bytes:90723494 (90.7 MB)

и так делал


$ ip route
default via 192.168.0.2 dev wlan0  scope link  metric 100 
192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.2  metric 9

и так делал

$ ip route
default via 192.168.0.1 dev wlan0  scope link  metric 100 
192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.2  metric 9

$ sudo iptables-save
:пусто



$ nslookup ya.ru
;; connection timed out; no servers could be reached

$ ping 8.8.8.8
connect: Network is unreachable



Комп2 (раздающий 3g)

$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr b8:88:e3:67:d4:45  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:5976 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5976 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:547759 (547.7 KB)  TX bytes:547759 (547.7 KB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:10.225.20.196  P-t-P:10.64.64.64  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:14699 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13627 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:11287729 (11.2 MB)  TX bytes:2950024 (2.9 MB)

wlan0     Link encap:Ethernet  HWaddr 50:b7:c3:2a:68:31  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::52b7:c3ff:fe2a:6831/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1000 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1021 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:148348 (148.3 KB)  TX bytes:108966 (108.9 KB)

wwan0     Link encap:Ethernet  HWaddr 58:2c:80:13:92:63  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


$ ip route
default via 10.64.64.64 dev ppp0  metric 100 
10.64.64.64 dev ppp0  proto kernel  scope link  src 10.225.20.196 
192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.1  metric 9 

net.ipv4.ip_forward = 1

Даже после команды :

$ sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 10.0.0.0/24 -o ppp0 -j
MASQUERADE 

в iptables пусто

$ sudo iptables -L -v -n --line
Chain INPUT (policy ACCEPT 11498 packets, 8572K bytes)
num   pkts bytes target     prot opt in     out     source               destination
        

Chain FORWARD (policy ACCEPT 2 packets, 112 bytes)
num   pkts bytes target     prot opt in     out     source               destination
        

Chain OUTPUT (policy ACCEPT 11183 packets, 2394K bytes)
num   pkts bytes target     prot opt in     out     source               destination     

$ sudo iptables-save
# Generated by iptables-save v1.4.21 on Fri Aug 12 21:04:53 2016
*nat
:PREROUTING ACCEPT [437:43281]
:INPUT ACCEPT [389:28232]
:OUTPUT ACCEPT [1207:218579]
:POSTROUTING ACCEPT [66:9831]
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT
# Completed on Fri Aug 12 21:04:53 2016
# Generated by iptables-save v1.4.21 on Fri Aug 12 21:04:53 2016
*filter
:INPUT ACCEPT [29340:31886316]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21601:3071749]
-A FORWARD -s 192.168.0.0/24 -i wlan0 -o ppp0 -j ACCEPT
-A FORWARD -d 192.168.0.0/24 -i ppp0 -o wlan0 -j ACCEPT
COMMIT
# Completed on Fri Aug 12 21:04:53 2016

$ nslookup ya.ru
Server:     127.0.1.1
Address:    127.0.1.1#53

Non-authoritative answer:
Name:   ya.ru
Address: 93.158.134.3
Name:   ya.ru
Address: 213.180.193.3
Name:   ya.ru
Address: 213.180.204.3

Сделал :


iptables -F 
iptables -X
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A FORWARD -i wlan0 -o ppp0 -s 192.168.0.0/24 -j ACCEPT
iptables -A FORWARD -i ppp0 -o wlan0 -d 192.168.0.0/24 -j ACCEPT


Получил

$ sudo iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 72 packets, 4357 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 65 packets, 3965 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 88 packets, 13008 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 5 packets, 890 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   90 12510 MASQUERADE  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0

Но маскарад так и не работает.



В итоге на комп2 есть инет и пингуется комп1. А на комп1 нет инета,хотя и пингуется
комп2. Почему нет интернета ?(
    

Ответы

Ответ 1

так как в вопросе не упомянут файл /etc/resolv.conf, скорее всего, в нём и дело.

в этом файле сохраняется информация, необходимая системе для преобразования доменных
имён в ip-адреса (и обратно).

как минимум в нём должна присутствовать строка вида:

nameserver ip-адрес


где ip-адрес — это адрес dns-сервера (сервера имён), который, собственно, и выполнит
(при обращении к нему со стороны вашей системы) упомянутое выше преобразование (например,
ya.ru → 93.158.134.3).

чем «ближе» находится сервер имён, тем быстрее будет получен от него ответ. вы можете
взять адрес из аналогичного файла со второго компьютера. или воспользоваться каким-нибудь
публичным:


8.8.8.8, 8.8.4.4 (поддерживаются компанией google)
77.88.8.8, 77.88.8.1 (поддерживаются компанией yandex)


Ответ 2

На обоих компах прописал в файл /etc/resolv.conf

nameserver 8.8.8.8

Спасибо @alexander-barakin

Сделал на компе2(с 3g инетом):


iptables -F
iptables -X
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A FORWARD -i wlan0 -o ppp0 -s 192.168.0.0/24 -j ACCEPT
iptables -A FORWARD -i ppp0 -o wlan0 -d 192.168.0.0/24 -j ACCEPT


Спасибо @nobody

И заработало. Всем спасибо!)

Белый список для 80 порта

#linux #ubuntu #nginx #iptables

Как можно сделать белый список для n (около 300 и в планах вырастит до 700) числа
ip адресов к 80 порту? 

Информация о сервере:
Ubuntu v16.04.1 (Linux v4.4.0-31) и Nginx v1.11.3 
    

Ответы

Ответ 1

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

location / { 
  allow 100.23.45.14;  ## IP которому нужно разрешить доступ
  allow 100.23.45.15;  ## IP которому нужно разрешить доступ
  deny all;
}


Если хотите сделать это через Iptables, то вам требуется прописать следующие строки:

iptables -I INPUT -s  -p tcp --dport 80  -i eth0 -j ACCEPT
iptables -A INPUT -j DROP -p tcp -i eth0 --dport 80


Первую строку нужно повторять столько раз, сколько нужно добавить IP в список разрешенных. 

Рассмотрим параметры iptables:


I: Вставка правила в начало
A: Вставить правило в конец
s: IP-адрес источника
j: Выполнить действие, если пакету соответствует текущее правило (ACCEPT принять
пакет, DROP блокирование пакета)
p: Протокол
dport: Порт, через который ожидается пакет
i: Интерфейс


Ответ 2

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

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

location / {
    include whitelist.txt;
}


Файл whitelist.txt:

  allow 100.23.45.14;
  allow 100.23.45.15;
  deny all;


Во-вторых, проскальзывало в комментариях про большое количество хостов: не забывайте,
что nginx (в отличие от apache, который до сих пор не умеет, позор!) понимает подсети:

# Rostelecom provider, Belgorod
allow 213.24.126.0/24;

deny all;


Ответ 3

Для белого списка использовал ipset + iptables

Создаем 2 новые списков:

ipset -N whitelist iphash # Для адресов 
ipset -N whitelist_net nethash  # Для сетей


Добавить новые адреса в whitelist:

ipset -A whitelist 100.23.45.14
ipset -A whitelist_net 100.23.45.0/24


Создается правило для использования списков:

iptables -A INPUT -m set --match-set whitelist src -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m set --match-set whitelist_net src -p tcp --dport 80 -j ACCEPT


и закрываем 80:

iptables -A INPUT -j DROP -p tcp --dport 80




Дополнительная информация:

https://habrahabr.ru/post/108691/

Как реализовать схему nginx-nginx ssl?

На фронтенде nginx, на бакэнде nginx с сертификатами.
Как мне пробросить запросы на бакэнд? или надо пробросить сертификаты на фронтенд?
Сейчас напрямую форвардятся все запросы к 443 на бакэнд через iptables, но реальный ip адрес не передается, а надо.
Через iptables этого не сделать, надо как-то через nginx.

Ответ

Через iptables этого не сделать (ссылка)
по ссылке описана несколько иная сетевая схема: два сервера, подключенные к интернету независимо друг от друга.
в вашем же случае (когда у второй машины шлюзом по умолчанию указана первая) это вполне реализуемо: Проброс реального ip-адреса в виртуальную машину за nat но более гибким решением, по-моему, будет обработка ssl на первой из машин («шлюзе»). тогда из поступающих https-запросов можно будет узнать целевое доменное имя и проксировать уже http- (не https-) пакеты на нужные http-серверы внутри вашей сети. а на этих серверах уже можно принимать и обрабатывать http- (не https-) трафик.
для того же, чтобы дать понять этим серверам, что https таки используется, можно устанавливать де-факто стандартный заголовок x-forwarder-proto, и эти серверы затем смогут сообщить сайтам об этом факте (например, некоторые cms имеют привычку делать редирект на https, если «обнаруживают», что используется http, например, для авторизации пользователей).
как этот заголовок обработать в apache, написано, например, здесь
ServerName ... ... SetEnvIf X-Forwarded-Proto https HTTPS=on ...
как этот заголовок обработать в nginx, написано, например, здесь
server { ... set_scheme_from ip-адрес-шлюза; real_scheme_header X-Forwarded-Proto; ... }

Маршрут в сеть за wireguard

Есть vpn на wireguard (далее сервер). Вот конфиг сервера: wg0.conf
[Interface] Address = 172.20.100.1/24 ListenPort = 9002 PrivateKey = uio77898hFT89UY= SaveConfig = false
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -s 172.20.100.0/24 -o ens18 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -s 172.20.100.0/24 -o ens18 -j MASQUERADE
[Peer]
PublicKey = 4m7879878798098098 AllowedIPs = 172.20.100.50/32,172.16.100.0/24
Есть машинка со следующим конфигом подключенная к wireguard (далее клиент).
[Interface] Address = 172.20.100.50/32 PrivateKey = CC/Ti8RUTv8gCTrwixgCsRW9QK/A89Hb6cY0D6Xy3nI= DNS = 208.67.222.222 208.67.220.220 PostUp = iptables -A FORWARD -i %i -j ACCEPT;iptables -t nat -A POSTROUTING -s 172.16.100.0/24 -o enp0s5 -j MASQUERADE
PostDown = iptables -A FORWARD -i %i -j ACCEPT;iptables -t nat -D POSTROUTING -s 172.16.100.0/24 -o enp0s5 -j MASQUERADE
[Peer]
AllowedIPs = 172.20.100.0/24
PublicKey = B24s34juy0HNp6jvztoLmoTudpmKhLag7Qh+f64EUUA=
Endpoint = wireguard-ip:9002
PersistentKeepalive = 25
Нужно все машины подключенные к wiregard пустить в сеть 172.16.100.0/24 которая находится за клиентом.
С такой конфигурацией я захожу на клиента по его локальному адресу без проблем. А на другие адреса его локалки не получатся. ipv4.forward везде 1

Ответ

PostUp = iptables -A FORWARD -i %i -j ACCEPT;iptables -t nat -A POSTROUTING -s 172.!!!>>>20<<PostDown = iptables -A FORWARD -i %i -j ACCEPT;iptables -t nat -D POSTROUTING -s 172.!!!>>>20<<В клиентском конфиге ошибка в адресе сети. 20 должно быть вместо 16-ти все работает.

Как понять, почему не отвечают сервисы/почему сервер не доступен?

Периодически без всяких причин может заглючить сервер. Два типа глюков:
1) Машина в принципе перестаёт отвечать. Запросы не идут к ней. По ssh не зайти.
2) На машину зайти можно зайти, но она тупит. К примеру, сервисы вроде запущены, но работать с ними не получаются. Тот же redis или consul. В процессах висят, но при попытке выполнить любой cli запрос, он тупо виснет. Даже операция find подвисает. nginx проксирует некоторые запросы к nodejs сервисам. Они тоже отваливаются по таймауту. Лимиты на серверах большие (ulimit, ограничение на сокеты и т.п.).
CPU не жрётся, на диске место есть, оперативки хватает. После ребута машины, логично, что всё ок.
Все виртуалки с Ubuntu 16.04.4 LTS
В какую сторону копать и что смотреть, если это снова случится?
Я не разбираюсь в iptables, но я сохранил список во время проблемы и после:
Когда присутствует проблема, то есть такие правила:
Chain RESET (0 references) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
Chain PROHIBIT (0 references) pkts bytes target prot opt in out source destination 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Они могут быть причиной? Если да, то как найти виновника? Единственное, что я нашёл в логах:
Jul 15 06:25:01 journey-test python3[1090]: 2018/07/15 06:25:01.935420 INFO Successfully added Azure fabric firewall rules Jul 15 06:25:01 journey-test python3[1090]: 2018/07/15 06:25:01.963119 INFO Firewall rules: Jul 15 06:25:01 journey-test python3[1090]: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) Jul 15 06:25:01 journey-test python3[1090]: pkts bytes target prot opt in out source destination Jul 15 06:25:01 journey-test python3[1090]: Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) Jul 15 06:25:01 journey-test python3[1090]: pkts bytes target prot opt in out source destination Jul 15 06:25:01 journey-test python3[1090]: Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) Jul 15 06:25:01 journey-test python3[1090]: pkts bytes target prot opt in out source destination Jul 15 06:25:01 journey-test python3[1090]: 0 0 ACCEPT tcp -- * * 0.0.0.0/0 168.63.129.16 owner UID match 0 Jul 15 06:25:01 journey-test python3[1090]: 0 0 ACCEPT tcp -- * * 0.0.0.0/0 168.63.129.16 ctstate INVALID,NEW
UPD: в /etc/waagent.conf нашёл OS.EnableFirewall=y. На старых виртуалках, где всё норм, такого правила нет. На всех новых виртуалках есть. Azure поменял дефолтное поведение своего агента. Сейчас он может менять правила фаервола. Не знаю, может ли это быть причиной.

Ответ

На серваках крутится Азуровский WALinuxAgent. Я заметил в логах, что он зачем-то лезет править фаервол. С каких-то пор они поменяли дефолтное поведение агента. Это я случайно заметил сравнив /etc/waagent.conf на старых машинах и на новых. Там теперь OS.EnableFirewall=y, он теперь может править фаервол. Я использую apf для настройки доступа. В какой-то момент у них возник конфликт. После установки в false этого флага OS.EnableFirewall=n проблема больше не повторяется.
Небольшое дополнение. Вероятно, при поднятии новой машины я забыл убрать basic настройки фаервола.

Как следствие, их агент, вероятно, переопределял мои настройки в apf и ломали доступ по ssh и т.п.

Как заблокировать ip диапазон посредством iptables?

Я хотел бы заблокировать исходящий трафик на все ip-адреса, начинающиеся на 115.
Нужно заблокировать все ip вида:
115.*.*.*
Debian 6.0
Как это можно сделать?

Ответ

Заблокировать и сохранить:
sudo iptables -A OUTPUT -d 115.0.0.0/8 -j DROP sudo iptables-save > /etc/iptables/rules.v4
Потом восстановить из сохраненного, если понадобится:
sudo iptables-restore < /etc/iptables/rules.v4
Для Debian начиная с 6.0 есть утилита автозагрузки сохраненных правил "iptables-persistent". Её достаточно установить:
sudo apt-get install iptables-persistent
Warning Играя с iptables вы легко можете потерять доступ к серверу. Даже когда, казалось бы, «что может пойти не так?!» – ошибки совершаются. Наступал на эти грабли n раз. Поэтому не рвите SSH сеанс с сервером, пока не убедитесь, что всё ещё можете до него достучаться хотя бы по SSH в новом параллельном сеансе.

Как обмануть сканер портов?

Возможно ли сканерам портов вернуть будто порт закрыт, но на самом деле он открыт??

Ответ

Вынесено из комментария

Один из вариантов скрытия портов от утилит сканирования и несанкционированных подключений - механизм port knocking. Суть его в том, что изначально порт защищаемого сервиса закрыт файрволом, демон port knocking'a ожидает получения пакетов на определенные порты в заданной последовательности, после чего открывает порт сервиса для доступа извне.
Мануалы по настройке:
https://wiki.archlinux.org/index.php/Port_knocking http://ashep.org/2010/zashhita-sistemy-pri-pomoshhi-port-knocking/
Преимущества/недостатки port knocking - вопрос обсуждаемый, но в любом случае, этот механизм нужно рассматривать как часть системы безопасности, а не ее единственный элемент.
Основные неудобства в использовании:
Требуется клиент для предварительной отправки последовательности пакетов перед подключением. Нет прямой поддержки в ядре Linux (хотя есть варианты решения целиком на iptables). Демон port knocking'a - это точка отказа, проблемы функционирования демона приведут к проблемам с доступом к защищаемым сервисам. Рекомендуется периодически менять последовательность "стуков".

iptables https перенаправление на nodejs (правило)

Здравствуйте! подскажите как указать правило для iptables перенаправлять все https запросы на nodejs?
для http сделано так
iptables
sudo iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:3000
nodejs
app.route('/*').get(function(req, res) { logreq(req); //res.send(""); });
function logreq(req){
var method = req.method , len = 10 - +method.length , met = new Array(len).join(" ");
console.log("
\033[32m ",me+met,"\033[42m\033[0m", "\033[33m hostname: \033[42m\033[0m",req.headers.host, "\033[32m Pathname: \033[42m\033[0m",req.url) };
var server = app.listen(3000, '127.0.0.1', function(){
});

Ответ

Проблема в том, что nodejs будет слушать порт не по ssl, а подключение будет подразумевать использование ssl-шифрования. И браузер будет выдавать ошибку ssl, поскольку будет ждать ssl-handshake, но его не получит. Е
Если вам необходимо слушать именно https, то ознакомьтесь с примером в документации: https://nodejs.org/api/https.html

Проброс реального ip-адреса в виртуальную машину за nat

Есть вэб-сервер на виртуальной машине.
Нужно сделать так, чтобы весь трафик по 80 и 443 портам заворачивался на эту виртуальную машину без подмены ip-адреса клиента.
Мой iptables:
iptables -F iptables -t nat -F iptables -t mangle -F iptables -X
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o vmbr0 -j SNAT --to-source 'x.x.x.x iptables -t nat -A POSTROUTING -o vmbr1 -j SNAT --to-source 192.168.0.1
iptables -t nat -I PREROUTING -p udp -m udp --dport 60000:61000 -j DNAT --to 192.168.0.200:60000-61000
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 18180 -j DNAT --to 192.168.0.200:22 iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 17172 -j DNAT --to 192.168.0.102:22 iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 17171 -j DNAT --to 192.168.0.101:22 iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 3000 -j DNAT --to 192.168.0.101:3000 iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 443 -j DNAT --to 192.168.0.200:443 iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 80 -j DNAT --to 192.168.0.1:80
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -s y.y.y.y -d 'x.x.x.x --dport 8080 -j DNAT --to 192.168.0.102:80 iptables -A PREROUTING -t nat -i vmbr0 -p tcp -s y.y.y.y -d 'x.x.x.x --dport 8081 -j DNAT --to 192.168.0.102:8081
iptables -A INPUT -p TCP --dport 80 -j ACCEPT iptables -A OUTPUT -p TCP --dport 80 -j ACCEPT iptables -A INPUT -p TCP --dport 443 -j ACCEPT iptables -A OUTPUT -p TCP --dport 443 -j ACCEPT
iptables -A INPUT -s y.y.y.y -j ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT #iptables -I INPUT 1 -p udp --dport 60000:61000 -j ACCEPT #iptables -A INPUT -p icmp --icmp-type echo-request -j REJECT --reject-with icmp-host-prohibited iptables -P INPUT DROP

Ответ

как я понял, подразумевается трафик, приходящий на интерфейс vmbr0 на адрес x.x.x.x
вот эти правила надо «привести к общему знаменателю»:
iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 443 -j DNAT --to 192.168.0.200:443 iptables -A PREROUTING -t nat -i vmbr0 -p tcp -d 'x.x.x.x --dport 80 -j DNAT --to 192.168.0.1:80
если целевая виртуальная машина имеет ip-адрес 192.168.0.200, то и во втором правиле должен фигурировать этот ip-адрес. а это правило надо убрать:
iptables -t nat -A POSTROUTING -o vmbr1 -j SNAT --to-source 192.168.0.1 на целевой виртуальной машине шлюзом по умолчанию должен быть назначен ip-адрес, который присвоен сетевому интерфейсу (на машине, правила netfilter-а которой приведены в вопросе), «смотрящему» в локальную сеть. насколько я понял — 192.168.0.1

Раздать интернет

Почему
$ ping ya.ru ping: unknown host ya.ru
Комп1 (принимающий инет)
$ ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr b8:03:05:c9:3e:c5 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::ba03:5ff:fec9:3ec5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:33086 errors:0 dropped:0 overruns:0 frame:0 TX packets:62823 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2797459 (2.7 MB) TX bytes:90723494 (90.7 MB)
и так делал
$ ip route default via 192.168.0.2 dev wlan0 scope link metric 100 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.2 metric 9
и так делал
$ ip route default via 192.168.0.1 dev wlan0 scope link metric 100 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.2 metric 9
$ sudo iptables-save :пусто

$ nslookup ya.ru ;; connection timed out; no servers could be reached
$ ping 8.8.8.8 connect: Network is unreachable

Комп2 (раздающий 3g)
$ ifconfig -a eth0 Link encap:Ethernet HWaddr b8:88:e3:67:d4:45 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:5976 errors:0 dropped:0 overruns:0 frame:0 TX packets:5976 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:547759 (547.7 KB) TX bytes:547759 (547.7 KB)
ppp0 Link encap:Point-to-Point Protocol inet addr:10.225.20.196 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:14699 errors:0 dropped:0 overruns:0 frame:0 TX packets:13627 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:11287729 (11.2 MB) TX bytes:2950024 (2.9 MB)
wlan0 Link encap:Ethernet HWaddr 50:b7:c3:2a:68:31 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::52b7:c3ff:fe2a:6831/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1000 errors:0 dropped:0 overruns:0 frame:0 TX packets:1021 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:148348 (148.3 KB) TX bytes:108966 (108.9 KB)
wwan0 Link encap:Ethernet HWaddr 58:2c:80:13:92:63 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
$ ip route default via 10.64.64.64 dev ppp0 metric 100 10.64.64.64 dev ppp0 proto kernel scope link src 10.225.20.196 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.1 metric 9
net.ipv4.ip_forward = 1
Даже после команды :
$ sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 10.0.0.0/24 -o ppp0 -j MASQUERADE
в iptables пусто
$ sudo iptables -L -v -n --line Chain INPUT (policy ACCEPT 11498 packets, 8572K bytes) num pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 2 packets, 112 bytes) num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 11183 packets, 2394K bytes) num pkts bytes target prot opt in out source destination
$ sudo iptables-save # Generated by iptables-save v1.4.21 on Fri Aug 12 21:04:53 2016 *nat :PREROUTING ACCEPT [437:43281] :INPUT ACCEPT [389:28232] :OUTPUT ACCEPT [1207:218579] :POSTROUTING ACCEPT [66:9831] -A POSTROUTING -o ppp0 -j MASQUERADE COMMIT # Completed on Fri Aug 12 21:04:53 2016 # Generated by iptables-save v1.4.21 on Fri Aug 12 21:04:53 2016 *filter :INPUT ACCEPT [29340:31886316] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [21601:3071749] -A FORWARD -s 192.168.0.0/24 -i wlan0 -o ppp0 -j ACCEPT -A FORWARD -d 192.168.0.0/24 -i ppp0 -o wlan0 -j ACCEPT COMMIT # Completed on Fri Aug 12 21:04:53 2016
$ nslookup ya.ru Server: 127.0.1.1 Address: 127.0.1.1#53
Non-authoritative answer: Name: ya.ru Address: 93.158.134.3 Name: ya.ru Address: 213.180.193.3 Name: ya.ru Address: 213.180.204.3
Сделал :
iptables -F iptables -X iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE iptables -A FORWARD -i wlan0 -o ppp0 -s 192.168.0.0/24 -j ACCEPT iptables -A FORWARD -i ppp0 -o wlan0 -d 192.168.0.0/24 -j ACCEPT
Получил
$ sudo iptables -t nat -nvL Chain PREROUTING (policy ACCEPT 72 packets, 4357 bytes) pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 65 packets, 3965 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 88 packets, 13008 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 5 packets, 890 bytes) pkts bytes target prot opt in out source destination 90 12510 MASQUERADE all -- * ppp0 0.0.0.0/0 0.0.0.0/0
Но маскарад так и не работает.

В итоге на комп2 есть инет и пингуется комп1. А на комп1 нет инета,хотя и пингуется комп2. Почему нет интернета ?(

Ответ

На обоих компах прописал в файл /etc/resolv.conf
nameserver 8.8.8.8
Спасибо @alexander-barakin
Сделал на компе2(с 3g инетом):
iptables -F iptables -X iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE iptables -A FORWARD -i wlan0 -o ppp0 -s 192.168.0.0/24 -j ACCEPT iptables -A FORWARD -i ppp0 -o wlan0 -d 192.168.0.0/24 -j ACCEPT
Спасибо @nobody
И заработало. Всем спасибо!)

Белый список для 80 порта

Как можно сделать белый список для n (около 300 и в планах вырастит до 700) числа ip адресов к 80 порту?
Информация о сервере: Ubuntu v16.04.1 (Linux v4.4.0-31) и Nginx v1.11.3

Ответ

Для белого списка использовал ipset + iptables
Создаем 2 новые списков:
ipset -N whitelist iphash # Для адресов ipset -N whitelist_net nethash # Для сетей
Добавить новые адреса в whitelist:
ipset -A whitelist 100.23.45.14 ipset -A whitelist_net 100.23.45.0/24
Создается правило для использования списков:
iptables -A INPUT -m set --match-set whitelist src -p tcp --dport 80 -j ACCEPT iptables -A INPUT -m set --match-set whitelist_net src -p tcp --dport 80 -j ACCEPT
и закрываем 80:
iptables -A INPUT -j DROP -p tcp --dport 80

Дополнительная информация:
https://habrahabr.ru/post/108691/