UFW Cho phép 22 cho IPv4 và IPv6 nhưng SSH ngắt kết nối khi kích hoạt

sudo ufw disabletheo sau là đuổi sudo ufw enabletôi ra khỏi SSH

Báo cáo DMESG

[UFW BLOCK] IN=eth0 OUT= MAC=30:........ SRC=192.168.1.me DST=192.168.1.server LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=15776 DF PROTO=TCP SPT=55640 DPT=22 WINDOW=253 RES=0x00 ACK URGP=0

Tôi có thể đăng nhập lại mà không phải thay đổi quy tắc thông qua bảng điều khiển (UFW vẫn được bật).

Điều này bắt đầu sau khi nâng cấp Xenial (16.04) từ kernel 4.4 lên 4.15 (HWE). Nâng cấp lên 18.04.1 không giải quyết được vấn đề.

Phiên bản:

iptables v1.6.1
0,35
4.15.0-29-chung # 31-Ubuntu
Ubuntu 18.04.1 LTS

Trạng thái dài dòng UFW là (một số quy tắc đã bị bỏ qua, nhưng tất cả chúng đều TẤT CẢ)

Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22                         ALLOW IN    Anywhere
22 (v6)                    ALLOW IN    Anywhere (v6)

Tại sao điều này xảy ra, hoặc ít nhất, làm thế nào để trở lại hành vi dự kiến?

Tôi đã xem câu trả lời này và tôi không chắc nó có áp dụng hay không, nhưng đây là /etc/ufw/b Before.rules

#
# 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 conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

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

# ok icmp codes for INPUT
-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

# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -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

PS: Tôi không mong đợi điều này sẽ "khắc phục" vấn đề nhưng chỉ để tham khảo, tôi đã thay đổi cổng SSHD lắng nghe (và quy tắc tương ứng) và vấn đề vẫn tồn tại.

— Gaia
nguồn

Vì vậy, mọi thứ hoạt động như bình thường ngoại trừ việc bạn tạm thời rời khỏi phiên ssh khi bạn tắt tường lửa rồi bật lại?

— Bernard Wei

vâng, trong giây lát như trong nó ngắt kết nối và tôi phải kết nối lại. nó không "chỉ" gian hàng

— Gaia

Điều này rất lạ vì bật / tắt thông qua ufw sẽ chỉ có hiệu lực sau khi bạn khởi động lại. Bạn có thể kiểm tra bằng trạng thái systemctl ufw để xem vẫn đang chạy (hoặc không chạy) khi các lệnh đó được ban hành.

— Bernard Wei

Đây dường như là một hồi quy hạt nhân và dường như đã được giới thiệu giữa các hạt 4.13 và 4.14. Tôi đang làm một nhân đôi bây giờ. Nó sẽ mất một hoặc hai ngày. Nếu bất kỳ độc giả nào đã biết thủ phạm, xin vui lòng đăng ở đây để tôi không lãng phí thời gian.

— Doug Smythies

Không có số lỗi nào, tôi chỉ hoàn thành việc chia nhân. 4d3a57f23dec59f0a2362e63540b2d01b37afe0a netfilter: conntrack: không kích hoạt theo dõi kết nối trừ khi cần. Hãy cho tôi một vài giờ và tôi sẽ viết một câu trả lời.

— Doug Smythies

Bối cảnh và giới hạn cho vấn đề:

Sự cố chỉ xảy ra khi UFW hoặc iptables, với các quy tắc cho phép ssh này được bật và phiên ssh được bắt đầu. tức là bất kỳ phiên SSH nào được bắt đầu mà không có iptables đều hoạt động tốt, nhưng có thể bị loại bỏ ngẫu nhiên một khi bộ quy tắc được đặt đúng chỗ.
nhớ lại rằng ufw chỉ là một mặt trước cho iptables.
Vấn đề hiện diện ngay cả với kernel 4.18-rc8.

Chuyện gì đang xảy ra vậy?

Các sudo ufw allow in port 22kết quả trong phân đoạn quy tắc iptables sau:

Chain ufw-before-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination
      16     1553 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
     386   300622 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
      15     1068 ufw-logging-deny  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
      15     1068 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID

Sau sudo ufw disableđó sudo ufw enable, và mặc dù bản thân kết nối ssh vẫn ổn, bộ quy tắc iptables kết quả dường như đã quên liên kết với kết nối cụ thể đó và do đó phân loại bất kỳ gói tin nào là không hợp lệ. Bằng cách nào đó, bảng theo dõi kết nối đã bị lẫn lộn và gói thậm chí không được coi là MỚI, nhưng với các cờ không chính xác, cũng không được coi là một phần của kết nối hiện có.

Hãy xem xét một iptables rất cơ bản tương đương với những gì ufwđang làm. Hai tập lệnh, một để xóa bộ quy tắc và một để tạo nó:

#!/bin/sh
FWVER=0.01
#
# clear_firewall_min 2018.08.10 Ver:0.01
#       clear iptables minimum.
#       Currently for this question:
#       /ubuntu/1059781/ufw-allows-22-for-ipv4-and-ipv6-but-ssh-disconnects-when-enabling
#
echo "Loading clear_firewall_min version $FWVER..\n"

# The location of the iptables program
#
IPTABLES=/sbin/iptables

#Set some stuff
#
EXTIF="ens5"
UNIVERSE="0.0.0.0/0"

#Clearing any previous configuration
#
echo "  Clearing any existing rules and setting default policies.."
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT

# Reset all IPTABLES counters
$IPTABLES -Z

#sleep 10

echo clear_firewall_min $FWVER done.

Và:

#!/bin/sh
#
# test_firewall 2018.08.13 Ver:0.01
#       Minimum version of most basic iptables firewall.
#
# test_firewall 2018.08.09 Ver:0.01
#       Most basic iptables firewall.
#       Currently for this question:
#       /ubuntu/1059781/ufw-allows-22-for-ipv4-and-ipv6-but-ssh-disconnects-when-enabling
#

#sleep 50

# The location of the iptables program
#
IPTABLES=/sbin/iptables

#Set some stuff
#
EXTIF="ens5"
UNIVERSE="0.0.0.0/0"

#Clearing any previous configuration
#
#echo "  Clearing any existing rules and setting default policies.."
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT

# loopback interfaces are valid.
#
$IPTABLES -A INPUT -i lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT

$IPTABLES -A INPUT -i $EXTIF -p tcp -m conntrack --ctstate INVALID -j LOG --log-prefix "IINVALID:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -p tcp -m conntrack --ctstate INVALID -j DROP
$IPTABLES -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j LOG --log-prefix "NEW TCP no SYN:" --log-level info
$IPTABLES -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
$IPTABLES -A INPUT -i $EXTIF -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -i $EXTIF -p tcp -m conntrack --ctstate NEW --dport 22 -j ACCEPT

echo "test_firewall_min $FWVER done..." >> /dev/kmsg

sleep 3

Kết quả là các gói này được tính sau một chu kỳ xóa / tải với phiên ssh được bắt đầu sau chu kỳ tải:

doug@s17:~$ sudo iptables -v -x -n -L
Chain INPUT (policy DROP 3 packets, 220 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
      35     6388 LOG        tcp  --  ens5   *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID LOG flags 0 level 6 prefix "IINVALID:"
      35     6388 DROP       tcp  --  ens5   *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
       0        0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 ctstate NEW LOG flags 0 level 6 prefix "NEW TCP no SYN:"
       0        0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 ctstate NEW
       9      680 ACCEPT     all  --  ens5   *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
       0        0 ACCEPT     tcp  --  ens5   *       0.0.0.0/0            0.0.0.0/0            ctstate NEW tcp dpt:22

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

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

Lưu ý 35 gói không hợp lệ khi tôi nhập vào thiết bị đầu cuối phiên ssh bị tê liệt và trước khi PuTTY chấm dứt.

Tại sao điều này ngừng hoạt động, nó được sử dụng để làm việc?

Bởi vì điều này có thể lặp lại 100%, việc chia nhân tương đối dễ dàng, chỉ tốn thời gian. Kết quả là:

4d3a57f23dec59f0a2362e63540b2d01b37afe0a is the first bad commit
commit 4d3a57f23dec59f0a2362e63540b2d01b37afe0a
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Jul 28 11:22:04 2017 +0200

    netfilter: conntrack: do not enable connection tracking unless needed

    Discussion during NFWS 2017 in Faro has shown that the current
    conntrack behaviour is unreasonable.

    Even if conntrack module is loaded on behalf of a single net namespace,
    its turned on for all namespaces, which is expensive.  Commit
    481fa373476 ("netfilter: conntrack: add nf_conntrack_default_on sysctl")
    attempted to provide an alternative to the 'default on' behaviour by
    adding a sysctl to change it.

    However, as Eric points out, the sysctl only becomes available
    once the module is loaded, and then its too late.

    So we either have to move the sysctl to the core, or, alternatively,
    change conntrack to become active only once the rule set requires this.

    This does the latter, conntrack is only enabled when a rule needs it.

    Reported-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>

Liên kết với toàn bộ cam kết.

Làm thế nào để trở lại hành vi dự kiến?

Sau khi vô hiệu hóa ufw hoặc xóa bộ quy tắc iptables, hãy tạo một phiên SSH mới. Nó sẽ tồn tại trong lần kích hoạt ufw tiếp theo, nhưng đôi khi có thể bị rơi ra ngẫu nhiên.

Vấn đề này sẽ được đưa lên thượng nguồn tại một số điểm, thông qua danh sách email liên quan.

EDIT: luồng e-mail ngược dòng (chứa một công việc xung quanh). Cách giải quyết được sao chép ở đây:

echo 1 | sudo tee /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal

EDIT 2: bản vá đề xuất ngược dòng , mà tôi đã thử nghiệm và báo cáo lại.

EDIT 3: 2018.11,06: Điều này đã bị đình trệ và tôi không có thời gian để làm phiền họ. Tôi sẽ cố gắng lấy lại sớm.

EDIT 4: 2019.03.17: Tôi không thể tái tạo vấn đề này một cách đáng tin cậy với kernel 5.0.

— Doug Smythies
nguồn

Vấn đề vẫn tồn tại ngay cả với kernel 4.18-rc8. Có một mối quan hệ giữa nếu vấn đề sẽ xảy ra hay không dựa trên việc hàng đợi đến bất kỳ phiên ssh nào trống hay không. Không, giảm thiểu đó không phải là giải pháp. Tôi cần thêm thời gian.

— Doug Smythies

Được rồi cảm ơn. Tôi phải thực hiện một số thay đổi cho câu trả lời, nhưng không biết khi nào. Có nhiều vấn đề ở đây. Tôi là một phần của cách phân chia hạt nhân thứ hai, chỉ liên quan đến iptables. Tôi đang cố gắng loại bỏ UFW khỏi vấn đề này. Mọi thứ là một mớ hỗn độn (ý kiến của tôi), và công cụ conntrak về cơ bản bị hỏng vì cam kết đầu tiên tôi tìm thấy. Tôi sẽ đi ngược dòng một khi tôi có đủ chi tiết để làm như vậy.

— Doug Smythies

@Gaia Nếu bạn không chỉ định tiền thưởng đầy đủ thì Doug sẽ chỉ nhận được 50% trong số đó NẾU có hai lượt bình chọn. Hiện tại chỉ có một phiếu bầu tăng, vì vậy tôi thêm một phần nữa để đảm bảo tiền thưởng 50% nhưng chủ yếu là vì đó là một câu trả lời tuyệt vời.

— WinEunuuchs2Unix

@Gaia: Tôi chỉ có thể giả sử vấn đề của bạn bằng cách nào đó có liên quan đến một số quy tắc UFW khác của bạn. Tôi đã gửi một email ngược dòng (họ không có hệ thống lỗi), nhưng tôi đã loại bỏ hoàn toàn UFW và chỉ đề cập đến iptables. Vì tôi không có trong danh sách e-mail cụ thể đó và tôi chưa thấy nó trong kho lưu trữ, tôi cho rằng nó đang bị giữ để kiểm duyệt. Tôi sẽ cung cấp một liên kết một khi có sẵn.

— Doug Smythies

@Gaia: Tôi không thể suy đoán. Tất cả những gì tôi biết là, chỉ với các quy tắc ssh, UFW được kích hoạt và sau đó khởi động lại kết nối ssh hoạt động tốt, ít nhất là đối với tôi. Nó bị loại bỏ khi vô hiệu hóa / kích hoạt UFW tiếp theo.

— Doug Smythies