UFW อนุญาต 22 สำหรับ IPv4 และ IPv6 แต่ SSH ตัดการเชื่อมต่อเมื่อเปิดใช้งาน

sudo ufw disableตามด้วยsudo ufw enableเตะฉันออกจาก SSH

รายงาน 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

ฉันสามารถล็อกอินกลับโดยไม่ต้องเปลี่ยนกฎผ่านทางคอนโซล (ยังเปิดใช้งาน UFW)

สิ่งนี้เริ่มต้นหลังจากอัพเกรด Xenial (16.04) จากเคอร์เนล 4.4 เป็น 4.15 (HWE) การอัปเกรดเป็น 18.04.1 ไม่ได้แก้ปัญหา

รุ่น:

• iptables v1.6.1
• ufw 0.35
• 4.15.0-29-generic # 31-Ubuntu
• Ubuntu 18.04.1 LTS

สถานะ verbose UFW คือ (บางกฎถูกละเว้น แต่ทั้งหมดล้วนอนุญาต)

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)

เหตุใดสิ่งนี้จึงเกิดขึ้นหรืออย่างน้อยที่สุดจะกลับไปใช้พฤติกรรมที่คาดหวังได้อย่างไร

ฉันดูคำตอบนี้และฉันไม่แน่ใจว่ามันใช้ แต่นี่คือ / etc / uww/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: ฉันไม่ได้คาดหวังสิ่งนี้เพื่อ "แก้ไข" ปัญหา แต่สำหรับการอ้างอิงฉันเปลี่ยนพอร์ต SSHD ฟัง (และกฎที่เกี่ยวข้อง) และปัญหายังคงอยู่

ความเป็นมาและขอบเขตของปัญหา:

• ปัญหาเกิดขึ้นเฉพาะเมื่อ UFW หรือ iptables ที่มีกฎการอนุญาต ssh เหล่านี้ถูกเปิดใช้งานและเริ่มเซสชัน ssh เช่นเซสชัน SSH ใด ๆ ที่เริ่มต้นโดยไม่มี iptables ทำงานได้ดี แต่อาจมีการปล่อยแบบสุ่มเมื่อมีการตั้งค่ากฎ
• จำได้ว่า ufw เป็นเพียงส่วนหน้าสำหรับ iptables
• ปัญหานี้เกิดขึ้นแม้กระทั่งกับเคอร์เนล 4.18-rc8

เกิดอะไรขึ้น?

sudo ufw allow in port 22ผลลัพธ์ใน iptables ต่อไปนี้กฎส่วน:

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

ตามsudo ufw disableมาด้วยsudo ufw enableและถึงแม้ว่าการเชื่อมต่อ ssh ยังคงดีชุดกฎ iptables ผลลัพธ์ดูเหมือนจะลืมการเชื่อมโยงกับการเชื่อมต่อนั้นและดังนั้นจึงจัดประเภทแพคเก็ตเข้ามาใด ๆ ที่ไม่ถูกต้อง ตารางติดตามการเชื่อมต่อได้สับสนและแพ็คเก็ตไม่ได้พิจารณาใหม่ แต่ด้วยการตั้งค่าสถานะที่ไม่ถูกต้องและไม่ถือว่าเป็นส่วนหนึ่งของการเชื่อมต่อที่มีอยู่

พิจารณา iptables ขั้นพื้นฐานที่เทียบเท่ากับสิ่งที่ufwกำลังทำ สองสคริปต์หนึ่งรายการสำหรับล้างชุดกฎและอีกหนึ่งสคริปต์สำหรับสร้าง:

#!/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.

และ:

#!/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

ผลลัพธ์ในแพ็กเก็ตเหล่านี้นับหลังจากล้าง / โหลดรอบด้วยเซสชัน ssh ที่เริ่มต้นหลังจากรอบโหลด:

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

สังเกตเห็น 35 แพ็กเก็ตที่ไม่ถูกต้องตามที่ฉันพิมพ์บนเทอร์มินัลเซสชัน cshppled และก่อนที่ PuTTY จะถูกยกเลิก

ทำไมการหยุดทำงานจึงใช้งานได้

เนื่องจากสามารถทำซ้ำได้ 100% การแบ่งเคอร์เนลค่อนข้างง่ายใช้เวลานาน ผลการวิจัยพบว่า:

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>

เชื่อมโยงไปสู่การกระทำทั้งหมด

จะเปลี่ยนกลับไปใช้พฤติกรรมที่คาดหวังได้อย่างไร

หลังจากปิดใช้งาน ufw หรือล้างชุดกฎ iptables ให้สร้างเซสชัน SSH ใหม่ มันจะอยู่รอดในการเปิดใช้งาน ufw ที่ตามมา แต่อาจมีการปล่อยแบบสุ่มในบางจุด

ปัญหานี้จะเกิดขึ้นในบางช่วงเวลาผ่านรายการอีเมลที่เกี่ยวข้อง

แก้ไข: เธรดอีเมล upstream (มีการแก้ไข) วิธีแก้ปัญหาที่คัดลอกมาที่นี่:

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

แก้ไข 2: แพทช์อัปสตรีมที่เสนอซึ่งฉันได้ทดสอบและรายงานกลับ

แก้ไข 3: 2018.11.06: สิ่งนี้หยุดชะงักและฉันไม่มีเวลารบกวนพวกเขา ฉันจะพยายามกลับไปหามันในไม่ช้า

แก้ไข 4: 2019.03.17: ฉันไม่สามารถสร้างปัญหานี้ได้อย่างน่าเชื่อถือด้วยเคอร์เนล 5.0