API per accedir a les dades del Bicing

Llistat d’aplicacions en temps real per consultar l’estat de les estacions del Bicing en temps real.

Trastejant per internet m’he trobat amb un aplicació que obté les dades del Bicing en temps real, o sigui una API del bicing que s’anomena Citybik.es i a part de poder consultar les dades del Bicing en temps real també permet accedir a les dades dels “bicings” d’altres ciutats d’arreu del món com Londres, Brussel·les, París, entre moltes d’altres. A banda de l’API, també disposen d’una aplicació per al sistema operatiu Android i en la seva pàgina diuen que estan preparant l’aplicació per a iOS o el que és el mateix per a iPhone i iPad.  Tal i com he comentat anteriorment disposen d’una API per poder accedir a les dades dels “bicings” que actualment suporta dos formats:

El projecte té llicència LGPL i el codi es troba a @github.

Recentment Citibik.es ha ampliat el projecte mostrant en temps real les bicicletes que s’agafen i les que es retornen a les ciutats de tot el móns a les que té accés l’API i l’han anomenat CityBikes realtime.

Fent servir l’API de Citibik.es i gràcies a les puntualitzacions del seu creador, Eskerda, es poden trobar els següents projectes que també permeten accedir a les dades del Bicing de Barcelona i altres ciutats en temps real:

Atacs SSH: protegeix el teu servidor

Quan tens un servidor a Internet exposes la teva màquina a milers d’atacs sobre aquest buscant vulnerabilitats en el sistema per accedir-hi utilitzant els usuaris del sistema. Com a mètodes d’atac tenim l’atac de força bruta i l’atac de diccionari. Aquesta entrada explica les opcions que tenim per evitar aquests tipus d’atacs.

 

Logo del keepass

Quan tens un servidor a Internet exposes la teva màquina a milers d’atacs sobre aquest buscant vulnerabilitats en el sistema per accedir-hi utilitzant els usuaris del sistema. Hi ha diversos tipus d’atacs però en aquesta entrada ens centrarem en els atacs SSH.

Com a mètodes d’atac tenim l’atac de força bruta i l’atac de diccionari. L’atac per força bruta consisteix en anar provant totes les possibles combinacions d’una contrasenya sobre un usuari fins aconseguir l’accés al sistema, el que pot comportar molt de temps per aconseguir entrar en el sistema. Justament per això apareixen els atacs de diccionari que el que fan es aprofitar-se que la majoria de les contrasenyes que es posen es basen en paraules que tenen un significat, doncs bé, es proven aquestes paraules reduint el número de proves a realitzar i conseqüentment el temps d’accés al sistema. Per evitar això el millor és seguir una política de contrasenyes per a que aquestes no siguin fàcils de reconèixer per cap dels dos tipus d’atac mencionats anteriorment. També es poden fer servir eines com el Keepass que et permet emmagatzemar (en un fitxer encriptat) i generar contrasenyes segures (amb caràcters especials, longitud determinada, …). A part, en el nostre servidor també podem dur a terme algunes tasques per evitar que ataquin el nostre servidor com les que llistem a continuació:

  • utilitzar el firewall del nostre servidor
  • utilitzar l’utilitat denyhosts
  • modificar el fitxer hosts.allow i el hosts.deny
  • modificar la configuració de l’ssh

Utilitzar el firewall del nostre servidor

Mitjançant el firewall del nostre servidor, podem permetre o denegar l’accés a unes determinades IP:

  • Permetem totes les connexions al port 22 des de la IP 66.23.45.78:
[nom_usuari@nom_servidor rc.d]# iptables -A INPUT -p tcp -m state --state NEW --source 66.23.45.78 --dport 22 -j ACCEPT
  • Deneguem la resta de connexions al port que utilitza SSH:
[nom_usuari@nom_servidor rc.d]# iptables -A INPUT -p tcp --dport 22 -j DROP

Aquestes modificacions també es poden dur a terme al fitxer /etc/rc.d/rc.local, així aconseguirem que s’executi cada vegada que engeguem la nostra màquina, afegint una regla per permetre l’accés a determinats ports (per exemple 22, 25, 80), sense especificar cap IP i denegar la resta prèviament

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -m multiport --destination-ports 22,25,80 -j ACCEPT

 

Utilitzar l’utilitat Denyhosts per evitar atacs SSH

Denyhosts és un script escrit en Python que analitza els missatges de log del servidor sshd per decidir quins hosts estan intentant dur a terme un atac al teu sistema.  També determina quins comptes d’usuari són els que s’ataquen així com la freqüència dels atacs SSH des de cada host.

Cada cop que es detecta un possible atac repetit, el fitxer /etc/hosts.deny es actualitzat per prevenir possibles intents en el futur d’aquest host.

 

Modificar el fitxer hosts.allow i el fitxer hosts.deny

 

Tal i com s’ha comentat anteriorment, amb l’eina Denyhosts s’automatitza el fet de retocar els fitxers hosts.deny i hosts.allow manualment, però si no es vol fer automàticament, es poden afegir manualment les IPs dels hosts que es volen denegar i que es volen acceptar respectivament en aquests fitxers.

Si tenim el cas que coneixem una IP (per exemple: 67.223.43.212) que es intenta connectar-se al nostre servidor repetidament i li volem denegar l’accés, podem escriure el següent en el fitxer hosts.deny:

sshd: 67.223.43.212

I per permetre l’accés a una IP nostra (per exemple: 66.67.82.47), hem de modificar el fitxer hosts.allow

sshd: 66.67.82.47/255.255.255.0

El fitxer hosts.allow preval sobre el fitxer hosts.deny o sigui que si posem en hosts.deny sshd:ALL i en hosts.allow posem alguna IP permetrà l’accés a les IPs que hi hagi al hosts.allow.

Modificar la configuració de l’SSH

El servei de SSH a CentOS es configura mitjançant el fitxer /etc/ssh/sshd_config.  En aquest fitxer es poden configurar les següents directives

  • No permetre l’accés a l’usuari root mitjançant SSH
PermitRootLogin no
  • Permetre l’accés a determinats usuaris (per exemple usuari marc i usuari xavi):
AllowUsers marc xavi

 

Un cop modificat aquest fitxer, s’ha de reiniciar el servei SSH mitjançant la següent comanda /etc/init.d/ssh restart.

 

Nota: aquesta entrada parla de la distribució CentOS però pot servir per a la majoria de distribucions Linux

Optimització d’Apache: keepalive

Apache és el servidor web més utilitzat de tot el món (15/11/2011) i per tant una de les tasques més importants a realitzar és la d’obtenir el màxim rendiment possible d’aquest servidor.  Aquí és on entra en joc Keepalive.

  

Què és el KeepAlive?

El protocol HTTP és un protocol en el qual és fa una connexió per obtenir un fitxer i aquesta connexió es tanca quan es reb el fitxer, el que fa les coses molt fàcils però no gaire eficients. Per aconseguir aquesta eficiencia es va crear una cosa anomenada KeepAlive amb la qual tant el servidor web com el navegador utilitzen la mateixa connexió per transferir múltiples fitxers.

La utilització  del Keepalive comporta beneficis i inconvenients. Pel cantó dels avantatges tenim que amb el KeepAlive activat aconseguim millorar la velocitat del nostre servidor web i redueix l’utilització de CPU però, per contra, s’incrementa l’utilització de de memòria en el servidor  ja que Apache ha de mantenir obertes les connexions esperant noves peticions per a les connexions obertes. 

Necessito utilitzar Apache KeepAlive?

Per tant la decissió de fer servir KeepAlive  o no depen de molts factors i tal i com s’ha comentat anteriorment, la RAM és un d’ells. Si en tenim poca serà milltr tenir-lo desactivat. Per contra si tenim poca CPU KeepAlive ens anirà molt bé si està actiu. També s’ha de tenir en compte si el nostre site tindrà molt de transit durant el dia pero espaiat en el temps o bé concentrat tot en un moment concentrat del temps. En el primer cas ens serà útil tenir KeppAlive actiu, mentre que en el segon cas ens interessarà mantenir-lo desactivat.

Com es configura Apache KeepAlive?

Com ja he comentat moltes vegades, jo faig servir normalment la distribució CentOS, en aquesta distribució hi ha un fitxer anomenat httpd.conf que es localitza a la següent ruta /etc/httpd/conf. Dins d’aquest fitxer hi ha els paràmetres de configuració de Apache i concretament pel que fa a KeepAlive hem de buscar una línea on apareixi la apraula KeepAlive i si esta a off el posem a on, quedant de la següent manera:

keepalive On

També hem de fixar número màxim de peticions que una connexió persistent atendrà, o el que és el mateix, configurar el paràmetre MaxKeepAliveRequests. El valor recomenat per a aquest paràmetre pot estar entre 50 i 75. Per últim ens queda configurar el temps que el servidor esperarà per noves peticions de clients connectats, o el que es el mateix, retocar el paràmetre KeepAliveTimeout. Això ens serveix per utilitzar la menor RAM possible mentre s’esperen peticions. Un valor entre 1 i 5 segons es força adequat.