настройка UFW

ufw enable сделал? Покажи ufw status.

К нему есть GUI. gufw, и аналог для KDE.

# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

To                         Action      From
--                         ------      ----
63221/tcp                  ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
22/tcp                     ALLOW IN    del
3306/tcp                   ALLOW IN    del

конечно сделал, факт в том, что правила вроде как работают, (пробовал в разных хостов, а вот с моего компа - не работает - пускает).

up. ufw находится на сервере в инете.

сервер без иксов

вот эта строчка что значит? New profiles: skip

Ok, подойдем с другой стороны.

Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
     344    23085 ufw-before-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     344    23085 ufw-before-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0
      75     3356 ufw-after-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0
      75     3356 ufw-after-logging-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0
      75     3356 ufw-reject-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0
      75     3356 ufw-track-input  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain ufw-before-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    265    19549 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

может быть я попадаю в RELATED? как это проверить?.

Хотя вряд ли, related - это же уже вторичное соединение, поверх существующего. Ребутал и сервер и ufw и свою машину - бестолку - пускает.

63221/tcp ALLOW IN Anywhere 80/tcp ALLOW IN Anywhere 22/tcp ALLOW IN del 3306/tcp ALLOW IN del

жесть какая-то

Итого:

сервер ufw - хост 1 мой компьютер - хост 2 правила доступа к 22, 3306 портам - хост 3 (del) внешний хост любой - хост 4

на хост 1: с хоста 2 - есть доступ на все порты, кроме 22, 3306 с хоста 3 - доступа нет, только для 63221, 80, 22, 3306 с хоста 4 - доступа нет, только для 63221, 80

че за муйня, мне кто-нибудь может сказать?

63221/tcp ALLOW IN Anywhere 
80/tcp ALLOW IN Anywhere 
22/tcp ALLOW IN del 
3306/tcp ALLOW IN del

жесть какая-то

Итого:

сервер ufw - хост 1 мой компьютер - хост 2 правила доступа к 22, 3306 портам - хост 3 (del) внешний хост любой - хост 4

на хост 1:

с хоста 2 - есть доступ на все порты, кроме 22, 3306

с хоста 3 - доступа нет, только для 63221, 80, 22, 3306

с хоста 4 - доступа нет, только для 63221, 80

че за муйня, мне кто-нибудь может сказать?

Дай 3 вывода:

Ufw status

Iptables -L

Iptables -t nat -L

https://gist.github.com/LennyLip/5d24a8f57867268b8ec5

8.8.8.8 - заменил свой ip (это хост 3 выше)

Окей

А теперь опиши, что именно тебе надо?

Только конкретно и по существу, постарайся сделать это внятно.

btw я вообще не увидел правил доступа для host2, на него должны распространяться те же правила, что и да host4.

На ssh правил я тоже не увидел, кстати.

при чем тут ssh (ну допусти 6521 это он, что это меняет)?

эти правила не берем 6521/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere тут все ок.

сервер с ufw - хост 1

мой компьютер - хост 2 (не 8.8.8.8)

с хоста 2 есть доступа на хост 1 на 25, 587, и остальные порты.? (это неправильно)

на эти порты 21/tcp 6521/tcp

доступа нет (которые прописаны для хоста 3 (8.8.8.8) ). (это правильно)

сделай nc -v -z host1 25

с host2

С host4 тоже все порты доступны? или такое только с host2?

d:\soft\nc>nc -v -z host1 25 host1 [185.*.*.*] 25 (smtp) open

host4 - пробовал с разных серверов (Россия и Германия), в том числе и с сайтов по тестированию портов - поведение ожидаемое - все закрыто, кроме открытых 80 и 6521.

host4

#nc -v -n -z host1ip 25
(UNKNOWN) [host1ip] 25 (smtp) : Connection timed out

Спецы по iptables, подскажите, вот это вообще нормально?

Chain INPUT (policy DROP)
target     prot opt source               destination         
ufw-before-input  all  --  anywhere             anywhere 

Chain ufw-before-input (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere                

В скобках стандартное действие прописано, а accept - для правила.

Кстати, в /etc/ufw/befor.rules есть что-то?

Ну если сложить это действия какой результат будет?

в before.rules ничего не правил:

я вообще ничего не правил, все по-умолчанию, только добавил правила в сам ufw.

# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-before-input
#   ufw-before-output
#   ufw-before-forward
#

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines


# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection
-A ufw-before-input -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m state --state RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m state --state INVALID -j ufw-logging-deny
-A ufw-before-input -m state --state INVALID -j DROP

# ok icmp codes
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local

# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

Никто их не складывает, если пакет не подошел ни под одно правило, то к нему применяется правило по умолчанию. В твоем случае это drop.

аа, блин, это ж правило для локал хоста:

Chain ufw-before-input (1 references) 
pkts bytes target prot opt in out source destination 
0 0 ACCEPT all  — lo any anywhere anywhere

Тогда все правильно, теперь стало понятно.

По-моему лучшее, что можно сделать с ufw - удалить его и использовать iptables.

Хаха.. нашел причину. Идиотизм. Засада пришла оттуда, откуда не ожидал. :)

Мой комп офтопик и аваст. Аваст скотина, походу перехватывает соединения, сканирует и отравляет дальше. Поэтому казалось порт открыт, а на самом деле соединение на себя брал аваст, поэтому срабатывал и телнет и d:\soft\nc>nc .

Хорошо я так вспомнил молодость и запустил netstat , который показал, что никаких соединений то к серверу и нет, и тут меня осенило.

Прошу прощения за беспокойство линуксойдов. :)

использовать iptables

Зачем использовать эту устаревшую упоротую некрофилию? В ufw есть хотя бы человеческий синтаксис.

В iptables нет ничего упоротого и некрофильного. Лаконичный и удобный синтаксис. Если асилить, конечно. Если бы не унаследованные от cli-утилит - и --, а также верхний регистр, никто бы вообще не жаловался.

Ну если уж так хочется быть на гребне волны - можно использовать nftables.

В iptables нет ничего упоротого и некрофильного

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

Лаконичный и удобный синтаксис

Настолько лаконичный и удобный что поверх него сделали Uncomplicated Firewall с синтаксисом из ipfw.

Если асилить, конечно

Асиливать упоротый и устаревший синтаксис чтобы написать несколько простых правил? Но зачем если уже есть интуитивно-понятный ufw с более универсальным и, главное, человеческим синтаксисом.

Если бы не унаследованные от cli-утилит - и --

И зачем нужно было наследовать всякий содом? В ipfw такого почему-то нет.

Ну если уж так хочется быть на гребне волны - можно использовать nftables.

Использовать тестовые альфа-версии сырого ПО в целях обеспечения безопасности — это даже не смешно.

Nftables мне ipfw. синтаксисом напомнил, кстати

Жалко, что еще слишком молодой для продакшна