Ben bir programcıyım ve ağları 22 numaralı bağlantı noktasında giden bağlantıları engelleyen birkaç istemci için çalıştım. Programcıların ssh için genellikle 22 numaralı bağlantı noktasını kullanmaları gerektiği göz önüne alındığında, bu bir ters üretim prosedürü gibi görünüyor. En iyi ihtimalle, programcıları şirketi 3G İnternet için faturalandırmaya zorlar. En kötüsü, işlerini etkili bir şekilde yapamayacakları anlamına gelir.
Bunun yarattığı zorluklar göz önüne alındığında, deneyimli bir sistem yöneticisi, kaybetme-kaybetme eylemine benzeyen şeyin istenen faydasını açıklayabilir mi?
Kimsenin SSH port yönlendirme ile ilgili riski ayrıntılı olarak açıkladığını görmüyorum.
Bir güvenlik duvarının içindeyseniz ve genel internetteki bir makineye giden SSH erişimine sahipseniz, bu genel sisteme SSH gönderebilirsiniz ve bu süreçte, genel internetteki kişilerin ağınızdaki bir sisteme tamamen erişebilmesi için bir tünel oluşturabilirsiniz. güvenlik duvarını atlayarak.
Fred masaüstünüz ve barney şirketinizde önemli bir sunucuysa ve wilma herkese açıksa (çalışıyorsa)
ssh -R *: 9000: barney: 22 wilma
ve giriş yapmak, bir saldırganın ssh üzerindeki 9000 numaralı bağlantı noktasını ve barney'in SSH arka plan programı ile konuşmasını sağlayacaktır.
Güvenlik duvarınız bunu asla gelen bir bağlantı olarak görmez, çünkü veriler başlangıçta giden yönde kurulan bir bağlantıdan geçirilir.
Bu sinir bozucu, ancak tamamen meşru bir ağ güvenliği politikası.
Bağlantı noktalarının bir karışımını engelliyorlarsa, bazı şeyleri rastgele içeriyorlar ve rastgele başka şeyleri engelliyorlarsa (Paul Tomblin'in SSH'yi engelleyen ve Telnet'e izin veren insanların üzücü masalını seviyorum) o zaman ya ağ çevresini korumaya ya da güvenlik politikalarına en azından dışarıdan bakıldığında kötü düşünülmüş. Böyle durumları anlayamazsınız, bu yüzden onlara acı çeken ve gününüze devam eden insanlar için gidişat ücretini talep edin.
TÜM bağlantı noktalarını engelliyorlarsa bu bağlantı noktasından trafiğe izin vermek için belirli bir iş durumu yoksa, bu noktada dikkatli bir şekilde yönetilir o zaman bunu işlerinde yetkin oldukları için yapıyorlar.
Güvenli bir uygulama yazmaya çalışırken, diğer işlemlerin bilgileri istedikleri gibi okumasını ve yazmasını kolaylaştırıyor musunuz yoksa insanların aramasını beklediğiniz ve dikkatlice dezenfekte ettiğiniz birkaç dikkatle belgelenmiş API'nız var mı?
Risk yönetimi - ağınıza veya İnternet'ten giden trafiğin bir risk olduğunu düşünüyorsanız, hem rota sayısı hem de yöntem sayısı açısından trafiğin İnternet'e erişme yollarını en aza indirmeye çalışırsınız. Daha sonra, bu "kutsanmış" ağ geçitlerini ve bağlantı noktalarını izleyebilir ve filtreleyebilirsiniz.
Bu bir "varsayılan reddet" güvenlik duvarı politikasıdır ve genellikle iyi bir fikir olarak kabul edilir. Bunun anlamı, engelini kaldırmak için belirli bir neden olmadığı sürece her şeyin engellenmesi ve nedenin faydaları risklerden daha ağır basar.
Edit: Açıklığa kavuşturmak gerekir, ben sadece izin bir protokolün izin ve başka bir bloke riskleri hakkında konuşmak değil, kontrolsüz bir ağ içine veya dışına akmasına izin veri iş potansiyel riskleri hakkında konuşuyorum yol.
Şimdi uyarılar ve muhtemelen bir şeyleri özgürleştirme planı:
Bazı müşterilerinizle birlikte bulduğunuz konum olan bir şeyden engellendiğinizde can sıkıcı olabilir. Çoğu zaman, güvenlik duvarından sorumlu insanlar, işlerinin "İşte riskler, şimdi faydaları nelerdir, ne yapabileceğimizi görelim" yerine "Hayır" demeyi düşünüyorlar.
Müşterileriniz için ağ güvenliğini kim yönetirse konuşursanız, bunlar sizin için bir şey ayarlamaya uygun olabilir. Sonunda birkaç belirli sistemi tanımlayabiliyorsanız ve/veya yalnızca belirli bir IP adresinden bağlanacağınızı garanti ederseniz, bu belirli koşullar için SSH bağlantıları için bir güvenlik duvarı istisnası oluşturmaktan çok daha mutlu olabilirler. sadece tüm internete bağlantılar açmak olacaktır. Veya güvenlik duvarından tünel açmak için kullanabileceğiniz bir VPN tesisine sahip olabilirler.
Ben orada çalışırken, ancak izin telnet! Bunu sorduğumda, ssh'ın bir güvenlik deliği olduğunu söylediler.
Başka bir deyişle, şirketler bazen aptalca kararlar alırlar ve daha sonra hatalarını kabul etmek yerine güvenlikle ilgili bahane mazeretler oluştururlar.
Şirket harici girişlere izin vermiyorsa gelen SSH iletişimini engellemeyi anlayabilirim. Ancak, ilk kez bir giden SSH bloğunu duydum.
Dikkat edilmesi gereken önemli olan, bu tür güvenlik duvarlarının muhtemelen sadece sıradan SSH kullanıcılarını sınırlayacağıdır. Birisi gerçekten SSH'yi dışarıda istiyorsa (tipik olarak kurumsal ağın dışında önemli bir erişimi olan bir sunucuya/makineye olacaktır) SSH sunucusunu 22 dışında bir bağlantı noktasında (örneğin, bağlantı noktası 80) kolayca çalıştırabilir. Blok kolayca atlanacak.
Kuruluştan HTTP üzerinden çıkmanıza izin veren (bağlantı noktası 80 veya HTTPS bağlantı noktası 443) ve dış bağlantı noktası 22'ye bağlanmanıza izin veren proxy'ler sağlayan birkaç genel etki alanı aracı da vardır.
Düzenleme: Tamam, bir saniye, neden bu bir politika olabilir bir fikrim var.
Bazen insanlar, IM ve Bittorrent gibi protokoller için temel giden güvenlik duvarlarını atlamak için SSH tünellerini kullanırlar (örneğin). Bu // belki // böyle bir politikayı tetiklemiş olabilir. Bununla birlikte, hala bu tünel araçlarının çoğunun 22 dışındaki limanlarda çalışabileceğini hissediyorum.
Bu tür giden tünellerin engellenmesinin tek yolu, SSH iletişimini anında algılamak ve (dinamik olarak) bu TCP bağlantıları) engellemektir.
Bence giden port 22'yi engellemenin iki temel nedeni var.
Birincisi, insanların belirttiği gibi, SSH bağlantı noktası yönlendirmesi, bu tür trafiğin izin verilmediğini belirten BT politikasından kaçınmak için diğer bağlantı noktaları ve hizmetler etrafında proxy olarak veya baypas olarak kullanılabilir.
İkincisi, birçok kötü amaçlı yazılım/botnet 22 numaralı bağlantı noktasını kullanır, çünkü genellikle "güvenli" olarak görülür ve bu nedenle izin verilir. Daha sonra işlemleri bu bağlantı noktasından başlatabilir ve virüslü bilgisayarlar SSH kaba kuvvet saldırıları da başlatabilir.
Muhtemelen bir düzenleme/uyumluluk sorunudur. İşvereniniz tüm iletişimi okuyabilmek/arşivleyebilmek istiyor. Bu genellikle bankacılık gibi sektörlerde bir gerekliliktir.
Müşterileriniz muhtemelen saklamak istedikleri önemsiz verilere sahip. Giden SSH, tüm ağa açık olması gerçekten kötü bir şeydir. Proxy'leri atlamak, hassas verileri sızdırmak ve genellikle iğrenç olmak oldukça önemsizdir.
IMO, ağ/internet çevresinden geçen her şey anlaşılmalı ve kontrol edilebilir olmalıdır. Bir grup geliştiricinin ssh üzerinden bir barındırma sağlayıcısında sunuculara erişmesi gerekiyorsa, bu iyi - ancak belgelenmesi gerekir. Genel olarak çalıştığım yerlerde, ağımızın dışındaki yerlere özel olarak siteden siteye VPN bağlantıları kurarız (esas olarak iç ağımızı genişletiriz) ve internet üzerinden SSH gibi istemci protokollerinden kaçınırız.
Çoğu zaman, gerekmedikçe tüm giden bağlantıları engelleme durumudur ve denemediğiniz sürece kimse 22 numaralı bağlantı noktasının giden bağlantılar için kullanılabilir olmasını istememişti (sadece 80, 433, vb.). Bu durumda çözüm, IS/IT ile iletişim kurmak ve onlara neden bir istisna eklemeye ihtiyacınız olduğunu söylemek kadar basit olabilir, böylece istasyonunuz belirli ana bilgisayarlara veya genel olarak giden SSH bağlantıları yapabilir.
Bazen insanlar, SSH'yi diğer kontrolleri atlatmak için vekilleri (bağlantı üzerinden bağlantı noktası iletme yoluyla) kurmanın bir yolu olarak kullanmak için tesisi kullanabilirler. Bu, tüm iletişimin yasal nedenlerle izlenmesi/kaydedilmesi gereken bazı düzenlenmiş endüstrilerde (yani bankalar) çok önemli bir faktör olabilir (içeriden öğrenenlerin ticaretini engellemek, kurumsal veya kişisel verilerin aktarımını tespit etmek/engellemek vb.) iç sızıntıların yanlışlıkla veya başka şekilde ticari sırlar vermesine neden olan büyük bir korkudur. Bu gibi durumlarda 3G bağlantınızı (veya SSH'yi HTTP üzerinden tünellemeye çalışmak gibi diğer teknikleri) kısıtlamaları aşmak için kullanmak sözleşmenizi ihlal edebilir ve bu nedenle görevden alınma suçu (veya muhtemelen daha kötüsü yasal bir suç) olabilir. denemeden önce eyleminizi kabul ettirin.
Başka bir neden, şirket tarafından çalıştırılan bir makineye kendini kurması için istenmeyen bir şeyin başa çıkması durumunda, giden ayak izini azaltmak (şirket güvenlik duvarları ve genel olarak dünya için erişilebilir olan dahili hizmetlere) olabilir. Bağlantı noktası 22'de SSH bağlantısı yapılamıyorsa, yayılma yollarından biri engelleneceğinden kaba kuvvet SSH oturumlarını kullanmayı deneyen daha basit hack'ler engellenir. Bu durumda, bu bağlantılar güvenlik duvarlarını kontrol eden kişilere haklı gösterilebiliyorsa, makinenizin SSH bağlantıları yapabilmesi için bir istisna eklenmesini tekrar isteyebilirsiniz.
Çünkü SSH bir VPN olarak kullanılabilir. Şifrelenir, böylece ağ yöneticileri ağlarından ne çıktığı konusunda hiçbir fikre sahip değildir (müşteri veritabanının dökümü vb.). Bunları aylık sütunumda ele aldım "Gizli Tüneller" . Bazı 3G internetin maliyeti, ağdan verilerinizi kanalize eden şifreli protokoller hakkında endişelenmek zorunda kalmadan çok daha az bir heck. Ayrıca, giden bağlantı noktası 22'yi varsayılan olarak engeller ve trafik denetimi yaparsanız, standart olmayan bağlantı noktalarında SSH'yi kolayca bulabilir ve böylece güvenlik politikasını ihlal eden kişileri bulabilirsiniz.
Açık yanıtların hepsi belirtildi. Yetkisiz iletişim kanallarının (ters proxy) oluşturduğu tehdidin yanı sıra tünellerin oluşturulması yoluyla politikayı atlatmak için kullanılabilecek şifreli bir protokoldür (bu, kurumsal web filtrelerini aşmanın harika bir yoludur).
Doğru, telnet herhangi bir modern ağda yok edilmelidir. Ancak, ssh'yi yasaklarken telnet'in ağdan çıkmasına izin verdiğini görebiliyorum. Telnet ssh'den daha az kapasiteye sahiptir ve akışı her zaman gerçek zamanlı olarak algılayıcılarım aracılığıyla izleyebilirim. Çekirdek ağımda herhangi bir telnet cihazım yoksa ve bazı kullanıcılar telnet yapmak istiyorsa ne umurumda. Görebilir ve bunun bir tehdit olmadığını doğrulayabilirim.
Elbette, tüm bunlar varsayılan politikanın tüm çıkışları engellemek ve sadece belirli protokollere izin vermek olduğu fikrine bağlıdır. Onları Edge'den önce vekaleten bonus puanları.
SSH aracılığıyla bir SOCKS proxy'si kurma ve böylece bazı site kısıtlamalarını atlatma yeteneklerini kötüye kullanan birkaç kişi tanıyorum.
Hatta bazı basit bağlantı noktası yönlendirme (
ssh -L ....), bağlantı noktası site kısıtlamaları nedeniyle gerçekten engellenmişse, şu konuma giderdim:
onları bir masaya getirin ve bunun neden engellendiğini detaylandırın. Tabii ki, dahili bir ürün geliştirmek için harici bir SSH bağlantı noktasına erişmeniz için iyi nedenlere sahip olmanız gerekir (dahili varlık: Bir şirket için çalışırken snakeoil.invalid adresinde neden boxA.example.com sitesine erişmeniz gerekiyor?
Ancak henüz SSH'yi engelleyen bir şirket görmedim :)
Açıkça, ağ yöneticileri SSH trafiğini belirli engellemek için ciddi ve ciddi çabalar göstermedikçe, giden bir TCP/22 bloğunu atlatmak kolaydır. Dahası, varlık yöneticilerinin 3G modemleri ve 2. NIC'lerde şüpheli IP adreslerini yakalamak için yeterli varlık envanterini çalıştıracak kadar topa sahip olmaları gerekir. Bölgemizde ClearWire hizmetimiz var, bu yüzden ağ güvenliğimiz etrafında bir son çalıştırma seçeneği olarak WiMax bile var.
Biz büyük ölçüde bilgi kaçağıyla ilgilenen bir kurum değiliz. Fakat biz olsaydık, acımasız bir ağ güvenliği politikasını acımasız bir varlık politikasıyla ve denetimle birleştirmemiz gerekirdi. Bildiğim kadarıyla, bir tür harici ağ bağlantısı ile envanter oluşturan bir varlığın ağ jakını kapatacak bir hazır güvenlik paketi olduğunu düşünmüyorum. Bu geliyor olabilir.
Böyle bir paketin yokluğunda, varlık-envanter süreci 3G veya WiMax gibi bir son çalıştırma ağ bağlantısını yakalamanın en iyi yollarından biridir.
Ve son olarak, TCP/22'nin kör olarak engellenmesi, yalnızca çalışma ağları için AUP'yi ihlal etme niyetinde olan son kullanıcıların en az wiley'i engelleyecektir.
Ben 22 millet 22 üzerinden http trafik yönlendirdiğini keşfettiklerinde bloke gördüm. İhtiyacımız olanlar için bir gösteri tıpa oldu ama org zeminde durdu.
Çoğu büyük kuruluş her şeyi engeller ve yalnızca proxy sunucu üzerinden HTTP/HTTPS erişimine izin verir.
Belirli bir ihtiyaç olmadıkça, masaüstü veya sunuculardan doğrudan harici bağlantılara izin veren herhangi bir şirketi duymak çok şaşırırdım.
Hiçbir şey uzak sshd'nizi bağlantı noktası 80'de çalıştırmanızı engellemez. Hem ssh hem de sshd'nin bağlantı noktasını ayarlamak için -p seçeneği yoktur.
Tabii ki, yöneticileriniz akıllıysa, sadece 22 numaralı trafiği değil, ssh trafiğini de izlemelidir. Yani, bir teknik probleminiz değil, bir politika probleminiz var gibi görünüyor.
Diğerlerinin de belirttiği gibi, şifreli protokoller çeşitli uyum sorunları hakkında endişelenmek zorunda olan insanlarda mide ekşimesine neden olabilir.
Bağlantı noktası 22'yi özel olarak engelleyen bir durum değildir, çünkü yöneticilerin SSH'ye karşı bir şeyleri vardır, daha çok sadece açık olmaları gerektiğini bildikleri bağlantı noktalarını açma durumudur. Yöneticinize SSH'nin açık olması gerektiği söylenmediyse, yöneticiniz bunu sunucuda kullanılmayan hizmetleri devre dışı bırakmak için geçerli olan prensip ile engelleyecektir.