Tag: Networking

pfSense deixava de re-enviar paquets misteriosament…

Reading time: 10 – 16 minutes

Intentaré explicar-vos un ‘expedient X’ d’aquells que ja tinc resolts, però que no tinc una explicació al 100% del comportament que tenia el pfSense davant del problema. La conclusió és que el pfSense descartava paquets per tenir massa connexions concurrents, però al ser connexions UDP costava identificar-les. El problema és que de forma completament misteriosa el pfSense descartava els primers X’s paquets cap a qualsevol IP. Aquesta número indeterminat, podia ser des de 2, 3 o 4 paquets fins a 100 o 200. O sigui, que hi havia moments on donava la sensació que s’havia perdut l’enllaç. Com a pecualiaritat de la configuració del firewall (pfSense) comentar que la targeta WAN estava en mode bridge amb la targeta de servidors d’internet. O sigui, que la DMZ rep el tràfic de les IPs públiques que allà hi han filtrat a través d’un bridge d’aquestes dues targetes de xarxa que he comentat.

Exemple, de la pèrdua de paquets que comentava. Ping realitzat a una IP d’internet (la de oriol.joor.net) des del propi firewall. Realment això d’operation not permitted em va tenir molt i molt desoncertat.

# ping 80.35.31.228
PING 80.35.31.228 (80.35.31.228): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
64 bytes from 80.35.31.228: icmp_seq=9 ttl=57 time=117.668 ms
64 bytes from 80.35.31.228: icmp_seq=10 ttl=57 time=86.728 ms

Des de qualsevol de les altres potes del firewall es patia el mateix efecte, fins hi tot si es feien els pings cap a la LAN. La solució vaig trigar quasi 48h en trobar-la, era una bogeria. Ja que al final per localitzar el problema varem aïllar el firewall d’internet i el fenòmen va deixar de passar.O sigui, ja mai passava això d’operation not permitted per molt tràfic que injectessim al firewall, no passava. Així doncs, gràcies a una molt bona idea del Manu varem tancar tot el tràfic des d’internet i varem anar obrint serveis cap a la DMZ, un per un. Fins que vaig descobrir que el servei d’NTP (123/upd) era el que probocava aquest extrany efecte al pfSense.

Després de diverses proves la conclusió, és que hi havia masses connexions concurrents contra el servei que comento. Així doncs, actualment el que he fet és filtrar el número de connexions que permeto contra aquest port:

pfsense.png
<div class="imatge" style="text-align: center;"></div>

Aquestes opcions les podeu trobar editant la Rule, concretament a la sección on posa Advaced Options. Com podeu veure podeu deixar ben limitat quines connexions i quines no deixeu passar cap a un servei.

Potser el més important que he aprés d’aquesta història és no montar mai un firewall que no acompleixi la regla d’or: by default block all. O sigui, tanqueu sempre tot i ja anireu obrint a mesura que faci falta. Però a vegades per voler ser una mica més transigent ho fem alrevés i al final això s’acaba pagant, com en aquest cas. A mi ja no em tornarà a passar, espero que a vosaltres tampoc.

pop2smtp: POP3 (“recojetodo”) a SMTP amb múltiples destins

Reading time: 2 – 3 minutes

Alguns ISPs ens permeten tenir una compte que reculli tot el correu enviat a un domini, això per exemple es pot usar com a mail-backup del nostre domini. Doncs bé a través de fetchmail és molt senzill re-injectar el correu enmagatzemat a una compte POP3 a un servidor SMTP contra un usuari. El més complicat, és si el correu que hi ha a la compte POP3 pot anar a més d’un destí, com el que deia fa un moment en comptes POP3 tipus ‘recojetodo’ o cul de sac com diuen alguns.

Doncs bé, per això he fet un petit script en python que a partir d’un fitxer BSMTP modifica la companda RCPT TO en funció de la informació de l’etiqueta Envelope to que conté una llista de les comptes d’email destí a qui va dirigit el correu. Així doncs, bàsicament la tasca consisteix en buscar quines comptes d’email apareixen a l’etiqueta comentada i després borrem la comanda RCPT TO i creem tantes comandes d’aquest tipus com faci falta en el seu lloc per enviar copies del correu que volem enviar als seus destins. Aquest nou fitxer BSMTP modificat l’injectem al nostre MTA. Aquest MTA serà l’encarregat de processar aquest correus i entregar-los a les comptes destí.

En el meu cas he decidit fer un petit shell script que s’executa des del crontab cada 10min. Aquest script, Crida a fetchmail per obtenir el fitxer BSMTP amb el correu que hi havia a la compte POP3, després crida l’script de python per modificar el fitxer BSMTP d’entrada tal com he comentat i crea un nou fitxer BSMTP de sortida. Finalment aquest fitxer s’injecta via SMTP cridant un petit script que gràcies al NetCat envia per SMTP el contingut del fitxer BSMTP de sortida.

L’script amb l’estructura de directoris empaquetat en un fitxer: pop2smtp_r1.tar.gz.

Segur que hi ha formes més elegants de resoldre el problema, però la veritat no les he sabut trobar.

Servidor FTP darrera un NAT (pure-ftpd)

Reading time: 2 – 2 minutes

Sovint quan montem un servidor FTP darrera d’un Firewall que fa DNAT per publicar els ports FTP (20, 21, tcp i udp) a internet ens deixa de funcionar l’FTP en mode Passive On. Llavors hem de fer allò tan molest i depenent del client tan difícil; o sigui, fer un Passive Off perquè la transmissió d’arxius, llistats de fitxers, etc. funcioni bé. Doncs avui cansat d’això en un servidor pure-ftpd que tinc montat a la feina i he posat solució ja que sinó tenia als tècnics molt limitats quan es trobaven a casa dels clients.

La cosa ha estat ben senzilla, només he hagut de llençar el pure-ftpd amb el paràmetre -p i especificar un rang de ports per on es faran les connexions passives. Jo he decidit que anessin entre el port 40000 i el 50000. Així doncs, el paràmetre ha quedat així: -p 40000:50000. Després al firewall he redirigit tot aquest rang de ports contra la IP interna del servidor i llestos (fent un DNAT). Ara ja funcionen perfectament els FTP passius.

Si tot això d’FTP passiu i no passiu, ús sona a xinès he trobat una petita web molt bona que explica la diferència entre un sistema i l’altre: Active FTP vs. Passive FTP, a Definitive Explanation (local).

Python: Reiniciem el router si no hi ha internet

Reading time: 1 – 2 minutes

Malgrat fa uns dies vaig canviar el meu vell Zyxel per un Cisco 837 a casa, la línia ADSL es continua penjant per motius desconneguts. Ja que quan les dades no circulen ni amunt ni aball les interficies ATM estan aixecades i tot sembla funcionar correctament. Així doncs, no m’ha tocat altre remei que fer-me un petit script amb Python a través del qual cada 5min comprovo si tornen els pings contra un dels servidors de OpenDNS. Si això no és així llavors es connecta contra el router Cisco i el reinicia. Ja que he fet proves baixant i pujant la interficie ATM i no hi ha manera. No se m’ha acudit cap millor idea que llençar un reload.

L’script guarda un fitxer de log a /var/log/online.log i usa el modul pexpect de Python. La resta de coses que usa són moduls que van instal·lats per defecte.

Si a algú li pot fer falta l’script el podeu descarregar: router.py.

pfSense: amb una Intel Quad PRO/1000 cal una versió >1.0.1

Reading time: 2 – 4 minutes

Avui he patit una d’aquelles feines d’administrador tan tontes i que et fan perdre tan de temps. Havia d’instal·lar una Intel PRO/1000 GT QUAD PORT en un servidor Compaq Proliant DL320 per fer de firewall amb un pfSense i el coi de servidor no tenia CDROM. El problema de connectar-li un CD extern és que detectava la tapa oberta i no s’engegava un cop superat aquest tema, com que la BIOS és vella i propietaria, no permetia arrencar amb un CD IDE sinó que volia que uses la controladora que porta instal·lada especialmet per aixo sinó no podia arrencara des de CD per instal·lar el pfSense. Al final he tret un dels disc durs del servidor, encara sort que són IDE, l’he posat a un ordinador nomal i l’hi he instal·lat el pfSense al fer el canvi de PC tot perfecte. Només un però, resulta que la versió 1.0.1 del pfSense no reconeix de forma automàtica la versió GT de la targeta de 4 ports d’intel. Així doncs, he hagut de baixar-me la versió beta de la 1.2 del pfSense que ha carregat el driver em del FreeBSD que reconeix a la perfecció la targeta de 4 ports.

intelquad.jpg

Realment una odissea de dia per fer una cosa ben senzilla. Ho comento perquè no perdeu el temps com jo intentant fer meravelles amb la versió 1.0.1 aneu directament a la 1.2 que malgrat estar en beta funciona molt bé. De moment diria que prou bé com per tenir-la en producció. El firewall finalment m’ha quedat amb 6 targetes de xarxa 2 a 100Mbps i 4 a 1000Mpbs. Dels 4 ports a 1000 n’hi ha 3 que hauran de treballar a plè rendiment quan hagi fet les proves d’estrés ja comentaré què tal. De totes formes, imagino que els resultats seràn excel·lents perquè FreeBSD realment és molt bo fent gestió de tràfic i més amb drivers tan madurs com el em per controlar el hardware d’intel.

Per cert, una altre odissea va ser trobar la targeta d’intel. Ja que malgrat fa molt de temps n’havia comprat una. De fet, el model que havia tocat era el MT i la que he montat avui és la GT, de fet ni el fabricant s’aclareix en decidir quina és la diferència real entre elles. Només anotar per si algún dia se’m torna a oblidar que les targetes les he trobat ben aprop de casa a un proveïdor de Vilafranca del Penedès que es diu ELPO. Bàsicament es dediquen al món dels SAIs però també fan de majoristes d’informàtica en general. El curiós és que en cap més distribuidor oficial de networking d’intel a l’estat la tenien ni me la volien portar.

Python trick: error Address already in use

Reading time: 8 – 12 minutes

Quan treballem amb sockets en python sovint al publicar un port si matem el procés que publicava el port encara que sigui de forma correcte ens trobem que al llençar-lo de nou, o sigui, a l’intentar publicar altre cop el procés aquest dona error un error que diu algo així com Address already in use. O sigui, que el sistema operatiu es pensa que el port encara esta sent publicat pel procés que ja em matat. Si fem un netstat veiem que el port no hi és, però encanvi fins al cap d’una estoneta (alguns segons o minuts) no hi ha manera de poder usar de nou aquest port.

Doncs bé, un petit truquillo perquè això no passi i el poguem usar a l’instant és fer això després de crear l’objecte de la classe socket:

# creació de l'objecte
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# afegim noves propietats a l'objecte
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

TCP bouncer o TCP relay digueu-li com volgueu

Reading time: 3 – 5 minutes

Encara m’enrecordo fa quasi 10 anys que per entrar a l’IRC usabem aplicatius d’aquest tipus per tal d’spoofejar la nostre IP. Doncs bé, avui he hagut de montar un procés que fa el mateix que usaben en aquelles èpoques però aquest cop per temes més seriosos. Així doncs, perquè si a algú li cal una eina que re-envii una connexió TCP d’un servidor a un altre de forma estàtica simple senzilla i ben fet he trobat el tcpxd. Ell mateix permet llençar-se com a dimoni, suporta múltiples connexions simultanees de forma asíncrona, de fet les típiques funcions xorres de tota la vida i amb una sintaxis ben senzilla:

tcpxd 7802 10.0.0.1 7802

Són d’aquelles eines xorres que t’ajuden a sortir de més d’un embolic quan la potència del NAT del firewall, router o el que sigui que tinguem pel mig no ens permet fer el que volem.

mini-remember: dig i DNS

Reading time: 53 – 88 minutes

Mai recordo aquest carai de paràmetre del dig:

oriol@mini2 ~ $ dig @80.35.31.228 joor.net axfr
; <<>> DiG 9.3.4 <<>> @80.35.31.228 joor.net axfr
; (1 server found)
;; global options:  printcmd
joor.net.               86400   IN      SOA     s0-ret.inforcomsoft.net. root.inforcomsoft.net. 2007041701 60 60 60 60
joor.net.               86400   IN      MX      20 s0-ret.inforcomsoft.net.
joor.net.               86400   IN      NS      oriol.joor.net.
joor.net.               86400   IN      NS      s0-ret.inforcomsoft.net.
joor.net.               86400   IN      NS      s1-ret.inforcomsoft.net.
joor.net.               86400   IN      A       83.175.213.75
adsl.joor.net.          86400   IN      A       62.37.147.231
bali.joor.net.          86400   IN      A       83.175.213.75
www.bali.joor.net.      86400   IN      A       83.175.213.75
dades.joor.net.         86400   IN      A       83.175.213.76
daphne.joor.net.        86400   IN      A       80.35.31.228
ftp.joor.net.           86400   IN      A       83.175.213.75
imatges.joor.net.       86400   IN      A       83.175.213.76
mail.joor.net.          86400   IN      A       83.175.213.75
medicinachina.joor.net. 86400   IN      A       80.35.35.228
oriol.joor.net.         86400   IN      MX      30 s0-ret.inforcomsoft.net.
oriol.joor.net.         86400   IN      A       80.35.31.228
s0.oriol.joor.net.      86400   IN      MX      30 s0-ret.inforcomsoft.net.
s0.oriol.joor.net.      86400   IN      A       80.35.31.228
tcm.joor.net.           86400   IN      A       80.35.31.228
webmail.joor.net.       86400   IN      A       83.175.213.75
www.joor.net.           86400   IN      A       83.175.213.75
joor.net.               86400   IN      SOA     s0-ret.inforcomsoft.net. root.inforcomsoft.net. 2007041701 60 60 60 60
;; Query time: 191 msec
;; SERVER: 80.35.31.228#53(80.35.31.228)
;; WHEN: Tue Apr 17 12:18:15 2007
;; XFR size: 23 records (messages 1)

Així que aquí queda el recordatori. Aprofito també per enllçar un petit manual que esta molt bé sobre el dig: Dig: consultando la configuración dns.

FeeNAS: FreeBSD embedded com a servidor NAS

Reading time: 2 – 3 minutes

Malgrat encara esta en una versió una mica verda, ja es fa mirar amb molt bons ulls aquest projecte. El FreeNAS és ideal per montar servidors NAS amb un moment. De tots els unixeros és sabut que els BSD tenen unes prestacions d’estabilitat i velocitat millor que els linux. Així doncs crec que és una idea molt bona idea que aquest sistema enquestat usi FreeBSD de base. Potser l’únic inconvenient és que la compatibilitat de hardware de FreeBSD és inferior que la que té linux. Així doncs si el penseu usar aneu molt amb compte a l’hora d’escollir el servidor que usareu. Reviseu la compatibilitat de hardware del servidor amb FreeBSD.

També és una opció interessant a tenir en compte la de tirar el servidor NAS com a màquina virtual dins de l’VMWare o quelsevol altre aplicatiu similar, com ara el Xen. Tingueu en compte que ha de suport FreeBSD. Obviament baixa el rendiment però per molts entorns és més que suficient. Jo la veritat és que em moro de ganes de comprar un targeta SATA i 4 discs d’1Tb per montar-me el nou servidor de fitxers de la xarxa amb un Pentium a 800Mhz que tinc per aquí tirat. De fet, abans de posar-me mans a l’obre provaré la versió de la màquina virtual d’VMware que tenen a la web, a veure fins a quin punt és configurable tot plegat.

screenshot.png

Entre el FreeNAS i el pfSense em moro de ganes de posar-me a re-montar una mica la xarxa de casa que la pobre esta una mica estancada, tot i que tampoc tinc cap necessitat vital de funcionalitats que no em doni tot plegat és una mica montar per disfrutar més que per necessitat.

També comentar que he descobert aquest software a través d’aquest howto: Network-Attached Storage With FreeNAS.

ARP Tools: arpdiscover buscant la IP dels dispositius de la xarxa

Reading time: 30 – 50 minutes

Sovint a les xarxes de les empreses hi tenim més connectades de les que recordem. O fins hi tot coses pitjors, hi ha algún dispositiu (p.exemple printserver) i no tenim ni idea de quina IP té per poder-hi connectar. Doncs amb les ARP Tools (paquet gentoo: net-analyzer/arptools) hi ha una eina que es diu arpdiscover que fa un enviament massiu de paquets ARP a la xarxa local per veure quines IPs ens contesten.

Per exemple:

$ sudo ./arpdiscover 10.19.83.1 5
using inteface eth0
our hw address is 00:11:D8:A9:D6:3B
our ip address is 10.19.83.5
bpf filter is 'ether dst 00:11:D8:A9:D6:3B && arp'
sniffer fork()ed into background with pid = 2535
request for hw address of ip address 10.19.83.1, 42 bytes to send, 42 bytes sent
received arp packet 60 bytes, hw address is 00:13:10:92:C2:E3, ip address is 10.19.83.1
request for hw address of ip address 10.19.83.2, 42 bytes to send, 42 bytes sent
request for hw address of ip address 10.19.83.3, 42 bytes to send, 42 bytes sent
request for hw address of ip address 10.19.83.4, 42 bytes to send, 42 bytes sent
request for hw address of ip address 10.19.83.5, 42 bytes to send, 42 bytes sent
waiting for sniffer terminate
sniffer terminated, exiting
scanner terminated
Scroll to Top