SSH erişimine izin verirken SCP'yi önlemek mümkün müdür?

Solaris ve Linux sunucuları ve OpenSSH kullanarak, kullanıcıların "ssh" ile kabuk erişimine izin verirken "scp" kullanarak dosya kopyalamasını engellemek mümkün müdür?

'Ssh $ server "cat file"' tipi dosya erişimlerinin engellenmesinin çok daha zor olduğunun farkındayım, ancak yeni başlayanlar için "scp" yi durdurma hakkında bir şeyler görmeliyim.

Başarısız olursa, sunucu tarafında tüm SCP erişimini güvenli bir şekilde günlüğe kaydetmenin bir yolu var syslogmı?

Buna /etc/ssh/sshd_configbenzer bir şeye bakmak için düzenleyebilirsiniz :

ForceCommand           /bin/sh
PermitOpen             0.0.0.0
AllowTcpForwarding     no
PermitTunnel           no
# Subsystem sftp       /usr/lib/openssh/sftp-server
PermitUserEnvironment  no

Bunun yerine kullanıcının ne için kullanacağını belirlerim. Çünkü erişmelerini istediğiniz birkaç komut varsa, bunun yerine normal bir sshkabuk bile çağırma yeteneğini kaldırırım .

AllowUsers             root
PermitRootLogin        forced-commands-only

PermitUserEnvironment  no

AllowTcpForwarding     no
PermitTunnel           no

# Subsystem sftp       /usr/lib/openssh/sftp-server
Subsystem smb-reload   /usr/bin/smbcontrol smbd reload-config
Subsystem status       /opt/local/bin/status.sh

ssh root@example -s smb-reload

Gerçekten normal bir mermi çalıştırmanız gerektiğini fark ederseniz, en çok umabileceğiniz şey onları yavaşlatmak ve daha zor hale getirmektir.

Diğerlerinin de belirttiği gibi, scp'yi engelleyemezsiniz (iyi, şunları yapabilirsiniz: rm /usr/bin/scpancak bu sizi gerçekten hiçbir yere götürmez).

Yapabileceğiniz en iyi şey, kullanıcıların kabuğunu sınırlı bir kabuğa (rbash) değiştirmek ve ancak o zaman belirli komutları çalıştırmaktır.

Dosyaları okuyabilirlerse, ekrandan kopyalayıp yapıştırabileceklerini unutmayın. İkili dosyalar? xxd / uuencode / mmencode hepsi bu sorunu çözer.

Etkinliği izlemenize yardımcı olması için süreç muhasebesini kullanmanızı da öneririm.

Tam anlamıyla sonsuz sayıda dosya aktarım mekanizmasına izin verirken "scp" yi durdurarak hiçbir şey kazanmazsınız. SCP'ye izin vermemek, ancak dosyaları kopyalamak için diğer mekanizmalara izin vermek denetçilere yalan söylemek için bir yöntemdir. Genellikle denetçiler yalan söylenmesini ister. Genellikle sahte düzeltmeler yapmak için yöneticilerle çalışan denetçilerin, "scp dosya aktarım komutu devre dışı bırakıldığını, böylece dosyaların scp kullanılarak sunucudan kopyalanamadığını" belirtebileceklerini görüyorum.

Şimdi makul bir kayıt mekanizması iyi olurdu. Belki denetim nihayet Linux üzerinde çalışır. Belki Solaris nihayet bir mekanizma veya dtrace güvenle kullanılabilir ekledi. Bir dosyaya her erişildiğinde işletim sisteminin günlüğe kaydedilmesini istemek mantıklıdır. Elbette "okuma" ve "kopyalama" arasında bir fark yoktur. Ancak bu bir denetçiyi tatmin edebilir ve sisteme önemli bir güvenlik sağlayabilir. Günlükleriniz o kadar gürültülü olabilir ki veriler işe yaramaz, hatta gülünç derecede kısa bir denetim izi tutmak zorunda kalırsınız. (örn. her read () 'ı günlüğe kaydedemezsiniz ve şaşırtıcı bir şey yapan bir uygulama her open () günlüğünü bir felaket haline getirebilir).

SSH'nin ne için gerekli olduğuna bağlı olarak, paket boyutu daha büyükse (örneğin 1400 bayt) oturumları sonlandırmak için IPTable'ları kullanarak bu hedefe (önemsiz olmayan) dosyaları elde edebilirsiniz. Bu, etkileşimli ssh'nin çoğunlukla işe yarayacağı anlamına gelir, ancak bir şey 1500 baytlık bir paket göndermeye çalıştığında, standart bir MTU 1500 varsayarak 1499 bayttan daha büyük bir dosya için bağlantıyı sonlandıracaktır.

Bu, bahsettiğiniz "catting" saldırısını da engelleyecektir.

Ne yazık ki bu, ekranın 1400 karakterden fazla çizmesi gerekiyorsa veya uzun bir dosyaya katlanmak veya uzun bir dizin listesi yapmak istiyorsanız, bazı dosyaları metin düzenleyicisiyle düzenlemekte sorun yaşayabileceğiniz anlamına gelir.

En basit durumda, bunu yapmak için bir komut şöyle görünebilir:

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff -j DROP

Paket uzunluğu kontrollerini ipt_recent ile birleştirerek bu işi daha iyi hale getirebiliriz, böylece belirli bir zaman aralığında 1400 bayttan daha fazla sayıda sınırlı pakete izin verirsiniz (5 saniyede 8 paket diyelim) - bu, 12k'ye kadar olan paketlerin kaymasına izin verir aracılığıyla, ancak dosyaları vb. düzenlemek için ihtiyacınız olan etkileşimi verebilir. Tabii ki, paket sayısını değiştirebilirsiniz.

Bu şuna benzeyebilir

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --set 
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --update --seconds 5 --hitcount 8 \
         -j REJECT --reject-with tcp-reset

Yukarıdaki kural örnekleri yalnızca gibi scp yüklemelerine karşı koruma sağlar scp myfile.data remote.host:~. Ayrıca gibi scp indirmeleri karşı korumak için scp remote.host:~/myfile.data /local/path, yukarıdaki kurallara tekrarlamak ancak onların yerini --dportile --sport.

Dikkatli bir bilgisayar korsanı, makinesinde 1400'den daha az bir MTU ayarlayarak (veya mtu veya benzeri bir kuvvetle) bu sınırlamalar üzerinde çalışabilir. Ayrıca, bunu belirli kullanıcılarla sınırlayamazken, iptables hatlarını uygun şekilde değiştirerek IP ile sınırlandırabilirsiniz !!

Şerefe David Go

En iyi seçeneğiniz scp'yi kilitlemek değil, okuma erişimini önlemek için ACL'li bir dosya sistemi kullanmaktır. Bazı uygulamaların belirli dosyalardan okunmasını önlemek için SELinux ile bir şeyler yapabilirsiniz.

Hayır scpve sshaynı bağlantı noktaları ile çalışan ve aynı protokolü kullanır. Bir sshoturum açarsanız, bağlantınızı aşağıdaki seçenekleri kullanarak sonraki scp çağrılarıyla bile paylaşabilirsiniz ControlMaster.

İnsanların belirli dosyaları makineden kopyalamasını istemiyorsanız, onlara makineye herhangi bir kabuk erişimi vermemelisiniz.

Etkileşimli ssh'yi devre dışı bırakmak ve scp'ye izin vermek için kabuk olarak 'scponly' kullanmanın bir yolu var, ancak ters yönde çalışan mevcut hiçbir şeyin farkında değilim.

Tersini gerçekleştirmek için scponly kabuğu hack keşfetmek keşfedebilirsiniz.

Bu aslında küçük bir googling sonrasında mümkün değildir.

Bu tartışmaya göz atın: http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Değeri ne olursa olsun, ticari ürün CryptoAuditor , bağlantıyı MITM yaparak ve derin paket denetimi kullanarak SSH üzerinden dosya aktarımlarını kontrol edebildiğini iddia ediyor . Açıkçası hiçbir çözüm kopyalama + yapıştırma, uuencode / kod çözme, FISH , vb. Güvenli değildir . Güzel bir şey şeffaf olmasıdır (olası sertifika hatalarının yanı sıra); SSH bağlantısının her iki ucuna yüklenecek aracı yazılımı ve yapılandırılacak portal / proxy yoktur.

Ürünü ben kullanmadım, bu yüzden YMMV.

Makineyi tamamen yararsız bırakmak için pek çok sistem yardımcı programını kaldırmadan dosya aktarımını engellemek imkansızdır. Dosya içeriklerini stdout'a gösterebilen her şeyden ve stdin'sini stdout'a yazabilen her şeyden kurtulmanız gerekir ve bunların hepsini kaldırdığınızda, kabuk erişimine izin vermenin bir anlamı kalmaz. hiç.

Bu yüzden bunun yerine günlük alternatifinize odaklanacağım:

Hemen hemen her dağıtımda yer alan ve komut dosyası olmayan bir program var ve bu programın kurulumu kolay olmayan programlara yüklenmesi kolay. Bir kabuktan gelen tüm girdi ve çıktıları, isteğe bağlı olarak zamanlama verileriyle kaydeden bir oturum kaydedicidir, böylece yeniden oynatılabilir ve tıpkı bunu yaparken kullanıcının omzunun üzerinden izlediğiniz gibi görünebilir. (Yine de% 95, bazen hemşireler söz konusu olduğunda çıktıyı salgılar, ancak çok sık değildir.)

Kılavuz sayfası, sistemin giriş kabuğu olarak ayarlanması için talimatlar içerir. Günlüklerin kullanıcının yalnızca silemeyeceği bir yere gittiğinden emin olun (yalnızca ek dosya sistemi özniteliği (chattr ile ayarlanabilir) bunun için yararlı olabilir. ACL'ler veya komut dosyalarını inotify gibi)

Bu, kullanıcıların dosyaları sistemden kopyalamasını engellemez, ancak hangi kullanıcılar tarafından ve ne zaman yapıldığını gözden geçirmenize izin verir. Baypas yapmak muhtemelen imkansız değildir, ancak baypas neredeyse kesinlikle günlüklere dönüşür, böylece tam olarak ne olduğunu gizlemeyi başarsalar bile en azından birinin iyi olmadığını biliyorsunuzdur.

Sunucudaki openssh istemcilerini (veya eşdeğerini) kaldırabileceğinize inanıyorum.

Ben scp istemcisi scp sunucu üzerinde scp çağırır veri kopyalarken böylece sunucuda scp kurtulmak, o zaman iyi olmalı.

$ scp bla server:/tmp/
...
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.utf8
debug1: Sending env LANG = en_US.utf8
debug1: Sending env XMODIFIERS = @im=ibus
debug1: Sending env LANGUAGE = en_US.utf8
debug1: Sending command: scp -v -t /tmp/
bash: scp: command not found
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
lost connection