Este es mi blog. Hay otros muchos pero este es el mío.
Via Applesfera I’ve learnt about two applications developed by Hanynet that allow you to manage the internal firewall on MacOS X Leopard:
Very useful.
One detail about VPNs that I’ve learnt this week the hard way:
If you want to use a VPN as your default gateway and not only to reach some private networks, you have to add first a static route to reach the VPN server through your current gateway.
It may not be very obvious but it’s quite logical: in order to start and maintain the VPN, you need to have network connectivity with the VPN server, that isn’t on our local network, so we reach it through our default gateway (the DSL router or whatever). Once the VPN is up, the “in transit” VPN is just TCP, UDP or some other protocol packets flowing from your host, through your gateway, and reaching the VPN server, that “unpacks” the actual VPN traffic. And what happens if now we set a default gateway on the other side of the VPN connection? It “overwrites” the previous GW, the DSL router. The new GW is not on our real local network anymore, we can’t reach it, so our “in transit” VPN packets can’t get to the VPN server.
Think about it. It’s quite silly, but it’s one of those things that get set up for you when configuring a VPN using a GUI, and you don’t even realize about them until you have to deal with things at a lower level (configuring a router, dealing with a server config files, etc.)
A través de éste artículo del blog de Enrique Dans doy con otro de un abogado poniendo de vuelta y media los avisos de confidencialidad en los correos electrónicos. Muy recomendables ambos así como sus comentarios.
No me voy a extender demasiado porque suscribo punto por punto todo lo que comenta Enrique: siempre me han parecido una bobada, nadie puede obligarme a nada sólo por el hecho de leer un texto que, además, viene después de la información sobre la que pretende imponerme esas obligaciones. Es de locos. Pero todos hemos visto cómo después de que algún “jefecillo espabilao” se lo pusiera en la empresa, ha habido más de tres y cuatro borregos que han hecho copy-paste en su firma para parecer más… ¿más? Y copiando unos de otros, al final media empresa con el disclaimer dichoso sin saber muy bien cómo ni por qué, pero ¡mola!. Una moda más, y como todas las modas, “sin chicha ni limoná”.
Aparte de al borreguismo, lo achaco a que todavía hay mucha gente que no está preparada (por así decirlo) para las nuevas tecnologías, y a alguna mente pensante (igual de poco apta con éstas cosas) se le ocurrió la genial idea de éstos textos para lavarse las manos ante las inevitables meteduras de pata propias y agenas.
Lo que está claro es que si el mensaje llega, llega a su destinatario. Por definición. El que pone en el “To:”. Ni el MUA ni el MTA van a meter la pata, si hay error será humano y en el lado del remitente “de gatillo fácil”.
Los problemas que veo son:
En fin, que si, que éstas cláusulas se ponen porque existe un problema, eso no lo niego. Pero no son la solución, no aportan nada, sólo más confusión.
Y menos mal que había dicho que no me iba a enrollar… XD
WordPress MU 1.3.2 has been released. It gets the project in sync with WordPress 2.3.2 and besides that adds several WPMU-specific security fixes, so it’s a must.
The full package is available for download here. If you already have the previous release installed (simply 1.3, but it was in sync with WP 2.3.1) you can use the following patch to upgrade it more easily: wpmu-1_3-1_3_2.diff
It has happened to me a cuple of times when dealing with UDP-based services that, when a server has more than one network interface (either physical or virtual), all the UDP traffic goes out through the interface on the default gateway’s network segment and with that interface’s IP address, even when the original request came through the other interface and was directed to the other IP address.
Graphically, say you have something similar to this:
If the server receives a request on IPa, the response goes out through that same interface and with origin IPa. But if the request arrives on IPb through the interface on the right, the response is also sent through the left interface with IPa. And what happens when the client receives a response from an incorrect IP address? Maybe even from a completely different network segment? And if there’s a fw in between doing NAT?
Of course this breaks the service. This week I’ve had this very problem setting up a L2TP VPN, and it was impossible to establish the tunnel. On some other ocasions I’ve had a similar problem with a DNS server, and the outcome depended on the client’s operating system: some OSes accepted the DNS response even when it came from a different address than that of the server originally queried; others would reject it and even raise a security alert.
I guess that this behaviour can be programmatically controlled. I mean, when you receive a packet you can check the IP address it was sent to, and craft the response so that it gets sent with that same address from the right interface. But it seems that this is seldom done.
Yesterday I got around this issue with the help of iptables and a coworker more knowledgeable than me on routing issues:
An example for redirecting all UDP traffic from a certain $PORT using IP address $IPb through gateway $GWb would be:
Some days ago, a coworker posted on his blog an article about how to serve several HTTPS sites from a single IP address using TLS. I told him that it was easier to use a single X.509 certificate for all those domains with the subjectAltName attribute, and he dared me to write a howto about it.
I’ve done something better: I’ve modified easy-rsa so that it can generate multi-domain certs.
A couple of days ago I stumbled upon the SaneSecurity set of ClamAV signatures, that detect a lot of SPAM (mainly the latest batch of GIF and PDF SPAM) and phishing mails. They’re similar to the MSRBL signatures, only better judging by the results we’re getting. Or to put it another way, one is the perfect complement to the other. :)
By using these two ClamAV signature sets together and some other techniques (SpamAssassin, DNS, RBL…) we’re stopping at work around 80% of all the mails we get, 100000-120000 daily, with a very low false-positive ratio, 2-3 weekly at most. And these figures include all the internal mails too which are supposed not to be SPAM, I’m sure the real SPAM blocking ratio (just external mails) in our system is way above 90%. One of these days I’ll do the math.
I’ve been thinking for some time about writing an article about the different anti-SPAM techniques we use here. I’ll see if I can get some free time to do it…
I’ve just uploaded the 1.22.1 release of the osCommerce RSS feed with e-Commerce support, which fixes a security bug that made possible a SQL Injection attack.
Credit and thanks go to Jim Nanney for the heads up. More info here.
Dando vueltas por Internete buscando ya no me acuerdo qué (tíiipico) he dado con la bitácora en Barrapunto de Gufete (link a su web). Tiene varios artículos bastante interesantes, en concreto estos dos sobre temas que siempre nos traen de cabeza en el trabajo:
Eso en cuanto a la parte técnica. En cuanto a “qué mal que está el patio”, tiene otro interesante artículo sobre la triste realidad de la profesión de Ingeniero Informático en nuestro país, con el que (tristemente) no podría estar más de acuerdo. :-/ Algún día tengo que escribir algo yo también sobre el tema, aunque más que en plan “que malos los empresarios que no nos pagan una mierda” iría por “qué poca iniciativa tenemos y qué conformistas somos que sabiendo lo mal que está la cosa sólo nos quejamos en vez de echarle dos huevos y montar algo por nuestra cuenta” (que es por donde va al final el artículo de Gufete).
Últimos comentarios
RSS