UFW Memungkinkan 22 untuk IPv4 dan IPv6 tetapi SSH Putus Saat Diaktifkan

10

sudo ufw disablediikuti oleh sudo ufw enablemenendang saya keluar dari SSH

Laporan 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

Saya dapat masuk kembali tanpa harus mengubah aturan melalui konsol (UFW masih diaktifkan).

Ini dimulai setelah memutakhirkan Xenial (16.04) dari kernel 4.4 ke 4.15 (HWE). Upgrade ke 18.04.1 tidak menyelesaikan masalah.

Versi:

  • iptables v1.6.1
  • ufw 0,35
  • 4.15.0-29-generik # 31-Ubuntu
  • Ubuntu 18.04.1 LTS

Status UFW verbose adalah (beberapa aturan dihilangkan, tetapi semuanya MENGIZINKAN)

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)

Mengapa ini terjadi, atau setidaknya, bagaimana kembali ke perilaku yang diharapkan?

Saya melihat jawaban ini , dan saya tidak yakin itu berlaku, tapi inilah /etc/ufw/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: Saya tidak berharap ini untuk "memperbaiki" masalah tetapi hanya untuk referensi saya mengubah port SSHD mendengarkan (dan aturan yang sesuai) dan masalah berlanjut.

kernel ssh 18.04 firewall ufw Gaia
sumber
Jadi semuanya berjalan sebagaimana mestinya kecuali bahwa Anda sebentar turun dari sesi ssh ketika Anda mematikan firewall lalu hidupkan kembali?
Bernard Wei
ya, sebentar karena di dalamnya terputus dan saya harus terhubung lagi. itu bukan "hanya" kios
Gaia
Ini sangat aneh karena mengaktifkan / menonaktifkan via ufw hanya akan berlaku setelah Anda reboot. Anda dapat memeriksa menggunakan status systemctl ufw untuk melihat bahwa masih berjalan (atau tidak berjalan) ketika perintah itu dikeluarkan.
Bernard Wei
2
Ini tampaknya merupakan regresi kernel dan tampaknya telah diperkenalkan antara kernel 4.13 dan 4.14. Saya sedang melakukan pembelahan kernel sekarang. Ini akan memakan waktu satu atau dua hari. Jika ada pembaca yang tahu pelakunya melakukan, silakan posting di sini sehingga saya tidak membuang waktu.
Doug Smythies
1
Belum ada nomor bug, saya baru saja menyelesaikan pembagian kernel. 4d3a57f23dec59f0a2362e63540b2d01b37afe0a netfilter: conntrack: jangan aktifkan pelacakan koneksi kecuali diperlukan. Beri saya beberapa jam dan saya akan menulis jawaban.
Doug Smythies

Jawaban:

9

Latar belakang, dan batasan untuk masalah ini:

  • Masalah hanya terjadi ketika UFW, atau iptables, dengan ssh ini memperbolehkan aturan, diaktifkan dan sesi ssh dimulai. yaitu Setiap sesi SSH yang dimulai tanpa iptables sama sekali berfungsi dengan baik, tetapi dapat dikenakan drop out secara acak setelah aturan ditetapkan.
  • ingat bahwa ufw hanyalah ujung depan untuk iptables.
  • Masalahnya ada bahkan dengan kernel 4.18-rc8.

Apa yang sedang terjadi?

The sudo ufw allow in port 22hasil dalam iptables berikut aturan segmen:

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

Setelah sudo ufw disablediikuti oleh sudo ufw enable, dan meskipun koneksi ssh itu sendiri tetap baik-baik saja, himpunan aturan iptables yang dihasilkan tampaknya telah melupakan hubungan dengan koneksi tertentu dan karenanya mengklasifikasikan paket yang masuk sebagai tidak valid. Entah bagaimana tabel pelacakan koneksi menjadi bingung dan paket tersebut bahkan tidak dianggap BARU, tetapi dengan tanda yang salah, juga tidak dianggap sebagai bagian dari koneksi yang ada.

Pertimbangkan iptables yang sangat dasar yang setara dengan apa yang ufwsedang dilakukan. Dua skrip, satu untuk menghapus set aturan dan satu untuk membuatnya:

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

Dan:

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

Menghasilkan paket-paket ini dihitung setelah siklus clear / load dengan sesi ssh yang dimulai setelah siklus load:

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

Perhatikan 35 paket yang tidak valid saat saya mengetik di terminal sesi ssh lumpuh, dan sebelum Putty dihentikan.

Mengapa ini berhenti bekerja, dulu bekerja?

Karena ini 100% dapat diulang, pembelahan kernel relatif mudah, hanya memakan waktu. Hasilnya adalah:

4d3a57f23dec59f0a2362e63540b2d01b37afe0a is the first bad commit
commit 4d3a57f23dec59f0a2362e63540b2d01b37afe0a
Author: Florian Westphal <[email protected]>
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 <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>

Tautan ke seluruh komit.

Bagaimana cara kembali ke perilaku yang diharapkan?

Setelah menonaktifkan ufw atau menghapus set aturan iptables, buat sesi SSH baru. Ini akan bertahan jika memungkinkan ufw berikutnya, tetapi mungkin akan jatuh secara acak di beberapa titik.

Masalah ini akan diangkat di beberapa titik, melalui daftar email terkait.

EDIT: utas email hulu (berisi pekerjaan sekitar). Solusi disalin di sini:

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

EDIT 2: patch hulu yang diusulkan , yang telah saya uji dan laporkan kembali.

EDIT 3: 2018.11.06: Ini macet di hulu, dan saya belum punya waktu untuk mengganggu mereka. Saya akan mencoba untuk segera kembali.

EDIT 4: 2019.03.17: Saya tidak bisa mereproduksi masalah ini dengan kernel 5.0.

Doug Smythies
sumber
1
Masalah ini tetap ada bahkan dengan kernel 4.18-rc8. Ada hubungan antara apakah masalah akan terjadi atau tidak didasarkan pada apakah antrian untuk sesi ssh kosong atau tidak. Tidak, mitigasi itu bukanlah solusi. Saya butuh lebih banyak waktu.
Doug Smythies
1
Ok terima kasih. Saya harus membuat beberapa perubahan pada jawabannya, tetapi tidak tahu kapan. Ada beberapa masalah di sini. Saya bagian jalan melalui kernel kedua, yang terkait dengan iptables saja. Saya mencoba menghilangkan UFW dari masalah ini. Hal-hal agak berantakan (pendapat saya), dan alat conntrak pada dasarnya rusak karena komit pertama yang saya temukan. Saya akan pergi ke atas begitu saya memiliki detail yang cukup untuk melakukannya.
Doug Smythies
1
@ Gaia Jika Anda tidak menetapkan karunia penuh maka Doug hanya akan mendapatkan 50% dari itu JIKA ada dua suara. Saat ini hanya ada satu suara di atas jadi saya menambahkan yang lain di bagian untuk jaminan hadiah 50% tetapi kebanyakan karena itu adalah jawaban yang sangat baik.
WinEunuuchs2Unix
1
@ Gaia: Saya hanya bisa berasumsi masalah Anda entah bagaimana terkait dengan beberapa aturan UFW lainnya. Saya telah mengirim e-mail upstream (mereka tidak memiliki sistem bug), tetapi saya sepenuhnya menghilangkan UFW, dan hanya merujuk ke iptables. Karena saya tidak ada dalam daftar e-mail itu, dan saya belum melihatnya di arsip, saya menganggap itu ditahan untuk moderasi. Saya akan memberikan tautan setelah tersedia.
Doug Smythies
1
@ Gaia: Saya tidak bisa berspekulasi. Yang saya tahu adalah, dengan hanya aturan ssh, UFW diaktifkan dan kemudian boot ulang koneksi ssh berfungsi dengan baik, setidaknya untuk saya. Itu akan dijatuhkan setelah menonaktifkan / mengaktifkan UFW berikutnya.
Doug Smythies