Archives

Apache 2.4 mod_remoteip pentru colectarea în loguri a ip-urilor reale

Într-unul din proiectele recente am avut de pus pe picioare un setup în AWS.
Una dintre problemele pe care nu le anticipasem a fost că ip-urile vizitatorilordin logurile Apache erau suprascrise cu cel al load balancer-ului.

Căutând soluții am ales ceea ce mi s-a părut a fi cea mai simplă abordare și care satisface cerința fără multe modificări și anume folosirea modulului mod_remoteip din Apache 2.4.x

Pentru asta (serverele rulând Ubuntu) pașii sunt următorii:

$ sudo a2enmod mod_remoteip

Apoi în fișierul /etc/apache2/mods-enabled/remoteip.conf sau direct în /etc/apache2/apache2.conf (după dorința fiecăruia) se adaugă:

 RemoteIPHeader X-Forwarded-For

iar în secțiunea de definire a metodelor de log din /etc/apache2/apache2.conf se schimbă:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

în

LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

Adicătălea din %h în %a.

La final se restartează serverul de apache și din acest moment în loguri ar trebui să apară ip-urile reale ale vizitatorilor.

Taie elanul spamerilor cu mod_defensible

Urmărind activitatea serverelor pe care-mi petrec timpul, am sesizat în ultimele două luni o creștere de vreo 25% a volumului de încercări (presupun scriptate) de a găsi instalări ale WordPress, PhpMyAdmin și pagini cu formulare pe site-urile găzduite local. Nu m-a tentat să-mi bat prea tare capul cu întrebarea logică “Cum mama lor s-au prins așa repede că a apărut un nou domeniu de s-au și pus să-l scaneze?”, dar, m-am apucat să caut o metodă de a le mai tăia din elan acestor vizitatori nedoriți. Ca o paranteză – încep să cred că asta e jobul unor oameni și nu neapărat o mișcare automatizată întrucât, de exemplu scripturile de la “w00tw00t” sau “w00tw00t.at.blackhats.romanian.anti-sec:)” sunt rulate de pe multe ip-uri din China (probabil proxy), în mod special între orele 9 și 17 – GMT + 8 (ceea ce pică ca o mănușă pe CST – China Standard Time).Paranteză închisă.

Căutând să reduc numărul acestor vizitatori nedoriți am descoperit (nu doar apa caldă și că roata-i rotundă) – mod_defensible (destul de bătrân dar foarte util). mod_defensible este un modul pentru serverele Apache 2.x care blochează accesul spamerilor folosind serverele DNSBL. Astfel, înainte de a-i fi afișată pagina cerută, fiecărui vizitator îi va fi verificată adresa IP în unul sau mai multe servere DNSBL. Dacă adresa este prezentă în acestea, vizitatorul cu pricina se va trezi cu o minunată eroare 403 în fața ochilor și cam aici i se termină vizita.

mod_defensible poate fi descărcat și instalat folosind sursele de pe site-ul proiectului julien.danjou.info dar este de asemenea prezent în depozitele de bază ale distribuțiilor majore.

Pentru cei (ca mine) care folosesc servere Ubuntu, procedura de instalare este următoarea (presupun că deja există un server Apache instalat și configurat):

# sudo apt-get install libapache2-mod-defensible libudns0 

Unde libapache2-mod-defensible va instala modulul în sine iar libudns0 va instala bibliotecile necesare pentru UDNS.

După ce se termină instalarea, în /etc/apache2/apache2.conf trebuie adăugate următoarele:


DnsblUse On
DnsblServers httpbl.abuse.ch sbl-xbl.spamhaus.org
DnsblNameserver 145.253.2.75

Adresa folosită pentru DnsblNameserver poate fi înlocuită cu adresa oricărui alt server DNS, inclusiv cel local (dacă există).

Mai rămâne acum doar ca acest modul să fie activat,

$ sudo a2enmod defensible 

Și restartat serverul Apache

$ sudo /etc/init.d/apache2 restart 

După mine, acest modul merge bine combinat cu mod_evasive și nu în ultimul rând cu fail2ban sau denyhosts.

Găzduirea mai multor site-uri cu SSL pe același IP

Poate părea o rezolvare prostească și sunt convins că există multe alte metode mai elegante pentru a rezolva situația cu pricina.

M-am mai lovit de necesitatea găzduirii mai multor site-uri pe același server, toate având nevoie de SSL și neavând la dispoziție decât  o singură adresă IP.
Unde s-a putut am actualizat Apache și OpenSSL ca să permtiă SNI. Numai că uneori din varii motive nu m-am putut “atinge” de configurările serverului, sau am avut parte de probleme datorate navigatoarelor folosite de utilizatori…
Partea bună e că problemele nu apar pe servere aflate în producție și de cele mai multe ori, cerințele-s doar temporare.

Astăzi am găsit pe forumul Ubuntu niște discuții destul de vechi în urma cărora am reușit să compun o soluție care mi se potrivește ca o mănușă 🙂
Soluția este bazată pe minunea numită “rewrite” și o povestesc mai jos:

Am generat un certificat local în care la Common Name am pus *.domeniu.ro

Am făcut în directorul în care stau fișierele de configurare ale apache un fișier în care se vor mapa numele site-urilor și locațiile fizice (DocumentRoot) ale fișierelor – eu l-am numit host.ssl și arată cam așa:

site1.domeniu.ro /var/www/site1/
site2.domeniu.ro /var/www/site2/
site3.domeniu.ro /var/www/site3/

După asta am făcut un fișier de host virtual – vhost-ssl în care, pe lângă directivele specifice SSL (calea către certificat, opțiuni, calea către fișierele separate de log etc.) am pus următoarele:


RewriteEngine on

# am “forțat” formatarea adresei utilizate
RewriteMap lowercase int:tolower
#calea către fișierul host.ssl
RewriteMap vhost txt:/etc/apache2/host.ssl
#condiția pentru formatarea adresei
RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$
#citesc din fișierul host.ssl
RewriteCond ${vhost:%1} ^(/.*)$
#suprascriu calea fizică
RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}]

După asta am restartat apache și asta a fost cam tot.

Acuma, trebuie să recunosc că nu mă așteptam să fie așa ușoară toată distracția… însă-mi aduc aminte că acum vreo doi ani, când am mai avut nevoie de asta… n-am dormit vreo săptămână căutând soluții… Ca într-un final să aflu că varianta OpenSSl care m-ar fi ajutat nu mergea cu apache pe 64bit și X,Y,Z…

Așa că articolul ăsta va fi trecut la “Nu uita!”

Lucruri pe care nu le știam despre Apache 2.2.x

Până de curând (și sunt convins că nu sunt singurul în situația asta) știam despre Apache 2.2 că merge… și că merge foarte bine, dar, nu am avut nici timpul, nici cheful să sap în el, să văd ce noutăți au fost introduse în cel mai server dintre servere cum îl numesc unii :). Așa că am adunat aici câteva din lucrurile pe care până de curând chiar nu le știam….

SNI

De câns am început eu să butonez printre servere și siteuri, am știut că protocolul SSL are o bubă fundamentală, astfel încât nu poți avea mai multe certificate, pentru mai multe domenii pe același server, fără să aloci mai multe ip-uri. Alocarea de ip-uri pentru fiecare site este cea mai decentă rezolvare ok, dar, ce te faci când un client își alege un hosting unde nu poți adăuga ip-uri dar are 2 siteuri pe care vrea SSL? Ei bine, am aflat că Apache a trecut de asemenea în secolul 21 și acum permite configurarea mai multor hosturi virtuale, cu SSL activat pe aceeași adresă ip. Și că face asta folosind ceea ce se numește SNI (Server Name Idication)

Ideea cu SSL-ul e că nu știi numele cărui domeniu este cerut după ce certificatul (iar acesta poate să nu fie cel corect) a fost supus schimbului între client și server. Cu SNI numele este parte din negocierea inițială, astfel încât întotdeauna serverul va ști ce certificat să servească.

Încă de la versiunea 2.2.12, Apache are acum suport pentru SNI, așa că poate servi multiple site-uri cu SSL la aceeași adresă ip. Partea bună e că au început și programele de navigare să suporte SNI, acum, rămâne să vedem cât mai multe implementări… Cine dorește mai multe detalii despre SNI: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI.

Graceful Stop

La prima vedere, asta nu e mar lucru, dar, trebuie să recunosc că și eu am plâns după asta de multe ori. De câte ori nu ați stat să vă gândiți de mai multe ori înainte de a restarta serverul, iar în primele secunde după ce s-a oprit a sunat telefonul, cineva reclamând că “a picat rețeaua” ? De felul lui, atunci când se restartează, Apache omoară toate conexiunile existente…. iar această funcție de graceful stop păstrează conexiunile până ce acestea expiră. De asemenea, acum ceva timp, în același scop apăruse graceful restart, tot pe post de pastilă împotriva durerilor de cap cauzate de șefi.

$ httpd -k graceful-restart

Dar ce avem de făcut când trebuie să omorâm cu totul un server, dar nu vrem ca acest lucru să fie vizibil clenților? (normal, asta când vorbim de configurații cu mai multe servere și cu balansare a încărcării). Păi, Apache 2.2.x are această minunată opțiune, graceful stop. Așa că, toate conexiunile deja prezente vor fi păstrate în celălalt server, în timp ce pe serverul pe care lucrăm Apache se va opri.

$ httpd -k graceful-stop

Astfel, opririle de mentenanță devin transparente, iar utilizatorii și șefii’s fericitți.

mod_proxy_balancer

S-a scris mult despre mod_proxy_balancer cum se instalează, configurează cât mai eficient, dar până nu ajungi să ai nevoie, nu afli că este deja inclus în Apache.

Apache 2.2 vine cu o interfață foarte puternică care poate balansa un număr indefinit de servere în spate fără a avea mari probleme. De asemenea, știe să țină minte unde a redirectat un client, astfel că toate cererile acelui client se vor duce spre același server spre care a fost trimis de prima dată, sesiunile sale nefiind astfel întrerupte.Face așadar ceea ce se numește balansare orientată spre trafic. Altă facilitate este că știe să predea altui server conexiunile atunci când serverul inițial pică. Și nu în ultimul rând, are și o consolă web de administrare, de unde se pot scoate serverele din procesul de rotație, sau modifica prioritatea lor.

Este un server de proxy adevărat, gratuit și inclus în serverul Apache 2.2

Pentru a iniția mod_proxy_balancer, trebuie definit pachetul de servere sau “clusterul” care vor face balansarea


BalancerMember http://192.168.1.50:80
BalancerMember http://192.168.1.51:80
BalancerMember http://192.168.1.51:80

Apoi trebuie să spunem serverului să folosească:

ProxyPass /test balancer://mycluster/

Pare simplu nu? Chiar este. Și de asemenea sunt multe alte opțiuni care pot fi configurate.

Să nu uit… documentația completă, împreună cu exemple etc o puteți găsi la: http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html

Ar mai fi poate de zis despre httxt2dbm sau flagul -M…. dar despre astea poate apuc să mai scriu în altă zi.

WebEx + Firefox 3 în Ubuntu 8.10

Pe ziua de azi, printre activitățile mele s-a nimerit să se întâmple si o configurare de server Apache via WebEx, pe o mașină care nu are acces la net (un server local al unui client care furnizează informații doar in LAN).

Așa că mă pun eu frumos și imi fac incă un cont (pentru că bineînteles uitasem parola de la ultima mea experiență WebEx) iar când sa fac conexiunea de test…. surprize, surprize…. Firefox crapă într-o fericire… fără mesaje de eroare, fără să aibă bunul simț să spună ce și cum se întâmplă.

Într-un final, am găsit o mulțime de variante de a face să funcționeze, o sursă foarte bună fiind aici: http://ubuntuforums.org/archive/index.php/t-502973.html….

De la lume adunate și-napoi la lume date:) asta e ceea ce a rămas în picioare pentru mine, din păcate, se pare ca e puțin probabil să funcționeze în versiunile pe 64bit, cel puțin așa reiese din posturile găsite pe net.

1. sudo apt-get install libstdc++5 sun-java6-plugin
2. Am editat ~/.profile și am adăugat următoarele două linii:
export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.66
export PATH=$JAVA_HOME/bin:$PATH
3. Am restartat X-ul cu ctrl+alt+backspace

După toate astea, am reușit să particip la conferința WebEx și să îmi rezolv problemele remote acolo.

Constatări de final (nu ma lasă sufletul să nu le fac):

1 – NU mă așteptam ca cei de la Cisco sa nu ofere suport pentru Linux in aplicațiile lor.

2 – Speram ca dupa atâția ani de zile de participări pe forumuri, unii useri să înteleagă faptul că dacă cineva postează o problemă cu o aplicatie, indiferent cât de exotică este aceasta, indiferent dacă parerea mea personală este pro sau contra acelei aplicații – un răspuns util este să îi spui dacă și eventual cum poate omul să scape de problemă nu să ii dai o listă cu aplicații similare care iți plac sau nu sau care “rulez frate”. Nu de alta, dar asta ajunge sa semene a Microsoft (toți să folosească aceeasi aplicație în același fel pentru a putea deveni productivi.) ori, tocmai asta cred că este esența și spiritul Linux – să poti folosi mai multe moduri / aplicații pentru a-ți atinge ținta și a-ți rezolva problema.


China vrea sa vorbeasca!

Conform statisticilor de la Netcraft, site-ul qq.com facut un salt incredibil, de la 3 situri gazduite la mai bine de 20000000 !!! intr-o singura luna, devenind astfel al treilea furnizor de servicii web din lume. Cum s-a ajuns aici? Prin simpla activare a serviciilor de blog pentru clientii lor. Si asa au ajuns iata mai tari ca  Goggle blogger, ca Microsoft Live Spaces mult peste MySpace. Intr-o singura luna! Va imaginati? Acolo, in China zaceau 20 de milioane de oameni care vor bloguri.

Mai jos am pus tabelul de la Netcraft

Developer January 2009 Percent February 2009 Percent Change
Apache 96,947,298 52.26% 104,796,820 48.59% -3.67
Microsoft 61,038,371 32.91% 62,935,449 29.18% -3.72
qq.com 3 0.00% 20,021,763 9.28% 9.28
Google 9,868,819 5.32% 8,157,546 3.78% -1.54
nginx 3,462,551 1.87% 3,447,596 1.60% -0.27

Sursa: Netcraft Web Survey Survery Feb 2009

© 2009-2019 Alex. Burlacu
%d bloggers like this: