VipNight Networks

Kadangi prieš kurį laiką išsivaliau visas iptables taisykles, tai labai tingėjosi daryti visiems servisams iš naujo. Šiek tiek pagooglinęs radau alternatyvą, kuri už mane atliko visą reikalingą darbą: fail2ban. Mano serveryje naudojama Ubuntu Server distribucija, todėl įdiegimas nereikalavo jokių konfigūravimo ir kompiliavimo žinių (kartais tingisi tai daryt):
’sudo apt-get install fail2ban’

Tada beliko susirast /etc/fail2ban/fail2ban.conf.
maxfailures - kiek kartų suklydus blokuoti IP;
bantime - kuriam laikui blokuoti IP (dokumentacijoje parašyta, kad neigiamas skaičius reiškia permanent, tik man tai neveikė);
ignoreip - IP, kuriam negalioja draudimai (by default šio nustatymo nėra fail2ban.conf byloje.);

Dabar parodysiu, kaip reikia apsaugoti, pvz, SSH:

[SSH] - serviso pavadinimas;
enabled = true
logfile = /var/log/auth.log - kur fail2ban turi stebėti prisijungimų eigą;
port = ssh - serviso pavadinimas (iptables standartas);
timeregex = S{3}s{1,2}d{1,2} d{2}:d{2}:d{2} - laiko regexp’as
timepattern = %%b %%d %%H:%%M:%%S - laiko formatas naudojamas loguose;
failregex = : (?:(?:Authentication failure|Failed [-/w+]+) for(?: [iI](?:llegal|nvalid) user)?|[Ii](?:llegal|nvalid) user|ROOT LOGIN REFUSED) .*(?: from|FROM) (?:::f{4,6}:)?(?PS*) - klaidingo pranešimo forma sisteminiuose loguose.

Analogiškai nustatymai veikia ir kitiems servisams, detali informacija autorių puslapyje:www.fail2ban.org

Daug kur internete pastebėjau, kad žmonėms dažnai pakeitus/panaudojus permalink adresų atvaizdavimą, serveris pasiunčia toli toli ir puslapis krenta į komą. Dauguma kaltina patį WP, dar kiti - serverį, treti - paslaptingasias jėgas. Problemos sprendimo būdų radau pačių įvairiausių, nuo mySQL lentelių koregavimo, iki .htaccess bylos rašymo ranka.

Mano tyrimai vykdyti tuose serveriuose, kuriuose PHP scenarijai (scriptai) vykdomi būtent to vartotojo vardu (saugumo sumetimais, uid/gid=useris, o ne www, www-data, apache ar nobody nors gal ir juose tai būdinga).
Tik įkėlus/instaliavus WP, .htaccess nebūna, jis sukuriamas patvirtinant norimus pakeitimus. Ir štai, kas man užkliuvo - jo permissionai. Jie buvo -rw——- (600). Pakeitus juos į -rw-r–r (644) - problema išsisprendė.
Taigi, nereikia nieko perrašinėt, nereikia rankiniu būdu kilnot to .htaccess, su juo viskas tvarkoje. Pasitvarkome permissionus ir problemos kaip nebūta. Enjoy.

Kažkurią čia dieną manęs paklausė, kaip yra skaičiuojamos CHMOD reikšmės. Visi jau žino, kad naudojamas (dažniausiai) triženklis skaičius, pvz.: 775, 750, 777. Bet ne daug kas žino, kaip tai paskaičiuot.
Taigi, pradėsim elementariai - įsivaizduokime, kad turime paprastą bylą ‘test’ be jokių teisių nustatymų, tai atrodys šitaip: ———-. Dešimt brūkšnelių. Pirmasis reiškia bylos tipą. d - katalogas, s - socketas, p - pipe, l - nuoroda/shortcutas. Yra dar keletas variacijų, bet jų mums kol kas nereikės. Sekantys trys - vartotojo teisės, dar kiti trys - vartotojo grupės teisės, likę trys - kitų teisės. Tarkime, jog norime, kad mes galėtume skaityt/rašyt, grupė - skaityt, kiti -skaityt.
Read atributo vertė - 4;
Write atributo vertė - 2;
Execute atributo vertė - 1;
Dabar paskaičiuokime: RW = 4+2 = 6, R = 4, R = 4, RW/R/R = 644.
Ką reiškia 755? 7=4+2+1=RWX, 5=4+1=RX, 5=4+1=RX.

Tai tiek šiam kartui apie bylų atributus.

Šiąnakt sėdėjau ir mąsčiau, kokie pagrindiniai aspektai padeda įsiskverbt į serverį hackeriui… Taigi, viską pabandžiau sudėliot eilės tvarka (mano ir jūsų nuomonės gali skirtis, tad nepeikite).

1. Netvarkingi php/perl/asp scriptai.
Kaip žinia, tai labai palengvina įsilaužėlio dalią, nes tai padeda surengt CSS/XSS ataką, SQL injekciją (aklą arba tikslingą), įkelti scriptus įgalinančius jam praplėst veiksmų spektrą (web shell).

2. Gavus priėjimą prie serverio pasinaudojant pirmu žingsniu, daromas antras - naudingos informacijos paieška. Dabartiniai hostingų adminai pagaliau susivokė ir pradėjo riboti PHP/PERL scriptų veiksmus (disabled_functions, safe_dir, suPHP). Tačiau yra viena mySQL klaida (ar tai funkcija daryta tikslingai, bet įsilaužėlių panaudota būtent savo tikslams), leidžianti skaityti lokalius failus. Asmeniškai mano pirmas taikinys būtų phpMyAdmin. Naudojant automatinį įdiegimą iš paketų (konkrečiai kalbėsiu apie Debian pagrįstas sistemas), yra sukuriamas mySQL vartotojas ‘debian-sys-maint’ (gal suklydau, bet dabar tingiu aiškintis), kurio slaptažodžio žinojimas tolygus visai mySQL DB kontrolei.

3. mySQL ir FTP slaptažodžių sutapimas.
Retas, tačiau vis dar pasitaikantis atvejis, kaip FTP ir mySQL slaptažodžiai sutampa. O jei dar yra SSH (nors dar nemačiau nei vienos brandžios hostingo kompanijos, kuri tai duoda, cPanel ir DirectAdmin automatiškai suteikia /sbin/nologin arba panašias direktyvas).

Taigi, įvertinkime tokią situaciją - įsilaužėlis pateko į vidų (turi FTP ir mySQL slaptažodžius). Asmeniškai man teko susidurt su tuo, kad įsilaužėlis paleido MassMail PHP scriptą. Ko gero, ilgokai to nebūčiau pastebėjęs (ps aux nerodė nieko neįprasto), jei ne padidėjęs serverio ‘loadai’. Štai čia į pagalbą atėjo Apache ‘logai’. Panagrinėjęs juos, suradau ir pašalinau scriptą. Daugelis laiškų nepasiekė adresato (mano serverio vardas nesutampa su jo adresu, todėl natūralu, kad jo nepripažino gavėjų serveriai.). Todėl leisiu sau įtraukti čia

4. Scriptų vykdymo laikas ir atminties išskyrimas.
Kiekvienam vykdomam PHP/PERL scriptui derėtų riboti vykdymo laiką (taip apsisaugosite nuo IRC botų paleidimo jūsų serveryje, bei panašių ‘backgrounde’ veikiančių PHP/PERL programų.)

Po viso šito, išsiaiškinus, kas tai padarė ir paviešinus šį faktą, mano serverį užlūdo DDoS ataka. Kaip nuo jos apsiginti, aprašiau ankstesniame įraše, tačiau nepaminėjau kai kurių pakeitimų Apache ir mySQLd serverių konfigūracijose (neskaitant PHP scriptų vykdymo laiko ir atminties sumažinimo).

5. Apache MaxClients ir mySQL max_connections nustatymų suderinimas pagal realius serverio poreikius.
Pas mane buvo ‘default’, taigi, Apache serveris leido jungtis 150 kompiuterių, nors realiai tiek aptarnaut negalėjo. Tad, sumažinau iki realaus skaičiaus pagal maksimalią įmanomą serveriui. Mano atveju tai buvo 30 (mažai lankosi, prisipažinsiu), todėl net ir agresyviausia DDoS ataka neužlauždavo sistemos, Apache atlaikydavo šią apkrovą, scriptų vykdymas nutrūkdavo dėl vykdymo laiko limitavimo, atminties nepritrūko (to mes ir siekėme, ar ne?)

6. Duomenų bazių kopijos.
Daugelyje hostingo kompanijų, už kopijos suteikimą reikia papildomai mokėti. Tai natūralu, jei vartotojas tuo nepasirūpina, vadinasi, gali už tai sumokėti. Mano serveryje kopijos automatiškai daromos kas 12 valandų. Jos yra prieinamos TIK man, ir joks įsilaužėlis prie jų neprieis (nebent gautų root teises).

7. Ir į paskutinę vietą pastatysiu drwxr-xr-x /home bei /home/user bei drwxrwxrwxt /tmp /var/tmp CHMOD’us..
Gerbiamieji administratoriai, bei serverių turėtojai, taip jūs atveriate visus vartotojų katalogus skaitymui tiesiog bet kam… drwx–x–x - štai toks CHMOD’as tenkina ir mane, ir vartotojus ir net priekabųjį suPHP/cgi-php. Bent jau pas mane puikiai pasiteisino. O /tmp ir /var/tmp, suteikti yra drwx-wx-wt CHMOD. Ir vėl gi - ir man gerai, ir serveris nesispjaudo. O svarbiausia:
eil@capricorn:/home$ ls -lia
ls: .: Permission denied
ir
eil@capricorn:/$ ls -lia /tmp
ls: /tmp: Permission denied

Valio, dabar niekas nematys, kokią pornografiją laikau pas save homedir’e

Tai tiek šiandien mano blevyzgų apie saugumą. Komentarai visada laukiami.

Taigi, aprašysiu savo projektėlį. Jo esmė yra serverio sukūrimas, paleidimas ir administravimas paprastame stacionariame kompiuteryje. Aprašysiu savo kompiuterio “geležies” parametrus:
(more…)