Genel olarak:
Güvenlik duvarı yapılandırmasını görüntülemek ve değiştirmek, rootsınırlı bağlantı noktası numarası aralığında hizmetlerin açılması gibi yönetici ayrıcalıklarına ( ) ihtiyaç duyar . Bu, ya oturum açmanız gerektiği anlamına gelir ya rootda alternatif sudoolarak komutu root olarak çalıştırmak için kullanılır . Bu tür komutları isteğe bağlı olarak işaretlemeye çalışacağım [sudo].
İçindekiler:
- Sipariş konularda veya arasındaki fark
-Ive-A
- Geçerli güvenlik duvarı yapılandırmasını görüntüleme
- Çıkışını yorumlama
iptables -L -v -n
- Ortamınızı tanıyın
- INPUT ve FORWARD zincirleri
- Çekirdek modülleri
1. Sipariş konularda ya arasındaki fark -Ive-A
Hatırlanması gereken şey, güvenlik duvarı kurallarının listelendikleri sırayla kontrol edilmesidir. Bir pakete veya bağlantıya izin veren veya devre dışı bırakan bir kural tetiklendiğinde çekirdek zinciri işlemeyi durduracaktır.
Bence en yaygın hata acemi duvarı yöneticileri için böyle aşağıda biri olarak, yeni bir liman açmak için doğru talimatları takip olmasıdır:
[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
ve sonra bunun etkili olmayacağını keşfedin.
Bunun nedeni, -Aseçeneğin tüm yeni kurallardan sonra
ve yeni güvenlik duvarındaki son kuralın, açık bir şekilde izin verilmeyen tüm trafiği engelleyen,
...
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
8 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
Veya iptables-save eşdeğeri:
...
iptables -A INPUT -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
ve 8080 numaralı TCP bağlantı noktasını açan yeni kurala asla ulaşılamaz. (inatla 0 paket ve sıfır baytta kalan sayaçlar tarafından kanıtlandığı gibi).
Kuralı -Iyeni kuralla ekleyerek zincirde ilk olurdu ve çalışacaktır.
2. Geçerli güvenlik duvarı yapılandırmasını görüntüleme
Güvenlik duvarı yöneticisi için önerim, kullanıcı dostu araçlardan güvenlik duvarı sorunlarını teşhis etmeye çalışmak yerine Linux çekirdeğinin çalıştığı gerçek yapılandırmaya bakmaktır. Genellikle altta yatan sorunları anladıktan sonra, bunları bu araçlar tarafından desteklenen bir konuda kolayca çözebilirsiniz.
Komut [sudo] iptables -L -v -narkadaşın (bazı insanlar iptables-savedaha iyi olsa da ). Genellikle yapılandırmalar tartışılırken, --line-numberssatırları numaralandırmak için seçeneği kullanmak da yararlıdır . #X kuralına atıfta bulunmak onları tartışmayı biraz daha kolaylaştırır.
Not: NAT kuralları iptables-saveçıktıya dahil edilir, ancak -t natseçenek ekleyerek ayrı olarak listelenmelidir [sudo] iptables -L -v -n -t nat --line-numbers.
Komutu birkaç kez çalıştırmak ve sayaçları artırmak için kontrol etmek, yeni bir kuralın gerçekten tetiklenip tetiklenmediğini görmek için yararlı bir araç olabilir.
[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 784K 65M fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 2789K 866M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 15 1384 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 117.239.37.150 0.0.0.0/0 reject-with icmp-port-unreachable
2 4 412 REJECT all -- * * 117.253.208.237 0.0.0.0/0 reject-with icmp-port-unreachable
Alternatif olarak, çıktısı iptables-save, yukarıdaki güvenlik duvarı yapılandırmasını yeniden oluşturabilecek bir komut dosyası verir:
[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
Anlaşılması daha kolay bulacağınız bir tercih meselesidir.
3. çıkışını yorumlama iptables -L -v -n
Politika varsayılan eylemi zincir kullanımlarını hiçbir açık kural maçları ayarlar. Gelen INPUTtüm trafiği KABUL olarak ayarlanır zinciri.
GİRİŞ zincirinin ilk kural TCP bağlantı noktası 22 (için mukadder tüm trafiği (kaynak 0.0.0.0/0 ve hedef 0.0.0.0/0) gönderir, hemen ilginç bir tanesidir tcp dpt:22() özel bir hedefe SSH varsayılan port fail2ban-SSH) . Adından da anlaşılacağı gibi, bu kural fail2ban (diğer şeylerin yanı sıra sistem günlük dosyalarını olası kötüye kullanım için tarayan ve kötüye kullanıcının IP adresini engelleyen bir güvenlik ürünü) tarafından korunur.
Bu kural iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHiptables-save as çıktısına benzer bir iptables komut satırı tarafından oluşturulmuş olurdu -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. Genellikle bu gösterimlerden herhangi birini belgelerde bulabilirsiniz.
Sayaçlar, bu kuralın 784'000 paket ve 65 Megabayt veriyle eşleştiğini gösterir.
Bu ilk kurala uyan trafik, fail2ban-SSHstandart olmayan bir zincir olarak OUTPUT zincirinin altında listelenen zincir tarafından işlenir .
Bu zincir, her bir istismarcı için bir tane (kaynak ip adresi 117.253.221.166 veya 58.218.211.166) engellenen (a ile reject-with icm-port-unreachable) iki kuraldan oluşur .
-A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable
Engellenen ana bilgisayarlardan olmayan SSH paketlerine henüz izin verilmiyor veya izin verilmiyor ve şimdi özel zincirin tamamlanacağı GİRİŞ zincirindeki ikinci kurala göre kontrol edilecek.
Bağlantı noktası 22 için hedeflenmeyen tüm paketler INPUT zincirindeki ilk kuralı geçti ve INPUT kuralı # 2'de de değerlendirilecek.
INPUT kural numarası 2 , bunun bağlantıları izleyen durum bilgisi olan bir güvenlik duvarı olmasını sağlar . Bunun bazı avantajları vardır, sadece yeni bağlantılar için paketlerin tüm kural setine göre kontrol edilmesi gerekir, ancak izin verildiğinde, kurulmuş veya ilgili bir bağlantıya ait ek paketler daha fazla kontrol edilmeden kabul edilir.
Giriş kuralı # 2, açık ve ilgili tüm bağlantılarla eşleşir ve bu kurala uyan paketlerin daha fazla değerlendirilmesi gerekmez.
Not: durum bilgisi olan bir güvenlik duvarının yapılandırmasındaki kural değişiklikleri, kurulan bağlantıları değil, yalnızca yeni bağlantıları etkiler.
Buna karşılık, basit bir paket filtresi, bağlantı durumunu izlemeden her paketi tüm kural kümesine karşı test eder. Böyle bir güvenlik duvarında durum anahtar sözcükleri kullanılmaz.
INPUT kuralı # 3 oldukça sıkıcı, geri döngü ( loveya 127.0.0.1) arayüzüne bağlanan tüm trafiğe izin verilir.
INPUT kuralları 4, 5 ve 6, YENİ bağlantılara erişim izni vererek (mevcut bağlantılara zaten INPUT kural 2 tarafından izin verilir) 22, 80 ve 443 numaralı TCP bağlantı noktalarını (sırasıyla SSH, HTTP ve HTTPS için varsayılan bağlantı noktaları) açmak için kullanılır.
Durum bilgisi olmayan bir güvenlik duvarında bu kurallar durum nitelikleri olmadan görünür:
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
veya
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
Son INPUT kuralı, # 7, INPUT kural 1-7'de erişim verilmeyen tüm trafiği engelleyen bir kuraldır. Oldukça yaygın bir sözleşme: izin verilmeyen her şey reddedilir. Teorik olarak, bu kural varsayılan POLİTİKAYI REDDET olarak ayarlanarak atlanabilirdi.
Daima tüm zinciri araştırın.
4. Ortamınızı tanıyın
4.1. Yazılım güvenlik duvarındaki ayarlar, ağın başka bir yerinde tutulan güvenlik ayarlarını etkilemez, yani iptablesyönlendiricilerdeki veya ağınızdaki diğer güvenlik duvarlarındaki değiştirilmemiş erişim kontrol listeleriyle bir ağ hizmeti açmanıza rağmen trafiği yine de engelleyebilir ...
4.2. Hiçbir hizmet dinlemiyorsa , güvenlik duvarı ayarlarına bakılmaksızın bağlanamaz ve bağlantı reddedilemez hatası alabilirsiniz . Bu nedenle:
- Bir hizmetin dinlediğini (doğru ağ arabiriminde / ip adresinde) ve beklediğiniz
[sudo] netstat -plnutveya alternatif olarak kullandığınız bağlantı noktası numaralarını kullandığını doğrulayın ss -tnlp.
- Hizmetlerinizin henüz çalışmaması gerekiyorsa, örneğin netcat ile basit bir dinleyiciyi taklit edin:
[sudo] nc -l -p 123veya openssl s_server -accept 1234 [options] bir TLS / SSL dinleyicisine ihtiyacınız varsa ( man s_serverseçenekleri kontrol edin ).
- Uzak bir ana bilgisayardan denemeden önce sunucunun kendisinden
telnet <IP of Server> 123veya yani echo "Hello" | nc <IP of Server> 123TLS / SSL güvenli hizmetini test ederken bağlanabildiğinizi doğrulayın openssl s_client -connect <IP of Server>:1234.
4.3. Hizmetleriniz tarafından kullanılan protokolleri öğrenin. Yeterince anlamadığınız hizmetleri düzgün bir şekilde etkinleştiremez / devre dışı bırakamazsınız. Örneğin:
- TCP veya UDP kullanılıyor mu veya her ikisi de (DNS'de olduğu gibi)?
- sabit bir varsayılan bağlantı noktası kullanıyor mu (örneğin bir web sunucusu için TCP bağlantı noktası 80 gibi bir şey)?
- alternatif olarak değişebilen dinamik bir port numarası seçilir (yani Portmap'a kayıt olan klasik NFS gibi RPC hizmetleri)?
- rezil FTP , pasif modu kullanmak için yapılandırıldığında hem sabit hem de dinamik bir bağlantı noktası numarası olmak üzere iki bağlantı noktası kullanır ...
- içindeki hizmet, bağlantı noktası ve protokol açıklamalarının
/etc/servicesbir bağlantı noktası kullanan gerçek hizmetle eşleşmesi gerekmez.
4.4. Çekirdek paket filtresi, ağ bağlantısını kısıtlayabilecek tek şey değildir:
- SELinux ağ hizmetlerini de kısıtlıyor olabilir.
getenforceSELinux'un çalışıp çalışmadığını onaylar.
- Her ne kadar biraz belirsiz hale gelse de TCP Paketleyicileri hala ağ güvenliğini sağlamak için güçlü bir araçtır. Kontrol dosyaları
ldd /path/to/service |grep libwrapve /hosts.[allow|deny]kontrol dosyaları.
5. INPUTveya FORWARDZincirler
Zincir kavramı burada daha ayrıntılı olarak açıklanmıştır, ancak kısaca:
INPUTAçabilir ve / veya iptables komutları nerede hizmetler için yakın ağ bağlantı noktaları ana bilgisayarda, yerel olarak çalışan nereye zinciridir.
FORWARDEğer Linux makine köprü, yönlendirici hypervisor gibi davranan ve / veya ağ adresini yapar diğer sistemlere çekirdek tarafından iletilen alır filtre trafik kuralları, fiili sistemlerini değil aynı zamanda Docker kapları ve Sanal konuk Sunucular sunucularını uygulamak nerede zinciridir çeviri ve liman yönlendirme.
Yaygın bir yanlış anlama, bir docker kapsayıcısı veya KVM konukunun yerel olarak çalıştığı için, geçerli filtre kurallarının INPUT zincirinde olması gerekir, ancak genellikle durum böyle değildir.
6. Çekirdek modülleri
Paket filtresi Linux çekirdeğinde çalıştığından, dinamik modül olarak da derlenebilir, aslında çoklu modüller. Çoğu dağıtım, modüller olarak netfilter içerir ve gerekli netfilter modülleri çekirdeğe gerektiği gibi yüklenir, ancak bazı modüller için bir güvenlik duvarı yöneticisinin yüklendiklerinden emin olması gerekir. Bu öncelikle nf_conntrack_ftpyüklenebilen bağlantı izleme modülleri ile ilgilidir insmod.
Çalışan çekirdeğe yüklü olan modüller ile görüntülenebilir lsmod.
Modüllerin yeniden başlatmalar arasında kalıcı olarak yüklenmesini sağlama yöntemi Linux dağıtımına bağlıdır.
