hacking , linux, serwer , otwarte porty

Był sobie serwer z czystą instalacją.
Otwarte były w 100% porty 22 i 80 - od samego początku INCOMING był akceptowany.
Brak firewalla:

• przez 10 dni port 80 otwarty, żadnej usługi na nim (brak apache2) - nic nie nasłuchiwało
• przez 5 dni port 22 otwarty, brak usługi
• po 6 dniach openssh-server, zaczyna nasłuchiwać, wszystko defaultowo
• po 7 dniach openssh-server zabezpieczony (poszedł skrypt zabezpieczający)
• po 11 dniach zauważyłem, że nie ma firewalla (po prostu zapomniałem wcześniej), instaluję firewall, odrzuca pełno połączeń z Chin, Korei, Rosji (boty)
• apache2 dalej nie ma, ale lada moment będzie, a porty zostaną znowu otwarte

Jestem przekonany, że w ciągu tych 10 dni było pełno "ataków" przez boty. Średnio jest to 15/dzień.
Jeżeli nie było żadnej usługi - np. port 80 był bez apache2 - to mogły coś zrobić, jakoś się dostać?

Jak sprawdzić czy "w środku" nie ma jakiegoś Chińczyka, Rosjanina, Koreańczyka?

Jaki system? Jakie jądro?
Defaultowo linux nie potrzebuje firewall'a.
Otwarty port, czyli co masz na myśli?

Standardowo tcpdump na czystym, szukać icmp dziwnie wyglądających, do tego

rkhunter --update
rkhunter --check-all

chkrootkit

Czarnuch napisał(a):

Jaki system? Jakie jądro?

Jeden z najnowszych debianów stabilnych, nie wiem jakie jądro, ale pewnie coś koło 4.0

Czarnuch napisał(a):

Defaultowo linux nie potrzebuje firewall'a.

czyli jak nie ma nic na routerze (ustawiona DMZ), i nie ma żadnego firewalla (iptables -L wskazuje, że wszystko jest akceptowane), to dalej jest bezpieczny?

Czarnuch napisał(a):

Otwarty port, czyli co masz na myśli?

że wystarczy zainstalować usługę i jest od razu widoczna z zewnątrz, nie trzeba nic otwierać. Po prostu brak ufw. Brak reguł na routerze, a iptables pusta tabela - nic ! Ale też bez usług.

Czarnuch napisał(a):

Standardowo tcpdump na czystym, szukać icmp dziwnie wyglądających, do tego

rkhunter --update
rkhunter --check-all
chkrootkit

bardzo Ci dziękuję, ale już widzę, że trochę czasu to zajmie i ciężko będzie ;/

Dokładnie tak jak napisał programy chrootkit i rkhunter -c do tego masa różnych poleceń w, who , whois, arp czy bardziej konkretne programy.

Jeżeli w jądrze nie masz bugów oraz z portów nic nie korzysta, wtedy pakiet trafia "nigdzie".
Dlatego nie rozumiem jak wywnioskowałeś, że ten port jest otwarty.
Przykładowo jak tworzysz gniazdo połączeniowe, a u Ciebie na maszynie nic nie nasłuchuje to dostajesz info o porcie zamkniętym.

Jak możesz to pokaż co Ci wysypało po tym
ifconfig
nmap -p- localhost
nmap -6 -p- ::1
service --status-all

sprawdz też usługę DNS, może w niej coś siedzi? udp 53

chkrootkit czy tam rkhunter nic specjalnego nie wykryły.

czytam teraz:
https://help.ubuntu.com/community/DoINeedAFirewall
https://dangertux.wordpress.com/2011/10/03/a-firewall-is-not-a-catch-all/

więc tak - definicja "portu otwartego" to jest "port, który ma przypięty usługę nasłuchującą".
A więc jak nie ma żadnej usługi podpiętej do portu, to teoretycznie port jest bezpieczny, pomimo braku firewalla.
Sprawa nie jest taka oczywista, bo jak nie ma firewalla, to można próbować jakieś reverse shelle - i mimo, że porty nie mają usług aktywnych, to nie są i tak bezpieczne (z tego co zrozumiałem z tych dwóch artykułów).

Pytanie jest tylko jedno:
jak bardzo chińsko-koreańskie boty są wyrachowane w tym swoim skanowaniu/sprawdzaniu portów ?
Bo jak są wyrachowane i stosują wszystkie sposoby, to może być niewesoło.

Tak samo zastanawia mnie skąd miały adres IP, skoro serwer żadnej usługi na zewnątrz nie wypuszczał?
Normalnie internet to pole bitwy, ledwo człowiek się wychyli, a już chińsko-koreańsko-ruskie boty atakują!! Jak w jakimś filmie... cyber wojna jest faktem.

Warto abyś zobaczył jak działa metasploit, jak przeprowadza się w nim testy oraz jak używa reverse payloada.
W przypadku, gdy:

1. Nic nie pobrałeś dziwnego, oraz Ty oraz nic w systemie tego nie uruchomiło
2. System jest wolny od nadużyć
   to system jest bezpieczny, firewall nie ma tutaj nic do rzeczy.
   reverse shell jest połączeniem PO ATAKU, gdy ktoś w jakiś sposób wykorzysta istniejącą dziurę do wykonania swojego kodu.

Czarnuch napisał(a):

Warto abyś zobaczył jak działa metasploit, jak przeprowadza się w nim testy oraz jak używa reverse payloada.
W przypadku, gdy:

1. Nic nie pobrałeś dziwnego, oraz Ty oraz nic w systemie tego nie uruchomiło
2. System jest wolny od nadużyć
   to system jest bezpieczny, firewall nie ma tutaj nic do rzeczy.
   reverse shell jest połączeniem PO ATAKU, gdy ktoś w jakiś sposób wykorzysta istniejącą dziurę do wykonania swojego kodu.

oki dzięki, wstępnie wygląda, że niby wszystko jest OK, ale wolę to jeszcze posprawdzać (i przy okazji nauczyć się jak to wszystko jest zbudowane).

Natomiast tutaj jest dosyć skuteczne rozwiązanie problemu anty-bot :
http://www.wizcrafts.net/exploited-servers-blocklist.html
(ostatnia aktualizacja 27 kwietnia 2016 roku)

"I read my raw access logs every day, watching for undesirable activity, such as hacking attempts, from humans and bots; unwanted foreign or privately owned indexing spiders; log and blog spam scripts; content scraping harvesters and last, but not least - proxy servers - that hide the IP of the person, or script, that is requesting access to a web page. (...)"

no i efektem tych działań ma być lista, która blokuje: Chińczyków, Koreańczyków, Ruskich i Nigeria. Generalnie jeżeli nasz serwer ma być tylko "w Polsce", to można doslownie spróbować się odciąć od tego co się dzieje na zewnątrz. Rozwiązanie zaprezentowane w tym linku opiera się na apache2, czyli .htaccess - gość wypisuje po prostu adresy IP (zakresy), które służą bot-netowi.

Nie wiem na ile skuteczne są takie listy, ale wydaje mi się, że też poszedłbym w takim kierunku - na pewno odciął się od Chiny-Rosja-Korea, bo 80% ip bot-netu jest stamtąd.

http://www.cipherdyne.org/fwknop/
http://www.cipherdyne.org/psad/

Na tej stronie reklamują też świetną książkę w temacie.

Jak myślisz o bezpieczeństwie to zamiast httpd zainteresuj się nginx lub innymi alternatywami.

nginx znam, ale raczej idę w kierunku apache2 + poprawne pisanie kodu PHP + firewall + usługi serwerowe wzmacniajace bezpieczeństwo (fail2ban)

apache2 nie jest taki zły, ale trzeba się napracować i dużo rzeczy ustawić.

No i wiele zależy bezpośrednio od PHP - bo tutaj jest cała masa tzw. "dobrych praktyk", które wzmacniają bezpieczeństwo całej serwerowej konstrukcji

Czy to PHP 7 jest bezpieczniejsze od innych nowych technologi!!!

KicjanoKrk napisał(a):

Czy to PHP 7 jest bezpieczniejsze od innych nowych technologi!!!

Z moich obserwacji (możliwe, że niepełnych) wynika, że PHP siedzi na serwerze i całość zabezpieczenia języka serwerowego (back-endowego) wiąże się bezpośrednio z zabezpieczeniem serwera, ale również dobrych praktyk kodu, żeby właśnie nie było możliwości np. SQL Injection

Np. taki wordpress jest dziurawy jak sito - widać to często po komentarzach na blogach, np. często są komentarze od botów, a to oznacza, że taki blog może mieć pełno backdoorów w sobie.

Generalnie pisanie w PHP i umieszczenie czegoś na serwerze dosyć szybko może skończyć się pozostawieniem dziur (luk bezpieczeństwa). Ale można też te dziury załatać i zrobić z tego twierdzę (kwestia doświadczenia)

No i nie liczy się, że tylko "ma działać". Liczy się, że ma "działać szybko, bezpiecznie, funkcjonalnie"

• przez 10 dni port 80 otwarty, żadnej usługi na nim (brak apache2) - nic nie nasłuchiwało
• przez 5 dni port 22 otwarty, brak usługi

W jakim sensie port otwarty, brak usługi? Chodzi o to że port nie jest blokowany przez firewall, ale nic tam nie stoi?

Jestem przekonany, że w ciągu tych 10 dni było pełno "ataków" przez boty. Średnio jest to 15/dzień.
Jeżeli nie było żadnej usługi - np. port 80 był bez apache2 - to mogły coś zrobić, jakoś się dostać?

Jestem przekonany że ataków przez boty było pełno. Ale atakować sobie mogą, jeśli żadna usługa nie stoi to sobie mogą atakować, bo i tak nic nie zrobią (chyba że będzie zeroday bezpośrednio na stack sieciowy linuxa, ale gdyby coś takiego się trafiło to cały internet by zapłonął i tak).

że wystarczy zainstalować usługę i jest od razu widoczna z zewnątrz, nie trzeba nic otwierać. Po prostu brak ufw. Brak reguł na routerze, a iptables pusta tabela - nic ! Ale też bez usług.

Jesli na jakimś porcie nie ma usługi to nie ma znaczenia czy jest firewall czy nie, bo i tak nic się nie połączy. Nie masz sie czego bać tutaj.\

więc tak - definicja "portu otwartego" to jest "port, który ma przypięty usługę nasłuchującą".
A więc jak nie ma żadnej usługi podpiętej do portu, to teoretycznie port jest bezpieczny, pomimo braku firewalla.

Dokładnie

Sprawa nie jest taka oczywista, bo jak nie ma firewalla, to można próbować jakieś reverse shelle - i mimo, że porty nie mają usług aktywnych, to nie są i tak bezpieczne (z tego co zrozumiałem z tych dwóch artykułów).

No nie, to nie o to chodzi. Jesli nie ma portu otwartego, to nikt z nim nic nie zrobi, koniec.

(ostatnia aktualizacja 27 kwietnia 2016 roku)

"I read my raw access logs every day, watching for undesirable activity, such as hacking attempts, from humans and bots; unwanted foreign or privately owned indexing spiders; log and blog spam scripts; content scraping harvesters and last, but not least - proxy servers - that hide the IP of the person, or script, that is requesting access to a web page. (...)"

Dobry pomysł, do takiego 4p idzie kilkaset tysięcy requestów dziennie, już lecę czytać je wszystkie codziennie ;).

no i efektem tych działań ma być lista, która blokuje: Chińczyków, Koreańczyków, Ruskich i Nigeria. Generalnie jeżeli nasz serwer ma być tylko "w Polsce", to można doslownie spróbować się odciąć od tego co się dzieje na zewnątrz. Rozwiązanie zaprezentowane w tym linku opiera się na apache2, czyli .htaccess - gość wypisuje po prostu adresy IP (zakresy), które służą bot-netowi.

Głupie. Przypomina mi trochę jak niedawno w jakimś banku chcieli wprowadzić (wprowadzili?) zasadę mówiącą że nie obsługują ludzi z nakryciem głowy - w domyśle wycelowaną w zamaskowanych przestępców. Niespodzianka - przeszkadzać to będzie wielu normalnym ludziom, a jeśli wejdzie zamaskowany przestępca z pistoletem to może się nie przejąć tym że łamie regulamin ;). Skąd ta analogia - zablokujesz normalnych ludzi z rosji/chin (a co jeśli ktoś jest np. na wakacjach w rosji, etc) - a hackerzy jednak myślę że potrafią używać proxy. Albo TORa.
Ja bym w tą stronę nie szedł, to bardziej security through obscurity niż faktycznie bezpieczeństwo.

edit:
Z rzeczy które możesz zrobić stawiając bezpieczny serwer PHP:

• bycie na bieżąco z aktualizacjami
• jak najmniejsze uprawnienia dla użytkownika na którego prawach działa webserver (brak praw zapisu gdziekolwiek poza jednym folderem z danymi, brak praw odczytu niczego poza webrootem)
• ograniczenie praw do bazy (ale pewnie i tak potrzebujesz prawie wszystkiego, więc to wiele nie da)
• regularne backupy, koniecznie robione w taki sposób że są nie do zniszczenia/zmodyfikowania z poziomu serwera z PHP.
• nie robienie błędów bezpieczeństwa w kodzie PHP :P

ok więc tak.

Po1. Jak serwer nie ma klientów (requestów) spoza Polski - a mój tak nie ma w planach - to można spróbować zablokować.
Rozumiem oczywiście, że może być serwer, który ma requesty spoza Polski, ale nie zawsze tak jest.
Np. póki co nie mam nic wspólnego z Ruskimi, Koreańczykami i Chińczykami - więc na pewno pójdzie blokada po IP.

Atakują nie zwykli ludzie, ale bot-nety, które w tych krajach są rozwinięte. Np. w takich Chinach jest nadal kilkaset milionów komputerów z WindowsemXP - a WindowsXP to siedlisko bot-netu. Mimo wszystko mam zamiar dać te IP do .htaccess - głównie na Azję.

Po2. Ogarniam teraz apparmor - taka dosyć ciekawa aplikacja, która ostro izoluje procesy od systemu. Mniej więcej jest to hardening procesu, a więc proces nagle nie może się wymknąć spod kontroli i ma prawa tylko jakie mu ustalimy. Wstępnie widać, że sporo z tym roboty, ale może gra warta jest świeczki - szczególnie, że są gotowe profile do blokowania tych procesów w necie. Np. sporo ma apache2, a inne usługi serwerowe również mają gotowe profile.
Np. http://www.dickson.me.uk/2010/07/09/security-enhancing-your-ubuntu-lamp-with-apparmor/

Po3. wiem właśnie, ze uprawnienia (ownership, permission) - nawet zobacz jakie dałem tematy ostatnio na 4p:
konfiguracja Apache2, wiele virtual hostów, a zamknięcie portów
symfony2 LTS (lub 3): permissions, owner, ważne ścieżki/foldery
Co chwilę piszę o tych uprawnieniach, bo to trzeba mieć w małym palcu - ale właśnie nie jest to takie oczywiste, bo 1 luka i można przeoczyć jak jakieś uprawnienia są źle ustawione. Co chwilę zastanawiam się czy jeszcze jakiegoś nie poprawić w tym wszystkim co jest, czy nie zejść gdzieś niżej w chmod.

Po4. OPRÓCZ KODU PHP, na Linuxie jest pełno sposobów zabezpieczenia serwera - to pojęcia nazywa się hardening; można tłumaczyć jako "utrudnienie". Np. tutaj wskazówki : http://fm4dd.com/security/apache-hardening-top-ten.htm
Pełno jest tego, każda zastosowana wskazówka "utrudnia" nasz system w płynnej konfiguracji, ale też wzmacnia bezpieczeństwo

Po5. Code review PHP, oddzielna bajka. Ale też samo ulepszanie pakietów na serwerze to za mało, bo prawdopodobnie jak kod niebezpiecznie jest napisany, to ulepszenie pakietów np. PHP nic nie da (wypadałoby przetestować konkretne przypadki).

Po6. Generalnie nie do końca wiadomo co jest w tym całym bot-necie chińsko-koreańskim. Biorąc pod uwagę, że Azjaci mają łeb do hackingu, to może nagle przyjść jakiś bot, który exploituje nam usługę - trzeba się "zabezpieczać" na ile się da, ale nie unikać problemu.

Po1. Jak serwer nie ma klientów (requestów) spoza Polski - a mój tak nie ma w planach - to można spróbować zablokować.
Rozumiem oczywiście, że może być serwer, który ma requesty spoza Polski, ale nie zawsze tak jest.
Np. póki co nie mam nic wspólnego z Ruskimi, Koreańczykami i Chińczykami - więc na pewno pójdzie blokada po IP.

Atakują nie zwykli ludzie, ale bot-nety, które w tych krajach są rozwinięte. Np. w takich Chinach jest nadal kilkaset milionów komputerów z WindowsemXP - a WindowsXP to siedlisko bot-netu. Mimo wszystko mam zamiar dać te IP do .htaccess - głównie na Azję.

Dalej uważam to za zły pomysł, ale jak uważasz. Nie ma nic gorszego niż false positive i zablokowanie dostępu zwykłemu użytkownikowi. A jest masa powodów dla których polak może się łączyć z IP które Twój serwer rozpozna jako zagraniczne (np. rosyjskie).
Security to confidentiality, integrity, availability, accountability - blokując dostęp do całych zakresów IP sam sobie ograniczasz availability (do pewnego stopnia).
Ale jeśli faktycznie jesteś na to zdecydowany to ok, Twój serwer :P. Na pewno faktycznie zmniejszy zakres ataków botów, tylko ideologicznie uważam to za złe podejście do zabezpieczania.

Po2. Ogarniam teraz apparmor - taka dosyć ciekawa aplikacja, która ostro izoluje procesy od systemu. Mniej więcej jest to hardening procesu, a więc proces nagle nie może się wymknąć spod kontroli i ma prawa tylko jakie mu ustalimy. Wstępnie widać, że sporo z tym roboty, ale może gra warta jest świeczki - szczególnie, że są gotowe profile do blokowania tych procesów w necie. Np. sporo ma apache2, a inne usługi serwerowe również mają gotowe profile.

Polecam apparmor jeśli chcesz poważnie zabezpieczać serwer (a widzę że chcesz). Ogólnie im więcej czasu poświęcisz na konfigurowanie go tym lepiej będzie chronił (można każdemu programowi dać tylko to czego dokładnie potrzebuje). Przed sqli Cię nie ochroni (i tak całą bazę będzie można wykraść), ale zawsze może pomóc w zabezpieczaniu usług.

Po3. wiem właśnie, ze uprawnienia (ownership, permission) - nawet zobacz jakie dałem tematy ostatnio na 4p:
konfiguracja Apache2, wiele virtual hostów, a zamknięcie portów
symfony2 LTS (lub 3): permissions, owner, ważne ścieżki/foldery
Co chwilę piszę o tych uprawnieniach, bo to trzeba mieć w małym palcu - ale właśnie nie jest to takie oczywiste, bo 1 luka i można przeoczyć jak jakieś uprawnienia są źle ustawione. Co chwilę zastanawiam się czy jeszcze jakiegoś nie poprawić w tym wszystkim co jest, czy nie zejść gdzieś niżej w chmod.

A faktycznie.

Swoją drogą, odnośnie drugiego tematu:

owner http://serverfault.com/questiolko root-folder?
przy prawach 770 osoby z zewnątrz będą mogły to odczytać? na forach polecają wejście aż na 775:
http://serverfault.com/questio[...]s-chmod-775-safe-to-use/144195

Rany, po co 775. Nie mówię że to złe uprawnienie, ale jeśli chcesz jak najbezpieczniej:
Wszystkie foldery do których aplikacja powinna pisać (sesja, cache, logi, etc): 770 (albo 700)
W zasadzie wszystkie pozostałe pliki (w szczególności pliki .php): 440 (albo 400). Serwer www nie powinien mieć praw do nadpisywania plików php, to ważne.

Po4. OPRÓCZ KODU PHP, na Linuxie jest pełno sposobów zabezpieczenia serwera - to pojęcia nazywa się hardening; można tłumaczyć jako "utrudnienie". Np. tutaj wskazówki : http://fm4dd.com/security/apache-hardening-top-ten.htm
Pełno jest tego, każda zastosowana wskazówka "utrudnia" nasz system w płynnej konfiguracji, ale też wzmacnia bezpieczeństwo

WIem co to hardening :P. Ja bym przetłumaczył jako "hartowanie" jednak.

Jak już przy tym jesteśmy, to możesz jakiś WAF postawić przy okazji - czyli takie coś co automatycznie wykrywa podejrzane requesty i zablokuje je. Też się mu zdarzają false positivy czasami teoretycznie (ale i tak lepszy sposób niż odgórne blokowanie zakresów IP), ale to można monitorować.

Po5. Code review PHP, oddzielna bajka. Ale też samo ulepszanie pakietów na serwerze to za mało, bo prawdopodobnie jak kod niebezpiecznie jest napisany, to ulepszenie pakietów np. PHP nic nie da (wypadałoby przetestować konkretne przypadki)

Nie no, update PHP nic nie da jak będzie SQLi albo inny vuln w kodzie - PHP tylko robi to co się mu każe.
Po prostu instalowanie regularnie security updates to dobry pomysł (nigdy nie wiadomo kiedy wyjdzie vuln na jakąś usługę).

Po6. Generalnie nie do końca wiadomo co jest w tym całym bot-necie chińsko-koreańskim. Biorąc pod uwagę, że Azjaci mają łeb do hackingu, to może nagle przyjść jakiś bot, który exploituje nam usługę - trzeba się "zabezpieczać" na ile się da, ale nie unikać problemu.

Albo inaczej - trzeba sie pogodzić że ktoś w końcu znajdzie lukę gdzieś, i pomyślec co zrobić żeby straty były jak najmniejsze.