Sztuczki bezpieczeństwa wiersza poleceń [zamknięte]

Wiersz poleceń i skrypty są niebezpieczne. Zrób małą literówkę za pomocą rm -rf i jesteś w świecie bólu. Pomyl prod ze sceną w nazwie bazy danych podczas uruchamiania skryptu importu i zostaniesz bez kości (jeśli są na tym samym serwerze, co nie jest dobre, ale się dzieje). To samo dotyczy zauważania zbyt późno, że nazwa serwera, z którego korzystasz, nie jest taka, jak myślałeś, po uruchomieniu niektórych poleceń. Musisz szanować Hole Hawg .

Mam kilka małych rytuałów przed uruchomieniem ryzykownych poleceń - takich jak potrójne sprawdzenie serwera, na którym jestem. Oto ciekawy artykuł na temat bezpieczeństwa RM .

Jakie małe rytuały, narzędzia i sztuczki zapewniają bezpieczeństwo w linii poleceń? Mam na myśli obiektywne rzeczy, takie jak „najpierw uruchom ls foo *, spójrz na wynik tego, a następnie zastąp ls rm -rf, aby uniknąć uruchomienia rm -rf foo * lub czegoś takiego”, a nie „upewnij się, że wiesz, co polecenie zrobi ".

Jednym, który działa dobrze, jest używanie różnych kolorów tła w powłoce dla serwerów prod / staging / test.

Zanim zaczniesz, miej na uwadze plan wycofania się.

• Spakuj plik / katalog zamiast usuwać go od razu
• ustaw router (cisco), aby uruchomił się ponownie w „x” liczbie minut i nie „wr” od razu
• upewnij się, że interfejs, który zmieniasz, nie jest tym, w którym wszedłeś do systemu. Może to być interfejs routera, do którego telnet zostałeś podłączony, lub port Ethernet VNC.
• nigdy nie loguj się jako „root”
• zrób kopię zapasową. sprawdź, czy to dobrze. zrobić kolejny.
• zapytaj kogoś, komu ufasz „Czy mam zamiar zrobić tutaj coś głupiego?”

Mam na niektóre z nich mało zaawansowane rozwiązanie.

Rozwinąłem nawyk wykonywania następujących czynności (podczas planowania pracy jako root):

• Najpierw zaloguj się jako zwykły użytkownik, a następnie użyj, sudo su - rootaby przełączyć się na root. Robię to jako przygotowanie mentalne, przypomnienie mi, że mentalnie wszedłem w bardzo niebezpieczny obszar i że powinienem być cały czas czujny i uważny. To zabawne, jak się wydaje, sam ten rytuał uratował mi mnóstwo żalu, po prostu wzmacniając, że nie mogę być nieostrożny .
• Każde polecenie jest wpisane, ale klawisz [Return] nigdy nie jest wciśnięty. Nigdy .
• Żadne polecenie nigdy nie jest wykonywane bez zrozumienia , co dokładnie robi. Jeśli robisz to, nie wiedząc, co robi, grasz w rosyjską ruletkę za pomocą swojego systemu.
• Przed naciśnięciem klawisza [Return] polecenie, które zostało wydane w interfejsie CLI, jest dokładnie sprawdzane wzrokowo. W przypadku wahania, śladu potencjalnego problemu, jest on ponownie rozpatrywany. Jeśli wahanie się powtarza, polecenie pozostawia się w wierszu, a ja wciskam klawisz F-Alt do innej konsoli, aby przejrzeć strony podręcznika itp. W sesji graficznej uruchamiam przeglądarkę i szukam.
• Żaden wspólny użytkownik nigdy nie jest przekazywany sudona moje systemy, nie dlatego, że jestem BOFH , ale dlatego, że bez przygotowania i szkolenia, to jest jak oddanie załadowanej broni małpie. Na początku jest zabawnie i zabawnie, dopóki małpa nie spojrzy w beczkę i nie wyciska ...

Korzystając z rm, zawsze cdnajpierw zaczynam od katalogu, a następnie używam przedrostka, ./aby upewnić się, że katalog jest poprawny, tj

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

lub podaję pełną ścieżkę do pliku

rm /usr/some/directory/targetfile

który jest PITA, ale ... lepiej bezpieczny niż przykro.

Ten jest specyficzny dla Windows Powershell.

Jako zasadę dodajemy następujący profil maszyny.ps1 na każdym serwerze. Dzięki temu spełnione są następujące warunki:

1. Okna konsoli administracyjnej PowerShell mają ciemnoczerwony kolor tła
2. Administrator został dodany do tytułu
3. Komunikat „Ostrzeżenie: Powershell działa jako administrator”. jest napisany przy starcie
4. Pasek tytułu jest poprzedzony „Administrator:”
5. Na ścieżce znajdują się standardowe narzędzia (takie jak skrypty korporacyjne, vim i infozip).

$ currentPrincipal = New-Object Security.Principal.WindowsPrincipal ([Security.Principal.WindowsIdentity] :: GetCurrent ())
I {
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        (get-host) .UI.RawUI.Backgroundcolor = "DarkRed"
        wyczyść hosta
        write-host "Ostrzeżenie: PowerShell działa jako administrator`n"
    }

    $ utilities = $ null
    if ([IntPtr] :: size * 8 -eq 64)
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
        $ utilities = "$ {env: programfiles (x86)} \ Utilities"
    }
    jeszcze
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x86)"
        $ utilities = "$ {env: programfiles} \ Utilities"
    }
    if ((Test-Path $ utilities) -i! ($ env: path -match $ utilities.Replace ("\", "\\")))
    {
        $ env: path = "$ utilities; $ {env: path}"
    }
}

funkcja Podpowiedź
{
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        if (! $ host.UI.RawUI.WindowTitle.StartsWith („Administrator:”))
        {$ Host.UI.RawUI.WindowTitle = "Administrator:" + $ host.UI.RawUI.WindowTitle}
    }
    „PS” + $ (if ($ nestedpromptlevel -ge 1) {'>>'}) + '>'
}

Mogę się zgodzić z wszystkimi powyższymi odpowiedziami, ale muszę podkreślić tę bardzo, bardzo ważną wskazówkę:

Wiedz, kiedy unikać wielozadaniowości.

Upewniam się, że nazwa hosta systemu, w którym pracuję, jest wyświetlana w wierszu polecenia bash (lub innej powłoki). Jeśli jestem chrootowany, upewniam się, że to też tam w jakiś sposób się pojawi.

Kiedyś instalowałem system Gentoo z innej dystrybucji Linuksa na żywo i przypadkowo uruchomiłem dość destrukcyjne polecenie (nie pamiętam, co to był ATM - jakaś odmiana rm) w niewłaściwej powłoce, powodując wiele rzeczy w systemie na żywo usunięte, a nie rzeczy z chroot. Odtąd zawsze tak robiłem

export PS1="(chroot) $PS1"

ilekroć pracowałem w chroot.

Przed zmianą serwera należy pamiętać o kilku ważnych rzeczach :

• Upewnij się, że jestem na właściwym serwerze

• Pamiętaj, ** ile osób dotknie to działanie * (jeśli popełnisz błąd, czy nie)

• Przed wpisaniem klawisza „enter” należy pamiętać o możliwości cofnięcia

• Zadaj sobie pytanie, czy to polecenie może rozłączyć sesję (reguła fw, złe zamknięcie itp.). Upewnij się, że wróciłeś do trybu failover (szczególnie jeśli jesteś poza siedzibą)

Jeśli jeszcze tego nie zrobiłeś, pseudonim rm to rm -i

Reguła 1 - rób kopie zapasowe

Zasada 2 - NIGDY nie dodawaj opakowań „molly guard” do standardowych poleceń, twórz własną wersję, jasne, ale nie przejmuj nazwy, po prostu ugryzie cię, gdy będziesz w systemie, którego nie skonfigurowałeś.

Monity podpowiedzi, takie jak inny kolor dla katalogu głównego i (częściowego) drzewa katalogów, są świetnymi pomocnikami, ale znowu upewnij się, że możesz bez nich pracować.

Może się to wydawać sprzeczne z intuicją i mniej ardkore, ale najlepszą wskazówką bezpieczeństwa, jaką mam w wierszu poleceń, jest: Jeśli dostępna jest alternatywa w trybie GUI i jest praktyczna, skorzystaj z niej .

Czemu? Całkiem proste. Tryb GUI zwykle ma wbudowaną siatkę bezpieczeństwa w postaci „ostrzeżenia - masz zamiar sflargować freeblefrop, czy na pewno chcesz to zrobić?” Nawet jeśli nie, spowalnia cię, dając więcej miejsca na przemyślenia. Umożliwia łatwiejsze sprawdzenie opcji przed ich zatwierdzeniem, zrzut ekranu przed i po stanie, chroni przed literówkami; wszystkie dobre, przydatne i pomocne rzeczy.

Czy w klasycznym przypadku przerażającego „rm -rf” łatwiej jest przypadkowo wydać go z GUI lub CLI?

Ostatecznie uciekanie się do GUI nie jest wstydem. To nieomylnie zapobiegnie poważnym katastrofom; w GUI jest tak samo możliwe, jak w przypadku wyzwalacza, tak jak w CLI; ale jeśli raz cię uratuje, okazało się, że warto.

Używaj zdrowego rozsądku i nie uruchamiaj poleceń, których nie rozumiesz. To wszystko dobra rada. Jeśli masz ochotę na zadawanie sobie trudu z zapisaniem absolutnej ścieżki wszystkiego, co przekazujesz do rm, lub prowadzeniem czegokolwiek przez sudo, nie krępuj się. Wolałbym wtedy su -c. Przynajmniej nie buforuje hasła. Nie czułbym się dobrze, gdyby zwykły użytkownik mógł uruchamiać rzeczy z uprawnieniami roota bez weryfikacji hasła.

Jest kilka rzeczy, które możesz umieścić w swoim ~ / .bashrc, aby uczynić je nieco bardziej bezpiecznymi, na przykład:

alias srm='rm -i'

Umożliwiając bezpieczną alternatywę dla rm, ...

Ale w końcu możesz i zawsze spieprzysz. Któregoś dnia niedziałający skrypt konfiguracyjny przejrzał cały folder / usr / bin, psując kilka rzeczy. Tak, prosta „instalacja” dowolnego typu oprogramowania z błędem może uszkodzić system. NIGDY nie jesteś bezpieczny, cokolwiek robisz. Chodzi o to, NAJWAŻNIEJSZĄ rzeczą:

Regularnie twórz kopie zapasowe.

Zamiast aliasingować rm do rm -i, czy nie lepiej byłoby, aby alias powiedział usuń lub zabezpieczył (i używał ich jako preferowanego narzędzia do usuwania). Następnie, gdy użyjesz pudełka, które nie zostało skonfigurowane, żadne obrażenia nie zostaną zadane.

Upewnij się, że nigdy nie uruchamiasz komendy znalezionej online, chyba że w pełni rozumiesz, co robią.

Twój system może różnić się od plakatu, co może spowodować ból.

Oczywistym dla bezpieczeństwa wiersza poleceń z perspektywy Uniksa / Linuksa jest prawidłowe użycie konta root.
Rm -rf jako root jest na ogół bardziej niebezpieczny niż jako użytkownik, a korzystanie z wbudowanych rzeczy takich jak sudo zamiast logowania się jako root jest niezbędne. Ładne, proste whoami zwykle pomoże schizofrenii lub wielu osobowościom.

To i wstępne echo do komend zmieniających pliki, szczególnie jeśli chcesz się upewnić, że masz poprawne dopasowanie glob lub regex.

Posiadanie drugiego połączenia z komputerem, nad którym pracujesz, może być przydatne na wypadek, gdybyś zabił swoją sesję podstawową lub zrobił coś głupiego, co ją zablokuje ... ciężkie przetwarzanie itp.

W ten sposób nadal masz dostęp do komputera i możesz zabić swoją podstawową sesję.

Większość powyższych komentarzy odnosi się do rm, ale zrobiłem też głupie rzeczy z innymi poleceniami ...

ifconfig, aby usunąć sieć - ouch, która wymaga fizycznej obecności do naprawy.

Co do skryptów, zazwyczaj pracuję w dwóch oknach. Pierwszy używam do pisania skryptu, drugi do testowania każdej linii podczas jej pisania. Idąc powoli i ostrożnie, mogę upewnić się, że każda linia działa zgodnie z oczekiwaniami, pisząc kod, dbając o zachowanie tych samych zmiennych itp.

Osobiście nie znajduję dodatkowych monitów dotyczących takich rzeczy, jak rm -i naprawdę pomagają. Popełniam większość moich błędów, gdy jestem zmęczony, zestresowany itp., I to są czasy, kiedy po prostu będę walić i ignorować podpowiedź. Być może zła praktyka.

Jeśli używasz bash, spróbuj tego:

TMOUT=600

w twoim /root/.bashrclub podobnym. Wylogowuje cię automatycznie po 10 minutach, zmniejszając ryzyko, że przełączysz się na terminal root, który przypadkowo pozostawiłeś otwarty i wpiszesz coś głupiego.

Tak, wiem, że powinieneś używać sudo do wykonywania poleceń roota - to tylko dodatkowa sieć bezpieczeństwa na wypadek, gdybyś pewnego dnia zdecydował się na ryzykowną grę.

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

Wysoce zalecany alias, który można mieć, jeśli kiedykolwiek użyjesz interfejsu CLI mysql.

Zamiast ls używam echa, dzięki czemu mogę zobaczyć pełne polecenie po rozszerzeniu powłoki przez wszystko. Ponadto zawsze cudzysłowuj zmienne reprezentujące pliki, aby Twoje rzeczy działały z nazwami plików, które mogą zawierać tabulatory lub spacje.

W *miarę możliwości unikam globu jako własnego argumentu. Nawet jeśli naprawdę mam na myśli „usuń wszystko z tego katalogu”, staram się być bardziej konkretny, tj. rm *.php. Jest to zapobiegawcza kontrola szkód na wypadek, gdy przypadkowo uruchomię to samo polecenie z historii w innym katalogu.

Świetnym sposobem na zastanowienie się nad tym, co robisz, jest dodanie czegoś takiego do bashrc root'a (cshrc, cokolwiek):

unset PATH

W ten sposób musisz zrobić / bin / rm zamiast po prostu „rm”. Te dodatkowe postacie mogą sprawić, że pomyślisz.

W przypadku złożonego wyrażenia regularnego, zwłaszcza polecenia „znajdź”, umieszczają echo na początku i przechwytują je do pliku. Następnie możesz sprawdzić, czy naprawdę usuwasz / przenosisz / itp. Dokładnie to, co myślisz przed uruchomieniem pliku za pomocą „źródła”.

Przydaje się również do ręcznego dodawania skrzynek, których regex nie wykrył.

Trochę meta do niektórych innych postów: Używam zwykłych kroków echo / ls zasugerowanych najpierw, aby upewnić się, że polecenie wybiera zestaw plików, które chcę lub w inny sposób są interpretowane przez powłokę zgodnie z przeznaczeniem.

Ale potem używam funkcji edycji historii poleceń powłoki w celu pobrania poprzedniego polecenia i modyfikowania tylko tych części, które muszą się różnić.

Wcale nie pomaga wpisanie każdego z tych poleceń niezależnie ...

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

... ponieważ przypadkowo wpisałem spację w ostatnim wierszu i usunąłem wszystkie pliki. Zawsze pobierałem poprzednią linię i po prostu usuwałem „echo”.

root użytkownik:
nie root, chyba że musisz.
Jeśli sprzedawca mówi, że musi działać jako root, powiedz mu, że jesteś klientem i że chcesz go uruchomić jako użytkownik inny niż root.
Ile pakietów oprogramowania z półki chce rootować „tylko dlatego, że jest łatwiej”?

nawyk:
nigdy nie używaj „*” przy usuwaniu bez patrzenia na to trzy razy Najlepiej jest zbudować nawyk używania ls -l TargetPattern , a następnie użyć „rm! $”. Największym zagrożeniem nie jest bycie tam, gdzie myślisz, że jesteś. I prawie wpisać „hosta” tak często, jak „ls”!

Kule:
standardowy szybka pomaga dużo, jak zrobić aliasy typu „alias rm =«rm -i»”, ale często nie mają pełnej kontroli nad maszynami Jestem na tak mogę używać oczekiwać wrapper script jedynie ustawić ścieżkę , monit i aliasy za pomocą „-i”

znajdowanie problemów:
użycie pełnej ścieżki pomaga, ale w przypadkach, gdy nie jest to możliwe, włóż płytę CD do bezpieczniejszej lokalizacji, a także użyj „&&”, aby upewnić się, że „płytka CD” się powiedzie, zanim zrobisz wyszukiwanie, usuń, tar, rozpakuj, etc:
przykład: cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
użycie „&&” może w tym przypadku zapobiec wyodrębnieniu pliku tar na siebie (chociaż w tym przypadku lepiej byłoby użyć „rsync”)

usuwa:
nigdy nie usuwaj rekurencyjnie, jeśli możesz pomóc, szczególnie w skrypcie. znajdź i usuń za pomocą opcji -type f i -name „wzorzec” Nadal żyję w obawie przed nakarmieniem „niczym” xargs ... tar i untar do przenoszenia rzeczy (zamiast tego użyj rsync)

Jeśli korzystasz z wielu wariantów systemu operacyjnego, być bardzo świadomi różnic w składni; to, co jest względnie bezpieczne w jednym wariancie uniksowym, jest wyjątkowo niebezpieczne w innym.

Przykład: killall

Linux / FreeBSD / OSX - zabija wszystkie procesy pasujące do przekazanego parametru. np .: „killall apache” zabija wszystkie apache, pozostawiając wszystkie inne procesy w spokoju.

Solaris - zabija wszystkie procesy. Nie naprawdę. Ze strony podręcznika man : killall jest używany przez shutdown (1M) do zabicia wszystkich aktywnych procesów niezwiązanych bezpośrednio z procedurą zamykania.

Zamiast

rm foo*

posługiwać się

rm -i foo*

Jest to praktyczne z garstką plików, ale nie z, powiedzmy, całym archiwum. Właśnie dlatego aliasing rmstanie Ci na drodze.

Uruchomienie polecenia z użyciem echa w pierwszej kolejności jest dobrym pomysłem, ale nadal jest podatne na literówki.

Spróbuj użyć go z rozszerzeniem, takim jak! $.

echo foo*
rm -rf !$

! $ Rozwija się do ostatniego słowa ostatniego polecenia, więc jest równoważne z

echo foo*
rm -rf foo*

Istnieje również! *, Który rozszerza się na wszystkie argumenty do ostatniego polecenia.

Rzeczywiście, możesz to zrobić w ten sposób, jeśli wolisz

echo rm -rf foo*
!*

(Jeśli używasz ksh, a nie bash, możesz wpisać Esc + kropka, aby zamiast tego wstawić ostatnie słowo).

W przypadku czegoś takiego jak:

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

Możesz użyć operatora podstawienia, takiego jak:
$ ls * .php
<dir listing>

$ ^ ls ^ echo rm (zamienia ls w poprzednim poleceniu na echo rm, zachowując pozostałą część wiersza poleceń)

$ ^ echo rm ^ rm (zamień echo rm na tylko rm, więc nie musisz wpisywać * .php i wstawiać spacji w niewłaściwym czasie)

^ = shift-6, dla tych, którzy się z tym nie znają.

Użyj bash i ustaw PS1 = '\ u @ \ h: \ w>'. Rozwija się to do nazwy użytkownika @ nazwa_hosta: / full / working / directory / path> Jak wspomniano w innych odpowiedziach, możesz oczekiwać, że skonfigurujesz środowisko przy każdym logowaniu, jeśli nie możesz zaktualizować plików .profile lub .bash_profile. Najlepszym rozwiązaniem jest zmiana kolorów tła :-)

O tak. Ta odwieczna sztuczka polegająca na wysyłaniu komuś pliku przez IRC o nazwie „-rf”, więc trafia on do katalogu ~. Jeden mały „rm -rf” później (zamiast „rm - -rf”) i wiele śmiechu nastąpiło, gdy nauczyli się trudnej lekcji na temat nie uruchamiania IRC jako root.

Zamiast używać rm -rf <dir>umieścić -rfna końcu tak: rm <dir> -rf. Pomyśl o tym jako o usunięciu bezpieczeństwa po celowaniu i przed oddaniem strzału. W ten sposób jesteś chroniony, jeśli masz poślizg klawisza Enter podczas wpisywania nazwy katalogu (lub przy użyciu uzupełniania tabulatorów) i masz podobnie nazwane katalogi.