Komut satırı güvenlik hileleri [kapalı]

Komut satırı ve komut dosyası tehlikelidir. Rm -rf ile küçük bir yazım hatası yapın ve incinmiş bir dünyadasınız. Prod dosyasını bir içe aktarma komut dosyası çalıştırırken veritabanının adıyla karıştırın ve siz de kemiklisiniz (aynı sunucudalarsa, bu iyi değil, ama olur). Çok geç fark ettiğin için, yazdığın sunucu adının bazı komutları kullandıktan sonra düşündüğün gibi olmadığını fark ettin. Delik Hawg'a saygı duymalısın .

Riskli komutları çalıştırmadan önce birkaç ritüelim var - bulunduğum sunucuyu üçlü olarak kontrol etmek gibi. İşte rm güvenliği ile ilgili ilginç bir makale .

Hangi küçük ritüeller, araçlar ve püf noktaları sizi komut satırında güvende tutar? Ve "ilk çalıştırma ls foo * 'gibi objektif şeyler, bunun çıktısına bakın ve sonra rm -rf foo * veya bunun gibi birşeyi çalıştırmaktan kaçınmak için rm -rf ile değiştirin; komut yapacağım ".

İyi çalışan bir ürün prod / staging / test sunucuları için kabuğunuzda farklı arka plan renkleri kullanmaktır.

Başlamadan önce aklınızda bir plan yapın.

• Derhal silmek yerine bir dosyayı / dizini sıkıştırın
• (cisco) yönlendiricisini 'x' dakika sayısı içinde yeniden başlatmaya ayarlayın ve hemen 'wr' yapmayın
• Değiştirdiğiniz arayüzün, sisteme girdiğiniz arayüz olmadığından emin olun. Bu, telnet yaptığınız router arayüzü veya VNC'nin ethernet portu olabilir.
• Asla 'root' olarak giriş yapmayın
• yedekleme yapmak. Bunun iyi olup olmadığını kontrol edin. bir tane daha yap.
• güvendiğiniz birisine sorun 'Ben burada aptal bir şey yapmak üzereyim?'

Bunlardan bazıları için düşük teknolojili bir çözümüm var.

Aşağıdakileri yapma konusunda köklü bir alışkanlık geliştirdim (root olarak çalışmayı planlarken):

• Önce normal bir kullanıcı olarak giriş yapın, sonra root'a sudo su - rootgeçmek için kullanın. Bunu zihinsel bir hazırlık olarak yapıyorum, bana zihinsel olarak çok tehlikeli bir bölgeye girdiğimi ve her zaman tetikte olmamı ve korumamda olduğumu hatırlatıyor. Kulağa komik gelince, bu küçük ritüel tek başıma, dikkatsiz olamayacağımı güçlendirerek beni bir ton kederden kurtardı .
• Her komut yazılır, ancak [Geri Dön] tuşuna asla basılmaz. Hiçbir zaman .
• Hiçbir komut edilir hiç anlamadan idam aynen ne yaptığını. Bunu ne yaptığını bilmeden yapıyorsanız , sisteminizde Rus ruleti oynuyorsunuz .
• [Return] tuşuna basmadan önce , CLI'ye çarpmış olan komut gözle dikkatlice incelenir. Herhangi bir tereddüt, potansiyel sorun herhangi bir ipucu varsa, tekrar incelenir. Eğer bu tereddüt devam ederse, komut satırda bırakılır ve man-sayfalarına bakmak için F-2'yi başka bir konsola yönlendiririm.
• Ortak kullanıcı şimdiye teslim edilir sudo, benim sistemlerinde değil , çünkü ben bir BOFH değilim , fakat hazırlık ve eğitim olmadan, bu bir maymun dolu bir silah vererek gibidir. İlk başta eğlenceli ve eğlenceli, maymun namluya bakıp sıkıncaya kadar ...

Rm kullanırken her zaman cdönce dizine gidiyorum , sonra ./dizinin doğru olduğundan emin olmak için bir ön ek kullanın.

cd /usr/some/directory ; rm ./targetfile

veya dosyanın tüm yolunu belirtiyorum

rm /usr/some/directory/targetfile

Bu bir PITA ama ... üzgünümden daha güvenli.

Bu, Windows Powershell'e özgüdür.

İlke olarak, her sunucuda makine profile.ps1'yi izleyerek ekleriz. Bu, aşağıdakilerin doğru olmasını sağlar:

1. Yönetici powershell konsol pencerelerinin koyu kırmızı bir arka plan rengi vardır
2. Yönetici başlığa eklendi
3. "Uyarı: Powershell, Yönetici olarak çalışıyor" mesajı. başlangıçta yazılır
4. Başlık çubuğuna "Yönetici:" ekli
5. Standart yardımcı programlar (şirket kabuğu komut dosyaları, vim ve infozip gibi) yolundadır.

$ currentPrincipal = Yeni Nesne Security.Principal.WindowsPrincipal ([Security.Principal.WindowsIdentity] :: GetCurrent ())
& {
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Yönetici))
    {
        (Get-konak) .UI.RawUI.Backgroundcolor = "DarkRed"
        clear-konak
        yazma ana bilgisayarı "Uyarı: PowerShell Yönetici olarak çalışıyor.`
    }

    $ utilities = $ null
    if ([IntPtr] :: size * 8 -eq 64)
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
        $ utilities = "$ {env: programfiles (x86)} \ Yardımcı programlar"
    }
    Başka
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x86)"
        $ utilities = "$ {env: programfiles} \ Yardımcı programlar"
    }
    if ((Test-Path $ utilities) -ve! ($ env: path -match $ utilities.Replace ("\", "\\")))
    {
        $ env: path = "$ utilities; $ {env: path}"
    }
}

İşlev İstemi
{
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Yönetici))
    {
        if (! $ host.UI.RawUI.WindowTitle.StartsWith ("Yönetici:"))
        {$ Host.UI.RawUI.WindowTitle = "Yönetici:" + $ host.UI.RawUI.WindowTitle}
    }
    'PS' + $ (eğer ($ nestedpromptlevel -ge 1) {'>>'}) + '>'
}

Yukarıdaki tüm cevaplara katılıyorum ancak bu çok, çok önemli bir ipucunu vurgulamalıyım:

Çoklu görevden ne zaman kaçınacağınızı bilin.

Bulunduğum sistemin ana bilgisayar adının bash (veya başka bir kabuk) isteminde olduğundan emin olun. Eğer chroot'luysam, bunun bir şekilde orada olmasını da sağlarım.

Bir keresinde başka bir canlı Linux dağıtımı içinden bir Gentoo sistemi kuruyordum ve yanlışlıkla rmyanlış bir komut verdim (ATM'nin ne olduğunu hatırlayamadım ), yanlış bir kabuğa yanlış bir şekilde koydum ve canlı sistemde bir sürü şey olmasına neden oldum . chroot içindeki öğeler yerine silindi. Ondan sonra hep yaptım

export PS1="(chroot) $PS1"

ne zaman bir chroot içinde çalışıyordum.

Sunucu değişikliği yapmadan önce dikkat edilmesi gereken birkaç önemli şey vardır :

• Doğru sunucuda olduğumdan emin ol

• ** Bu eylemden kaç kişinin etkileneceğini * unutmayın (bir hata yaparsanız veya yapmazsanız)

• 'Enter' tuşunu yazmadan önce, geri alma ihtimalinin farkında olun.

• Kendinize bu komutun oturumunuzu kesme potansiyeli olup olmadığını sorun (fw kuralı, hatalı kapatma, vb ...). Geri dönecek bir yük devretme aracı olduğundan emin olun (özellikle şehir dışındaysanız)

Eğer yapmadıysanız, zaten rm -i

Kural 1 - yedekleme yapın

Kural 2 - ASLA standart komutlara "molly guard" sarmalayıcıları eklemeyiniz, kendi versiyonunuzu yapmayınız, elbette, ancak adı devralmayınız, sadece kurmadığınız bir sistemde sizi ısırır.

Kök için farklı renk ve (kısmi) dizin ağacı gibi hileci istemi büyük yardımcıları, ancak yine, onlarsız çalışabilmenizi sağlar.

Bu, karşı sezgisel ve daha az zor olabilir, ancak sahip olduğum en iyi komut satırı güvenlik ipucu: Bir GUI modu alternatifi mevcut ve pratikse, BT KULLANIN .

Niye ya? Oldukça basit. GUI kipinde genellikle "uyarı - freeblefrop'u sarmak üzeresin, bunu yapmak istediğinden emin misin?" Şeklinde yerleşik bir güvenlik ağı vardır. Olmasa bile, sizi yavaşlatır, düşünme zamanı için daha fazla yer sağlar. Seçenekleri belirlemeden önce seçenekleri daha kolay kontrol etmenizi sağlar, durumlardan önce ve sonra ekran görüntüsünü alabilir, sizi yazım hatalarından korur; hepsi iyi, faydalı ve faydalı şeyler.

Korkunç "rm -rf" nin klasik durumunda, yanlışlıkla bir GUI'den veya bir CLI'dan vermenin daha kolay olduğunu düşünüyor musunuz?

Sonunda, GUI'ye başvurmakta utanılacak bir şey yok. Büyük felaketleri istemez şekilde engellemez; GUI'de CLI'de olduğu gibi tetikten mutlu olmak da mümkün; ama eğer seni bir kez kurtarırsa, kendini değerli buldu.

Sağduyu kullanın ve anlamadığınız komutları çalıştırmayın. Hepsi iyi tavsiye. Rm'ye ilettiğiniz her şeyin mutlak yolunu yazmakla kendinizi acı çekmek veya sudo ile bir şey çalıştırmak gibi hissetmek istiyorsanız, çekinmeyin. O zaman su -c'yi tercih ederim. En azından şifreyi önbelleğe almıyor. Parola doğrulaması yapmadan herhangi bir normal kullanıcının kök ayrıcalıklı şeyleri çalıştırmasına izin verilmesi beni rahat ettirmez.

İşleri biraz daha güvenli hale getirmek için ~ / .bashrc'nize yerleştirebileceğiniz birkaç şey vardır, örneğin:

alias srm='rm -i'

Güvenli bir alternatif rm almanıza izin vermek, ...

Ama sonunda, her zaman berbat edebilirsin ve edeceksin. Geçen gün bir feshedilmiş config betiği vardı / usr / bin klasörümün tamamını chown, birkaç şey kırdım. Evet, içinde herhangi bir yazılım bulunan ve içinde herhangi bir hata bulunan basit bir 'make install' sisteminizi bozabilir. Asla güvende değilsin, ne yaparsan yap. Ne elde edeceğim, en önemli şey:

Düzenli yedeklemeler al.

Rm -i rm yerine rm -i yerine, diğer adının kaldırılması veya daha güvenli olması gerektiğini söylemek (ve bunları tercih ettiğiniz silme aracı olarak kullanmak) daha iyi olmaz mıydı. Daha sonra bu kurulmamış bir kutu kullandığınızda, hiçbir hasar yapılmaz.

Ne yaptıklarını tam olarak anlamadığınız sürece çevrimiçi bulduğunuz komutları asla çalıştırmadığınızdan emin olun.

Sisteminiz posterinkinden farklı olabilir ve bu bir incinme dünyasına neden olabilir.

Unix / Linux perspektifinden komut satırı güvenliği için bariz olanı, kök hesabın doğru kullanılmasıdır.
Root gibi bir rm -rf, bir kullanıcı olarak genellikle daha tehlikelidir ve root olarak oturum açmak yerine sudo gibi yerleşik şeyler kullanmak hayati önem taşır. Hoş ve basit bir whoami, şizofreni ya da çoklu kişilik için genellikle yardımcı olacaktır.

Bu ve herhangi bir filechanging komutuna yankı hazırlamak, özellikle bir glob veya regex eşleşmesinin doğru olduğundan emin olmak istiyorsanız.

Üzerinde çalıştığınız makine ile ikincil bir bağlantı kurmak, ilk oturumunuzu kesmeniz veya makineyi kilitleyen ... ağır işlemler vb.

Bu şekilde hala makineye erişiminiz olur ve birincil oturumunuzu öldürebilirsiniz.

Yukarıdaki yorumların çoğu rm'ye atıfta bulunur, ancak diğer komutlarla da aptalca şeyler yaptım ...

ifconfig ağı ele geçirmek için - bu, düzeltmek için fiziksel bir varlık gerektirir.

Betik yazarken genellikle iki pencerede çalışıyorum. İlk olarak senaryoyu yazmak için kullanıyorum, ikincisi ise her satırı yazarken denemek için. Yavaş ve dikkatli gitmek, kodun yazdığı gibi her satırın çalıştığından, aynı değişkenleri korumamıza özen gösterdiğinden emin olabilirim.

Şahsen, rm -i gibi şeyler için fazladan yardım istemiyorum. Hatalarımın çoğunu, v. Yorgun, stresli vb. Durumlarında yapıyorum, ki bu, sadece yıprandığım ve istemi görmezden geldiğim zamanlar. Belki de kötü bir uygulama.

Bash kullanıyorsanız, şunu deneyin:

TMOUT=600

senin içinde /root/.bashrcveya benzerinde. 10 dakika sonra otomatik olarak oturumunuzu kapattığınızda, yanlışlıkla açık bıraktığınız bir kök terminale dönme ve aptalca bir şeyler yazma olasılığınızı azaltır.

Evet, root komutlarını yürütmek için sudo kullanmanız gerektiğini biliyorum - bu bir gün riskli oynamaya karar vermeniz durumunda ekstra bir güvenlik ağıdır.

# Allow only UPDATE and DELETE statements that specify key values
alias mysql="mysql --safe-updates"`

MySQL CLI kullanıyorsanız, çevresinde olması şiddetle tavsiye edilen bir takma ad.

Ls yerine echo kullanıyorum, böylece kabuk her şeyi genişlettikten sonra komutun tamamını görebiliyorum. Ayrıca, dosyaları temsil eden değişkenleri daima çift tıklatın, böylece öğeleriniz sekmeler veya boşluklar olabilecek dosya adları ile çalışır.

Ben önlemek *mümkün olduğunca kendi argüman olarak topak. Gerçekten "bu dizindeki her şeyi kaldır" anlamına gelsem bile daha belirgin olmaya çalışıyorum, yani. rm *.php. Yanlışlıkla aynı komutu başka bir dizinde geçmişin dışında çalıştırmam durumunda önleyici hasar kontrolü.

Yaptıklarınızı düşündürmenin harika bir yolu, kökünün bashrc'sine (cshrc, her neyse) böyle bir şey eklemek:

unset PATH

Bu şekilde, sadece "rm" yerine / bin / rm yapmanız gerekir. Bu ekstra karakterler sizi düşündürebilir.

Karmaşık regex için, özellikle 'find' komutları, ekoyu öne koyar ve bunları bir dosyaya kaydeder. Ardından, 'source' ile dosyayı çalıştırmadan önce tam olarak ne düşündüğünüzü / silmeyi / etc / etc gerçekten sildiğinizi kontrol edebilirsiniz.

Regex'in almadığı kenar kutusunu manuel olarak eklemek için de kullanışlıdır.

Diğer yazıların bir kısmı için biraz meta: Komutun istediğim dosya setini seçtiğinden veya kabuk tarafından istenildiği gibi yorumlandığından emin olmak için ilk önce önerilen echo / ls adımlarını kullanırım.

Fakat daha sonra önceki komutu almak için kabuğun komut geçmişi düzenleme özelliklerini kullanıyorum ve sadece değişken olması gereken parçaları değiştiriyorum .

Bu komutların her birini bağımsız olarak yazmak hiç yardımcı olmuyor ...

$ ls *.bak
$ echo rm *.bak
$ rm * .bak

... çünkü yanlışlıkla son satırda bir boşluk bıraktım ve tüm dosyaları sildim. Her zaman önceki satırı alırdım ve basitçe 'echo' yu kaldırırdım.

root user:
Zorunda olmadıkça root olmayın.
Satıcı, root olarak çalıştırılması gerektiğini söylüyorsa, onlara müşteri olduğunuzu ve root olarak çalıştırılmak istemediğinizi söyleyin.
Raftan kaç tane yazılım paketi 'sadece kolay olduğu için' kök istiyor?

alışkanlık:
asla '*' 'ı asla üç kez bakmadan kaldırmayla kullanmayın ls -l TargetPattern kullanma alışkanlığını geliştirmek , ardından' rm! $ 'kullanın. En büyük tehdit, senin düşündüğün yerde olmamak. Ben neredeyse sık sık 'ls' gibi 'hostname' yazın!

koltuk değneği:
"alias rm = 'rm -i'" gibi takma adlar gibi standart bir bilgi istemi de çok yardımcı oluyor, fakat genellikle üzerinde bulunduğum makineler üzerinde tam kontrolüm olmadığından, yalnızca yolunuzu ayarlamak için bir bekliyor sarmalayıcı komut dosyası kullanıyorum 'istemi, istemi ve takma adları'

sorunları bulun:
tam yol kullanmak yardımcı olur, ancak bunun mümkün olmadığı durumlarda, daha güvenli bir yere cd atın ve ALSO, 'cd' nin bulmanızı, çıkarmanızı, tar, untar'ı yapmadan önce başarılı olmasını sağlamak için '&&' komutunu kullanın. etc:
example: cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
'&&' kullanımı, bu durumda bir tar dosyasının kendi üzerine çıkarılmasını engelleyebilir (bu durumda 'rsync' daha iyi olur)

kaldırır:
özellikle bir komut dosyasında, yardımcı olabilirseniz özyinelemeli bir şekilde asla kaldırmayın. -tip f ve -name 'kalıbı' ile bulun ve kaldırın Hala xargs'e 'hiçbir şey' beslemekten korkuyorum ... tartar ve untar 'ın etrafını hareket ettirmek (yerine rsync kullanın)

Bir işletim sisteminin birden çok varyasyonu kullanırsanız, olmak çok sözdizimi farklılıkların farkında; bir unix varyantında makul olarak güvenli olan, diğerinde son derece tehlikelidir.

Örnek: killall

Linux / FreeBSD / OSX - geçen parametreye uyan tüm işlemleri öldürür. örneğin: "killall apache", diğer bütün işlemleri yalnız bırakarak tüm apelleri öldürür.

Solaris - tüm işlemleri öldürür . Hayır, gerçekten. Gönderen adam sayfası : Killall doğrudan kapatma prosedürü ile ilgili olmayan tüm aktif süreçleri öldürmek için kapatma (1M) tarafından kullanılır.

Yerine

rm foo*

kullanım

rm -i foo*

Bu, bir avuç dolusu dosya ile pratiktir, fakat tam bir tarball ile değildir. Bu yüzden takma ad rmsizin yolunuza girer .

Komutu ilk önce eko ile çalıştırmak iyi bir fikirdir, ancak hala yazım hatası olur.

! $ Gibi bir genişleme ile kullanmayı deneyin.

echo foo*
rm -rf !$

! $, Son komutun son kelimesine genişler, yani

echo foo*
rm -rf foo*

Son argümana tüm argümanlara genişleyen! * De vardır.

Gerçekten, eğer istersen bu şekilde yapabilirsin.

echo rm -rf foo*
!*

(Bash yerine ksh kullanıyorsanız, bunun yerine son kelimeyi eklemek için Esc + nokta yazabilirsiniz.)

Gibi bir şey durumunda:

ls * .php
echo rm * .php
rm * .php

İkame operatörünü şu şekilde kullanabilirsiniz:
$ ls * .php
<dir ranking>

$ ^ ls ^ echo rm (bu, önceki komuttaki ls'yi echo rm ile değiştirir, komut satırının kalanını aynı tutar)

$ ^ echo rm ^ rm (echo rm'yi sadece rm ile değiştirin, böylece * .php yazıp yanlış zamanda boşluğa atmanız gerekmez)

^ = shift-6, aşina olmayanlar için.

Bash kullanın ve PS1 = '\ u @ \ h: \ w>' olarak ayarlayın. Bu, userername @ hostname olarak genişler: / full / working / directory / path> Diğer cevaplarda da belirtildiği gibi, .profile veya .bash_profile dosyalarını güncelleyemiyorsanız, giriş yaptığınız zaman ortamı ayarlamak için kullanabilirsiniz. Arka plan renklerini değiştirmek kolayca :-) en iyi cevaptır

Ah evet. O yaş eski hileli birine "-rf" adında IRC'ye bir dosya gönderme hilesiyle ~ dizininde bitiyor. Daha sonra bir küçük "rm -rf" ("rm - -rf" yerine) ve IRC'yi root olarak çalıştırmama konusunda sert bir ders aldıklarında kahkahalar atıldı.

Bunun yerine kullanmanın rm -rf <dir>koymak -rfşöyle sonunda: rm <dir> -rf. Amacınızı kullandıktan sonra ve ateş etmeden önce güvenliği ortadan kaldırmak olarak düşünün. Bu şekilde, dizin adını yazarken (veya sekme tamamlama özelliğini kullanarak) enter tuşunu kaybederseniz ve benzer şekilde adlandırılmış dizinlere sahipseniz korunmuş olursunuz.