UFW, IPv4 ve IPv6 için 22'ye izin verir, ancak Etkinleştirilirken SSH Bağlantısı Kesilir

sudo ufw disableardından sudo ufw enableSSH beni kovdu

DMESG raporları

[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

Konsol üzerinden kuralları değiştirmek zorunda kalmadan tekrar giriş yapabilirim (UFW hala etkin).

Bu, Xenial'ın (16.04) çekirdek 4.4'ten 4.15'e (HWE) yükseltilmesinden sonra başladı. 18.04.1 sürümüne yükseltmek sorunu çözmedi.

sürümleri:

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

UFW durumu ayrıntılı (bazı kurallar atlandı, ancak hepsi İZİN VERİLDİ)

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)

Bu neden oluyor ya da en azından beklenen davranışa geri dönülmeli?

Bu cevaba baktım ve geçerli olduğundan emin değilim, ama burada /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: Ben bu sorunu "düzeltmek" beklemiyordum ama sadece referans için SSHD dinler (ve ilgili kural) bağlantı noktasını değiştirdim ve sorun devam ediyor.

— Gaia
kaynak

Yani güvenlik duvarını kapatıp tekrar açtığınızda geçici olarak ssh oturumundan düşmeniz dışında her şey olması gerektiği gibi çalışıyor?

— Bernard Wei

evet, geçici olarak olduğu gibi kesiliyor ve tekrar bağlanmam gerekiyor. "sadece" durak değil

— Gaia

Bu çok garip çünkü ufw ile etkinleştirme / devre dışı bırakma yalnızca yeniden başlattıktan sonra yürürlüğe girecek. Bu komutlar verildiğinde hala çalıştığını (veya çalışmadığını) görmek için systemctl status ufw komutunu kullanarak kontrol edebilirsiniz.

— Bernard Wei

Bu bir çekirdek gerilemesi gibi görünmektedir ve 4.13 ve 4.14 çekirdekleri arasına girilmiş görünmektedir. Şimdi çekirdek ikiye ayırıyorum. Bir iki gün sürecek. Herhangi bir okuyucu suçlu taahhüdünü zaten biliyorsa, zaman kaybetmemek için lütfen buraya gönderin.

— Doug Smythies

Henüz hata numarası yok, sadece çekirdek ikiye ayırmayı bitirdim. 4d3a57f23dec59f0a2362e63540b2d01b37afe0a netfilter: conntrack: gerekmedikçe bağlantı izlemeyi etkinleştirmeyin. Bana birkaç saat ver, ben de bir cevap yazayım.

— Doug Smythies

Arkaplan ve sorunun sınırları:

Sorun yalnızca bu ssh izin kurallarına sahip UFW veya iptables etkinleştirildiğinde ve bir ssh oturumu başlatıldığında oluşur. Yani hiçbir iptables ile başlatılmamış herhangi bir SSH oturumu iyi çalışır, ancak kural kümesi yerine getirildikten sonra rastgele bırakmalara maruz kalabilir.
ufw sadece iptables için bir ön uç olduğunu hatırlayın.
Sorun 4.18-rc8 çekirdeğinde bile var.

Ne oluyor?

sudo ufw allow in port 22Aşağıdaki iptables sonuçları segmentini kuralları:

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

Bunu sudo ufw disabletakiben sudo ufw enableve ssh bağlantısının kendisi iyi kalsa da, sonuçta ortaya çıkan iptables kural kümesi, söz konusu bağlantıyla ilişkilendirmeyi unutmuş ve bu nedenle gelen paketleri geçersiz olarak sınıflandırmıştır. Bir şekilde bağlantı izleme tablosu karıştı ve paket YENİ bile kabul edilmiyor, ancak yanlış bayraklarla veya mevcut bağlantının bir parçası olarak kabul edilmiyor.

Ne ufwyaptığına eşdeğer bir iptables düşünün . İki komut dosyası, biri kural kümesini temizlemek ve diğeri oluşturmak için:

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

Ve:

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

Bu paketlerdeki sonuç, bir yükleme döngüsünden sonra başlatılan bir ssh oturumuyla bir temizleme / yükleme döngüsünden sonra sayılır:

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

Sakat ssh oturum terminalinde yazılan ve PuTTY sonlandırılmadan önce 35 geçersiz paket dikkat edin.

Bu neden çalışmayı durdurdu, eskiden işe yarıyordu?

Bu% 100 tekrarlanabilir olduğundan, çekirdek ikilisi nispeten kolaydı, sadece zaman alıcıydı. Sonuçlar:

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>

Bağlantı entire taahhüt.

Beklenen davranışa nasıl dönülür?

Ufw'yi devre dışı bıraktıktan veya iptables kural kümesini temizledikten sonra yeni bir SSH oturumu oluşturun. Bir sonraki ufw etkinliğinden sağ çıkacaktır, ancak bir noktada rastgele bir düşüşe maruz kalabilir.

Bu sorun, ilgili e-posta listesi aracılığıyla bir noktada yukarı yönde ele alınacaktır.

EDIT: yukarı akış e-posta iş parçacığı (bir geçici çözüm içerir). Geçici çözüm buraya kopyalandı:

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

DÜZENLEME 2: Test ettiğim ve geri bildirdiğim, yukarı yönde önerilen yama .

EDIT 3: 2018.11.06: Bu yukarı doğru durdu ve onları rahatsız etmek için zamanım olmadı. Yakında geri dönmeye çalışacağım.

EDIT 4: 2019.03.17: Çekirdek 5.0 ile bu sorunu güvenilir bir şekilde yeniden oluşturamıyorum.

— Doug Smythies
kaynak

Sorun 4.18-rc8 çekirdeğinde bile devam ediyor. Herhangi bir ssh oturumunun kuyruğunun boş olup olmamasına bağlı olarak sorunun oluşup oluşmayacağı arasında bir ilişki vardır. Hayır, bu hafifletme çözüm değildir. Daha fazla zamana ihtiyacım var.

— Doug Smythies

Tamam teşekkürler. Cevapta bazı değişiklikler yapmam gerekiyor, ama ne zaman olacağını bilmiyorum. Burada birden fazla sorun var. Ben sadece iptables ile ilgili, ikinci bir çekirdek ikiye bölünme kısmen yol. UFW'yi sorundan çıkarmaya çalışıyorum. İşler biraz karışıklık (benim görüşüm) ve conntrak aracı bulduğum ilk taahhüt nedeniyle temelde kırık. Bunu yapmak için yeterli ayrıntıya sahip olduğumda yukarı doğru gideceğim.

— Doug Smythies

@Gaia sonra Doug sadece bunun% 50'sini alacak tam ikramiye atamazsanız IF iki yukarı-oy vardır. Şu anda sadece bir yukarı oy var, bu yüzden% 50 ikramiye güvencesi için bir parça daha ekliyorum, ancak çoğunlukla mükemmel bir cevap olduğu için.

— WinEunuuchs2Unix

@Gaia: Sorununuzun yalnızca bir şekilde UFW kurallarınızın bazılarıyla ilgili olduğunu varsayabilirim. Yukarı yönlü bir e-posta gönderdim (bir hata sistemi yok), ancak UFW'yi tamamen ortadan kaldırdım ve sadece iptables'a bakın. Belirli bir e-posta listesinde olmadığım ve henüz arşivde görmediğim için, moderasyon için tutulduğunu varsayıyorum. Bir kez bağlantı kuracağım.

— Doug Smythies

@Gaia: Spekülasyon yapamıyorum. Tek bildiğim, sadece ssh kuralları ile, UFW etkin ve sonra yeniden önyükleme ssh bağlantısı en azından benim için iyi çalışıyor. Bir sonraki UFW devre dışı bırakma / etkinleştirme işlemine son verilir.

— Doug Smythies