Varsayılan port numarasını değiştirmek gerçekten güvenliği arttırıyor mu?


69

Özel uygulamalar için farklı port numaraları kullanmanız gerektiğini söyleyen tavsiyeler gördüm (örneğin intranet, özel veritabanı, yabancıların kullanmayacağı herhangi bir şey).

Güvenliği artırabileceğine ikna olmadım çünkü

  1. Liman tarayıcıları var
  2. Bir uygulama savunmasız ise, liman numarasından bağımsız olarak kalır.

Bir şey mi kaçırdım yoksa kendi soruma cevap verdim mi?


30
Yaptığım şeylerden biri bal tencere olarak belirli varsayılan portları kullanmak (örn. SSH port 22). Bu bağlantı noktalarına bağlanmaya çalışan herkes, tamamen bir xsüre için tamamen engellenir . Port taramasına karşı etkili olduğu kanıtlanmıştır. Tabii ki, bu güvenlik araç kutusundaki tek bir araçtır.
Belmin Fernandez

Müstehcenlik yoluyla güvenlik hakkında genel soru burada sorulur: security.stackexchange.com/questions/2430/…
Tony Meyer

iyi belki "çocuklar için komut dosyası" için bir engel
Lukasz Madon 29:11

1
@BelminFernandez, "güvenlik araç kutusundaki bir araç" ? Hayır, bu sunucu yükünü (performansı) azaltmak içindir ve yalnızca yanılsama dışında güvenlikle ilgisi yoktur . Güvenlik açısından, sunucu zaten güçlü ise tamamen gereksizdir ve sunucu savunmasızsa daha güvenli hale getirmez.
Pacerier

@Pererier, Çaba ve odaklamanın daha sağlam güvenlik uygulamaları uygulamak konusunda olması gerektiği konusunda hemfikirdi. Ancak, ikisini birden yapamamanızın bir nedeni yok.
Belmin Fernandez

Yanıtlar:


68

Hedefli bir saldırıya karşı ciddi bir savunma sağlamıyor. Sunucunuz hedefleniyorsa, dediğiniz gibi, sizi taramaya başlayacak ve kapılarınızın nerede olduğunu bulacaktır.

Bununla birlikte, SSH'yi varsayılan 22 numaralı bağlantı noktasından çıkarmak, hedeflenmemiş ve amatör senaryo kiddie tipi saldırıların bir kısmını engelleyecektir. Bunlar özellikle, özellikle 22 numaralı bağlantı noktasının açık olup olmadığını ve bir tane bulduklarında büyük bir IP adresi bloğu taraması için komut dosyaları kullanan, özellikle karmaşık olmayan kullanıcılardır ve bunlara bir tür saldırı başlatırlar (kaba kuvvet, sözlük saldırısı, vb). Makineniz taranmakta olan IP bloğundaysa ve 22 numaralı bağlantı noktasında SSH çalışmıyorsa, yanıt vermez ve bu nedenle bu komut dosyası gönderen çocuğa saldırması gereken makineler listesinde görünmez. Ergo, sağlanan bazı düşük seviyeli güvenlik var, ancak yalnızca bu tür bir fırsatçı saldırı için.

Örneğin, sunucunuzda zaman - günlüğü dalışı varsa (SSH'nin 22 numaralı bağlantı noktasında olduğu varsayılarak) ve yapabileceğiniz tüm benzersiz SSH girişimlerini çekin. Ardından SSH'yi bu bağlantı noktasından uzaklaştırın, biraz bekleyin ve tekrar dalış yapmaya başlayın. Hiç şüphesiz daha az saldırı bulacaksınız.

Fail2Ban'ı halka açık bir web sunucusunda çalıştırdım ve SSH'yi 22 numaralı limandan çıkardığımda gerçekten çok açıktı. Fırsatçı saldırıları büyüklük sırasına göre kesti.


3
Kabul. SSH'yi standart olmayan bir porta taşımaya çalışırken çok benzer bir düşüş gördüm. Neyse ki parola auth devre dışı bırakıldığında, bu gerçekten bir sorun değil.
EEAA

3
Şimdiye kadar burada en iyi cevap. Her şey saldıran kişilere iniyor. Bir keresinde, taramalı bir çocuktan sıfır günlük bir saldırı ile vurulmuş bir sistemin yönetimine yardım ettim. Muhtemelen MS-RDP'de, güvenlik duvarı tarafından IIS'ye maruz kalmadığımızdan dolayı. Ev sahibimiz RDP portunu değiştirmemize izin vermedi (yönetilen hosting) bu yüzden IDS / IPS filtrelemeleri için yeni bir desen üzerinde çalışırken temelde oraya oturmak zorunda kaldık. Yine de, bazı MS ürünlerinden daha az güvenlik sorunu gibi görünen SSH gibi daha yerleşik sunucular için bu kadar yardımcı olmayabilir.
Matt Molnar

9
Kesinlikle katılıyorum. Güvenlik tamamen katmanlarla ilgilidir ve ne kadar fazlaysanız, o kadar güvende olursunuz. Bu zayıf bir katman olabilir, ancak yine de yine bir katman olabilir. Yalnızca güvenmediği sürece, yalnızca güvenliği artırabilir.
Paul Kroon

1
SSH'yi 22 numaralı bağlantı noktasından hareket ettirmenin diğer bir noktası, büyük miktarda SSH'nin, Fail2Ban'ın zaman zaman değerli CPU zamanları alabileceği gibi hizmetleri denemesidir. Hat donanımının tepesinde önemsiz olabilir, ancak bazı eski sunucular CPU artışlarına neden olabilir. CPU zamanı, hafızası ve bant genişliği ile başka şeyler için de kullanabilirsiniz.
artifex

Aynı şeyi Server 2003'teki RDP ile de yaptım - olay görüntüleyicideki başarısız kimlik doğrulama girişlerinin miktarını büyük ölçüde azalttı.
Moshe

43

Günlükleri temiz tutmak çok yararlıdır.

Eğer 33201 numaralı limanda çalışan sshd ile başarısız girişimler görürseniz, güvenli bir şekilde sizi hedeflediğini varsayabilir ve eğer isterseniz, uygun işlemi yapma seçeneğine sahip olduğunuzu varsayabilirsiniz. Kayıtlı kullanıcılarınızın IP'lerine veya her neyse), vb.

Varsayılan bağlantı noktasını kullanırsanız, birisinin size saldırıp saldırmadığını veya rasgele tarama yapan rastgele salakları bilmek imkansız olacaktır.


8
harika ayrım
ZJR

3
+1 Bu şimdiye kadar duyduğum bağlantı noktası numaralarını değiştirmek için en iyi argüman ve şimdiye kadar beni yapmaya ikna edecek tek şey
squillman

2
+1 Bu harika bir nokta. Hedeflenen tehditler rastgele problardan çok daha tehlikelidir (iyi niyetli bir güvenceniz varsa senaryo çocukları sadece daha kolay hedeflere geçer). Hedeflenen saldırgan belirli güvenlik açıkları ve hatta şifre kalıpları hakkında daha fazla şey biliyor olabilir. Bu saldırıları, 22 numaralı bağlantı noktasındaki spam sürüsü dışında tanıyabilmek güzel.
Steven T. Snyder

1
Bu yanlış. Standart olmayan bir SSH bağlantı noktasındaki bir taramadan en az bir sunucunun güvenliğini tehlikeye soktuğumu gördüm. Bir saldırganın diğer portları da tarayamaması için bir neden yoktur.
Sven Slootweg

@SvenSlootweg, True, özellikle bilgisayarlar daha hızlı ve daha ucuz hale geldiğinde, 65535 kat daha uzun süren bir tarama artık çok daha fazla değildir.
Pacerier

28

Hayır değil. Pek sayılmaz. Bunun terimi Müstehcenlik Güvenliği ve güvenilir bir uygulama değildir. Her iki noktasında da haklısın.

Müstehcenlik ile Güvenlik en iyi ihtimalle sadece bir noktada ön kapıyı açık bırakan birilerini bulabileceklerini bilerek varsayılan liman aramaya başlayan geçici girişimleri engelleyecektir . Ancak, bağlantı noktasını değiştirirken karşılaştığınız herhangi bir ciddi tehdit varsa, ilk saldırıyı en çok yavaşlatır, ancak önceden belirttiğiniz şey nedeniyle ancak bu kadar marjinal olarak.

Kendinize bir iyilik yapın ve bağlantı noktalarınızı doğru şekilde yapılandırın, ancak uygun bir güvenlik duvarı, yetkilendirmeler, ACL'ler vb. İle kilitleme önlemlerini alın.


17
(Güçlü) parolaların ve şifrelemenin gizlilik yoluyla güvenlik fikrine yansıtılması, biraz alçakgönüllü görüşüme göre bence ...
squillman 19

5
Tam alfabetik ve sayısal karakterlerle (ve özel karakterlere izin vermeyen) yalnızca 8 karakter kullanıldığında, olası kombinasyonların sayısı 62 ^ 8'dir (218,340,105,584,896). 65535, liman tarama dedektörlerini kullanırken bile, aynı evrende bile değil. Not, zayıf şifreler indirim yapıyorum.
squillman

3
Yine , "standart dışı liman bütün güvenlik cihazı gibi değil". Her küçük yardımcı olur. Başka bir şey olmazsa, sunucunuzun kapıları çalmaya başlamak için SSH arayan birini göstermesini durduracak 10 saniyelik bir ayar.
ceejayoz

8
Meh. Standart dışı portları takip etmek kitabımda buna değmez. Kimseye katılmamayı kabul edeceğim ... Limanı değiştirmenin ötesinde başka önlemler de kesinlikle denklemin bir parçası ve ben de işleri bulmacanın parçalarına bırakmayı tercih ederim.
squillman

6
Gördüğüm kadarıyla standart dışı limanlar oldukça standart hale geldi. Ssh için 2222, HTTP için 1080, 8080, 81, 82, 8088. Aksi takdirde, çok belirsizleşir ve 7201 numaralı bağlantı noktasında hangi hizmetin olduğunu ve neden 7102'de ssh ile bağlantı kuramadığınızı merak ediyorsunuz.
BillThor

13

Hafif bir gizlilik düzeyidir, ancak saldırıya çıkma yolunda önemli bir hız artışı yok. Belirli bir hizmetle konuşan her şeyin farklı liman hakkında anlatılması gerektiğinden, uzun vadeyi desteklemek daha zor bir yapılandırma.

Bir zamanlar ağ solucanlarından kaçınmak iyi bir fikirdi, çünkü bunlar sadece bir port taramaya meyilliydi. Ancak, hızla çoğalan solucanın zamanı şimdi geçmiş.


2
Zor yapılandırma ve destek sorunu için +1. Kapıyı korumak için harcayabileceğiniz zamanınızı boşa harcar (evinizde nereye koyduğunuzu aramak yerine).
Macke

12

Diğerlerinin de belirttiği gibi, liman numarasının değiştirilmesi size çok fazla güvenlik sağlamaz.

Bağlantı noktası numarasını değiştirmenin güvenliğiniz için zararlı olabileceğini de eklemek isterim.

Aşağıdaki basitleştirilmiş senaryoyu hayal edin. Bir kraker 100 ana bilgisayarı tarar. Bu ev sahiplerinin doksan dokuzu bu standart limanlarda hizmet veriyor:

Port    Service
22      SSH
80      HTTP
443     HTTPS

Ama sonra kalabalığın arasından sıyrılan bir ev sahibi var, çünkü sistem sahibi hizmetlerini şaşırtmaya çalıştı.

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

Şimdi, bu bir kraker için ilginç olabilir, çünkü tarama iki şey önerir:

  1. Ana bilgisayarın sahibi, bağlantı noktası numaralarını sistemlerinde gizlemeye çalışıyor. Belki de mal sahibi, sistemde değerli bir şey olduğunu düşünüyor. Bu bir fabrika çıkışı sistemi olmayabilir.
  2. Sistemlerini güvence altına almak için yanlış yöntemi seçtiler. Yönetici, deneyimsiz bir yönetici olabileceğini belirten liman gizliliğine inanmakla hata yaptı. Belki uygun bir güvenlik duvarı veya uygun bir IDS yerine liman gizliliği kullandılar. Başka güvenlik hataları da yapmış olabilirler ve ek güvenlik saldırılarına karşı savunmasız olabilirler. Şimdi biraz daha ileri araştıralım mı?

Bir kraker olsaydınız, standart portlarda standart servisler yapan 99 ana bilgisayara mı yoksa port gizleme kullanan bir ana bilgisayara mı bakmayı tercih ederdiniz?


14
Tecrübe bana aksini öğretmediyse 99 ev sahibine bakardım. Bana sorarsanız, liman etrafında dolanan birisinin muhtemelen yama ve güvenlik olasılığı daha yüksektir.
ceejayoz

4
Bazı PFY'nin "Port numaralarını değiştirirsem, INVINCIBLE!" Deme ihtimaline karşı öne çıkan 1 konağa bakarım. ancak root şifresi "password" olarak ayarlanmış.
Andrew,

3
@Ceejayoz, tamamen katılıyorum. SS22'yi 2222'de çalıştırıyorum, güvenlik değeri yok ama senaryo çocuklarını azaltma yolunda. Beni de görmezden gelmelerinin daha muhtemel olduğunu, limanı değiştirmekten rahatsız olduklarını, muhtemelen başka önlemler de aldıklarını düşünürdüm. Açıkçası hepsi varsayılan konfigürasyon değil ...
Chris S

1
Anladığım kadarıyla herkes benim görüşüme uymuyor. Ancak deneyimlerime göre, liman gizliliği kullanan birçok sistem sahibi vardı, ancak bazı kritik güvenlik açıklarına maruz kaldıktan sonra OpenSSH'yi güncelleme ya da paylaşılan bir üniversite sisteminden şifrelenmemiş SSH anahtarlarını kullanma gibi hatalar yapacaktı. bu sistemler sulu hedeflerdi.
Stefan Lasiewski

3
Ek olarak: standart olmayan bir limana geçerek, senaryo çocuklarını cesaretini kırma olasılığınız daha yüksektir, fakat aynı zamanda deneyimli bir bilgisayar korsanının ilgisini çekebilirsin. Hangisi soruyu soruyor: Hangisini daha çok hedef aldığınızdan korkuyorsunuz?
tardate

9

En azından kısmen genel eğilime karşı gideceğim.

Kendi başına , farklı bir limana geçmek, aranırken size birkaç saniye kazandırabilir, bu nedenle size gerçek anlamda hiçbir şey kazanamayabilirsiniz. Bununla birlikte, standart dışı bağlantı noktalarının kullanımını portscan karşıtı önlemlerle birlikte birleştirirseniz, güvenlik açısından gerçekten önemli bir artış sağlayabilir.

Sistemlerim için geçerli olan durum şudur: Halka açık olmayan hizmetler standart dışı bağlantı noktalarında yürütülmektedir. Belirli bir süre içinde başarılı bir şekilde olsa da, tek bir kaynak adresinden ikiden fazla bağlantı noktasına yapılan herhangi bir bağlantı girişimi, söz konusu kaynaktan gelen tüm trafiğin azalmasına neden olur.

Bu sistemi yenmek için ya şans (bloke edilmeden önce doğru kapıya vurmak) ya da diğer önlemleri tetikleyen dağıtılmış bir tarama ya da dikkat edilmesi ve üzerinde durulması gereken çok uzun bir zaman gerekir.


Bunu, Andreas Bonini'nin hedeflenen saldırılarla ilgili noktasıyla birleştirin ve alternatif bağlantı noktalarını kullanmak için güçlü bir argümandır.
JivanAmara

5

Bence bir uygulamanın çalıştığı bağlantı noktasını taşımak, yalnızca aynı uygulamanın farklı bir bağlantı noktasında (aynı güçlü ve zayıf yönleriyle) çalışmasından dolayı güvenliği artırmaz. Uygulamanızın dinlediği bağlantı noktasını farklı bir bağlantı noktasına hareket ettirmekte güçsüzlük varsa, zayıflığı ele almaz. Daha da kötüsü aktif olarak sizi zayıflığa ÇALIŞTIRMAMIZA sizi cesaretlendirir çünkü artık otomatik tarama ile sürekli çarpılmamaktadır. Çözülmesi gereken problem olan asıl sorunu gizler .

Bazı örnekler:

  • "Günlükleri temizler" - O zaman günlüklerinizi nasıl kullandığınızla ilgili bir sorun yaşarsınız.
  • "Bağlantı ek yükünü azaltır" - Ek yük ya önemsizdir (çoğu tarama olduğu gibi) ya da işlem sırasında yapılan bir tür filtreleme / Hizmet Reddi azaltma işlemine ihtiyacınız var
  • "Bu, uygulamanın maruz kalmasını azaltır" - Uygulamanız otomatik tarama ve sömürmeye dayanamıyorsa, uygulamanızın ele alınması gereken ciddi güvenlik eksiklikleri vardır (ör. Yamalı!).

Asıl mesele idari: İnsanlar SSH'nin 22'de, MSSQL'in 1433'de olmasını bekliyorlar. Bunları hareket ettirmek, bir karmaşıklık katmanı ve gerekli belgelerdir. Bir ağa oturmak ve nmap'ı sadece işlerin nereye taşındığını bulmak için kullanmak çok can sıkıcı. Güvenliğe eklemeler en iyi şekilde geçicidir ve olumsuz taraflar önemsiz değildir. Yapma Asıl sorunu düzelt.


2

Çok fazla güvenlik getirmeyeceği konusunda haklısınız (TCP sunucu bağlantı noktası aralığının yalnızca 16 bit entropisi olduğundan), ancak bunu iki nedenden ötürü yapabilirsiniz:

  • Diğerlerinin de söylediği gibi: çok sayıda giriş yapmayı deneyen davetsiz kişiler, günlük dosyalarınızı karıştırır (tek bir IP'den gelen sözlük saldırıları fail2ban ile engellenmiş olsa bile);
  • SSH , güvenli bir tünel oluşturmak için gizli anahtarlar değiş tokuş etmek için ortak anahtar şifrelemesine ihtiyaç duyar (bu, normal şartlar altında çok sık yapılması gerekmeyen pahalı bir işlemdir); tekrarlanan SSH bağlantıları CPU gücünü boşa harcayabilir .

Not: Sunucu portunu değiştirmeniz gerektiğini söylemiyorum. Bağlantı noktası numarasını değiştirmek için sadece makul nedenleri (IMO) açıklıyorum.

Bunu yaparsanız, diğer tüm yöneticilere veya kullanıcılara bunun bir güvenlik özelliği olarak değerlendirilmemesi gerektiğini ve kullanılan bağlantı noktası numarasının bir sır olmadığını ve bunu bir güvenlik özelliği olarak tanımladığını açıkça belirtmeniz gerektiğini düşünüyorum. Bu gerçek güvenliği sağlayan kabul edilebilir bir davranış olarak kabul edilmez.


Günlük dosyaları, uygun filtrelerle kolayca derinden çıkarılabilir. Günlüklerin azalması nedeniyle sunucu performansından bahsediyorsanız, artık güvenlikten söz etmiyoruz. Performans tamamen farklı bir konudur.
Pacerier

Aşırı disk kullanımı nedeniyle bilgisayar kullanılamaz hale geldiğinde olmaz.
curiousguy

Evet bu bir performans sorunu. Performans da kesinlikle önemlidir, ancak bu konu özellikle sadece güvenlikle ilgili tartışmaktadır. (Bu
konunun

1

Sshd'nizi alternatif bağlantı noktasında çalıştırmada olası bir güvenlik avantajının olacağı varsayımsal bir durum görebiliyorum. Bu, çalıştırdığınız sshd yazılımında önemsiz şekilde sömürülmüş bir uzaktan güvenlik açığının keşfedildiği senaryoda olacaktır. Böyle bir senaryoda, sshd'inizi alternatif bir bağlantı noktasında çalıştırarak rastgele bir arabayla atılma hedefi olmamanız için gereken süreyi size verebilir.

Kendimi sshd'yi özel makinelerimdeki alternatif bir bağlantı noktasında çalıştırıyorum, ancak bu esas olarak /var/log/auth.log dosyasındaki yığılmayı engellemek için bir kolaylık. Çok kullanıcılı bir sistemde, yukarıda sunulan küçük varsayımsal güvenlik avantajının, standart kısımda bulunmayan sshd'den kaynaklanan ekstra güçlük için yeterli neden olduğunu düşünmüyorum.


Senaryo yalnızca tüm yöneticiler kesinlikle öğle yemeğine ve diğerlerine gitmek için bu "fazladan" sürenin hiçbir
yerinde kalmayacaksa geçerli olacaktır

1

Güvenliği biraz arttırır. Bunun için açık limanı bulan saldırganın limanda neyin çalıştığını hesaplaması gerekir. Config dosyalarınıza erişemiyorsa (henüz :-)) 12345 numaralı bağlantı noktasının http, sshd veya başka bir ortak hizmetten mi çalıştığı hakkında hiçbir fikri yok, bu nedenle ciddi olarak çalışabilmeleri için neyin çalıştığını anlamak için fazladan bir çalışma yapmaları gerekir. Saldır.

Ayrıca, diğer afişlerin işaret ettiği gibi, 22 numaralı limana giriş yapmaya çalışırken, ipucu olmayan senaryolar, zombi truva atları ve hatta bir IP adresini yanlış yazan gerçek kullanıcılar olabilir. 12345 numaralı bağlantı noktasına giriş yapma girişiminin, gerçek bir kullanıcı veya ciddi bir saldırgan olduğu kesindir.

Diğer bir strateji birkaç "bal tuzağı" portuna sahip olmaktır. Hiçbir gerçek kullanıcı bu port numaralarını bilmediğinden, herhangi bir bağlantı girişiminin kötü niyetli olduğu düşünülmelidir ve rahatsız edici IP adresini otomatik olarak engelleyebilir / bildirebilirsiniz.

Farklı bir port numarası kullanmanın sisteminizi daha güvenli hale getireceği özel bir durum var. Ağınız bir Web Sunucusu gibi bir kamu hizmeti kullanıyor ancak aynı zamanda yalnızca bir iç kullanım web sunucusu kullanıyorsa, farklı bir bağlantı noktası numarasında çalışarak ve bu bağlantı noktasından herhangi bir dış erişimi engelleyerek herhangi bir dış erişimi kesinlikle engelleyebilirsiniz .


~% 0,1'lik güvenlik artışı, ilgili güvenlik azalmasına karşı tartılmalı ve muhtemelen kullanım durumuna ve içeriğe bağlı olarak güvenlikte toplam net zarar meydana gelmelidir .
Pacerier

0

Tek başına değil. Ancak, belirli bir uygulama için varsayılan bağlantı noktasını kullanmamak (örneğin, SQL Server), saldırganınızı bağlantı noktalarınızı taramaya zorlar; Bu davranış daha sonra güvenlik duvarınız veya diğer izleme ölçütleriniz tarafından algılanabilir ve saldırganın IP'si engellenebilir. Ayrıca, ortalama "script kiddie", kullandıkları basit araç veya komut betiği makinenizde bir SQL server örneği bulamadığında daha büyük bir olasılıkla caydırılır (çünkü araç sadece varsayılan portu kontrol eder).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.