Category: VPN


Cito a continuación un excelente articulo extraido del sitio PineHead, interesante lectura para los sysadmin de Linux:

“You’re fired!” yells a red-headed, more or less bald guy in a suit. You’ll probably recognize this from any of a dozen comedy series. Would you like to play the role of the employee in such a scene, in real life? If you happen to be a Linux sysadmin, it’s your lucky day! We’ve got just the right tips for you. Read on for a comprehensive list of ways to make your boss hit the roof and bounce back again.

1. Write undocumented scripts

This one always works wonders. Be sure to do this with scripts that are 1) important for others to be able to work and 2) likely to need an update in about 6 months, but no earlier. Those 6 months will help your memory to forget the tricky parts of the script, so you’re actually treating yourself to a nice challenge in the future! And if somebody else might ever try to replace you, he will have a ball figuring out what all your scripts are supposed to do. Even better: do not remove or mark old versions and unused scripts, and force him to examine them all!

2. Do not keep any back-ups, or only local ones

Back-ups are cumbersome. There is a good reason that many people intend to set them up but don’t actually do it, and the reason is that they’re cumbersome. Did I say that back-ups are cumbersome? Anyway, some bosses may actually keep nagging you about back-ups until you have them configured, so if you really can’t get away without setting them up, be sure to only make back-ups within a server. Why go through all the hassle of setting up remote authentication if you can just add a simple line of cp to your personal crontab? Problem solved! Nowadays hard disks don’t fail much, right?

3. Install updates on live systems

Installing software updates is easy, right? Just whack “sudo apt-get update” and then “sudo apt-get upgrade” into the server terminal, press enter without looking, now run the command again and press “y” before enter without looking because some blundering fool made “no” the default answer, and you’re done. What’s that? The company website is down? Well, it can’t have been the update you just installed, because newer versions are always better. Go check the power cables or something. Even better: blame the employee who was just editing the site using the CMS back-end. You never trusted that software anyway.

4. Install no updates at all

So, installing updates on a live system almost got you fired for bringing the company website down. Fine, let them experience life without updates! Be sure to expose the exact version string of the web server software in the site’s HTML, then wait until the next useful exploit is found for that version. And if the script kiddies don’t find the vulnerable server fast enough, post a challenge on some obscure hacker forum offering a list of all the company’s active e-mail addresses to the first person able to deface the company website. That’ll teach ‘em!

5. Put your personal settings in global configuration files

Have you ever had to work on somebody else’s account for a short while? Having to miss all your useful aliases, color settings, vi-style hotkeys and 60 characters long PS1 is just unbearable, right? So why not put those settings in the server’s /etc/profile? That way, you can enjoy your favorite terminal settings on everyone’s account! Doesn’t life just smile at you now?

6. Do not implement redundancy

Redundancy is lame. The very word suggests what’s wrong with it: you’re wasting hardware that could be used for something awesome, like powering your BitTorrent downloads so you can watch Star Trek tonight. And what about RAID? All RAID configurations are lame, except RAID 0, because it actually makes your I/O faster. So don’t do failover configurations, versioned back-ups, mirroring disks or UPS power supplies. Say it’s against your religion or something. Bloody waste.

7. Run a different distro on every server you manage

Let’s do some simple math. Every distro has its strengths and weaknesses, and every server is used for something different. So, install a different distro on every server, to match distro strengths with function requirements. Brilliant! Make sure to complete your collection of different package managers, so that every time you need to install or update software, you get confused between apt/dpkg, apt/rpm, apt/tgz, yum/rpm, pacman, emerge and even pisi. Also, make sure to “accidentally” include a distro that barely receives any updates and delight in the mess of incompatibility that ensues. And of course, enjoy the thrill of solving a single problem in 9 different ways!

8. Eat above your keyboard

Not only does it personalize your keyboard by making it feel extra greasy and causing it to smell after a while, but also it helps you to avoid boring conversations with colleagues who do not understand your ravings about the advantages of emacs over vim. Moreover, you don’t have to hear their complaints about the current IT situation, which are only caused by their own lack of computer skills. Besides, if they really want to talk to you, they can always join you on IRC in your favorite Freenode channel, right?

9. Don’t mind file permissions

File permissions are overprotective. And cumbersome. If people can read each others’ files, there is more social control, resulting in a better working climate. Besides, nobody is stupid enough to store a password in a file. If you can remember your own 40-random-character password, they should be able to remember their variations on abc123 and qwertyuiop. Also, nobody ever stores private files on work network shares, or sensitive files for that matter. No sense in fencing things off.

10. Always keep the default configuration on software

Especially if the comment says “DO NOT LEAVE THIS ON IN A PRODUCTION ENVIRONMENT”. Default settings are always good, because if you have a problem with the software and you Google for it, people’s answers are assuming that you’re running the default settings. Makes find a solution just that little bit easier. And if you have to change a setting, do it at the bottom of the configuration file without commenting the original default setting. Much easier than having to find where that particular setting is already listed.

11. Make all servers depend on a single one to function

Single points of failure are cool. Every sysadmin needs to experience a total breakdown of the IT setup of his/her company at least once, and the more single points of failure there are, the faster that experience will come. So, by all means, make a single login server that is contacted on every login, let servers use their configuration files from a network share directly, and put critical servers in a subnet protected by some outdated version of a firewall distro. In the meanwhile, make sure allinternet traffic is routed through a proxy server that blocks traffic based on some 4 kilobyte regex you once conjured up.

12. Do not monitor your servers and certainly don’t set alerts

An appropriate supplement to the previous point! Once your carefully designed single point of failure has done its job, the lack of monitoring and alerts ensures that it takes much longer before things are back up again. Make sure to save your dullest face for the moment the first colleague walks in asking why he hasn’t been able to get anything done for over an hour. Then start (slowly) walking through the default checklist of “have you tried turning it off and on again”, “is the power cord plugged in” and “did you recently see a living unicorn”. Then, when you’re finally fixing the actual problem, the lack of monitoring and alerts ensures you won’t notice it if you break something else in the process. Good times!

13. Give your friend ssh access to the server

So, your friend would also like to do nightly BitTorrent downloads over your company’s huge internet connection. Sure thing! Just give him an ssh account, preferably without double-checking the permissions it has, and let him download away! Nobody’s bothered, right? What could possibly go wrong?

14. Do not use a firewall

Firewalls are nasty. They always get in the way when you want to do something cool, like mounting the server’s “/” directory to your phone using sshfs, or playing EVE Online at work, or streaming the webcam in the company kitchen to livestream.com. Linux is secure by definition, so firewalls are redundant, and we already established that redundancy is lame. Also, don’t do port scans, as they might advise you to change the default configuration, which is against tip #10.

15. Copy huge files over the company internet connection without bandwidth limits

Sometimes, you have to copy a large amount of data to some machine outside the company. It could be a back-up, but that would violate tip #2, so let’s say your external hard drive is full and you want to copy the latest 1080p uncompressed Doctor Who episode to your home computer over the internet. Well, doesn’t that seem like an excellent moment to test the upload bandwidth of the company internet connection? Not only is this a useful statistic to know, but it will also get your 300 gigabytes of sci-fi goodness home that much sooner! Perhaps it will make Reddit load a bit slow on your pc, but fortunately, there’s an app for that!

16. Take home confidential files on an unencrypted usb pendrive

And by tip #2, don’t have a back-up of them either. You won’t be as stupid as those people who lost important pendrives in public transport or things like that. Also, pendrives never fail. And encryption just wastes space and CPU cycles.

17. Always leave the physical terminal of every server logged in

It’ll save you a few keystrokes and some racking your brain for the password. No one else will ever even think of touching the server’s physical terminal, right? No colleagues, cleaners, janitors and certainly no hackers, who always play by the rules and hack over the internet. Completely safe, this.

18. Find the cheapest hosting for the company website

And put the company personnel database on the same hosting account. How could a dollar a month ever be wrong? Besides, shared hosting makes the company website feel less lonely. And if it loads slow (if at all) or suddenly gets hacked, you have the hosting provider to point at instead of taking the blame yourself. Think about it! No need to apply updates, no configuration files to crack your brains over, easy phpMyAdmin access (preferably without SSL) and a fancy control panel to click around in. Oh, and “99% uptime guaranteed” means the website isn’t down for more than 7.44 hours a month, or you’ll get your dollar back!

19. Use the same password on every server

And preferably a password that you also use in your private life. Look at how fast you can type this password because you type it all day! Share this achievement with all your Facebook friends and be considered the most awesome geek they know!

20. Enable root login in sshd_config

Having to su or type sudo all the time is cumbersome bothersome (back-ups are cumbersome, remember?). Therefore, enable root login for ssh, keep it running on the default port (saves typing -pevery time) and use a short root password for convenience. Now, when you see strange failed authentication warnings for the root account in the sshd logs (presuming you actually check those at all), comfort yourself by saying that they will never guess that your short root password is l3tm31n instead of letmein.

21. Change the server network configuration over ssh

And don’t add a timed reversal script or anything like that. Locking yourself out won’t happen to you like it happened to so many others, because of your secret years of ninja training. Or whatever. Bonus points if you don’t have physical access to the server.

22. Don’t invest in your Linux knowledge

Stay away from the other articles on this site, and especially from linuxacademy.com. Block it in your firewall! Wait, you don’t have one because of tip #14. Ahem! Change the ip to 127.0.0.1 in /etc/hosts! This site is insolent enough to presume that you could possibly learn anything about Linux. The arrogance! Your vast knowledge is unparalleled! Besides, copy-pasting solutions from Google always works, so there’s no need to understand anything about them.

Fuente: http://tuts.pinehead.tv/2012/10/10/how-to-make-your-boss-angry-bad-linux-sysadmin-practices/

Hamachi  es una solución provista por la empresa LogMeIn que permite implementar de manera rápida y fácil una solución de VPN en aquellas redes donde nos encontramos con gateways con restricciones de acceso, basta con bajar un aplicativo cliente e instalarlo para crear  nuestras redes “privadas” y agregar equipos a ellas.

Antes de trabajar con Hamachi ya había implementado redes privadas virtuales en Linux con  pptp, openvpn y otras herramientas, y la verdad que con estas soluciones siempre tuve que  disponer de uno a un par de  puertos  públicos habilitados para poder validarme y establecer el vinculo desde los equipos clientes hacia las subredes privadas  situadas detrás de un server que corría el servidor de vpn, también necesitaba de ciertos privilegios  para aplicar cambios en la configuración del gateway de salida a  Internet.  Con Hamachi esta visión cambio dado que la conexión de los clientes se establece hacia la nube, lo cual elimina las restricciones antes mencionada. Desde el aplicativo  podemos crear VPNs y asociarlas a una contraseña, misma que deberá tener cada equipo que vaya a unirse a la red. La arquitectura de conexión de los equipos en la versión libre de Hamachi permite tener hasta un máximo de 16 equipos unidos por red y en la versión comercial hasta 256.

Los instaladores de la version 2 para Linux se pueden bajar desde aqui:

https://secure.logmein.com/labs/

Lo bueno en mi caso, ya que trabajo en una gran parte con sistemas Debian, es que estan disponibles  los paquetes .deb, tanto para arquitecturas de 32 y 64 bits,  también hay paquetes en formato  .rpm y .tgz.

Algunos comandos de hamachi2 en consola

Para operar con hamachi es necesario iniciar el correspondiente servicio. En sistemas  basados en Debian el demonio se ubica en /etc/init.d y  se arranca con :

# /etc/init.d/logmein-hamachi start

Una medida de seguridad para no ejecutar los comandos habituales como usuario root es especificar en el archivo h2-engine-override.cfg otro usuario normal de sistema. Para ello debemos crear archivo en :

/var/lib/logmein-hamachi/h2-engine-override.cfg

y agregarle la siguiente linea:

Ipc.User         MiUsuario

Este archivo sirve para setear algunos valores por defecto para el servicio, tales como  recordar contraseñas de acceso a redes, proxy de salida a internet y otros.

Algunos comandos básicos para trabajar con Hamachi en consola:

Establecer conexión con la red de Hamachi:

$ hamachi login

Para crear  una red:

$ hamachi create NOMBRE_DE_RED PASSWORD

(si no se especifica una contraseña de acceso se solicita a continuación)

Unir el equipo actual a una red determinada:

$ hamachi join NOMBRE_DE_RED

Establecer un ID de red, este nombre sera con el que nos visualizaran otros miembros de la red:

$ hamachi set-nick APODO_DE_PC

Listar las estaciones y redes en las que estamos:

$ hamachi list

deberia visualizar algo asi:

 $ hamachi list
 * [VPNWorking007]
       084-117-321   mami                       5.5.53.21
       083-007-603   cigarra                    5.18.6.92
       084-182-025   mona                       5.13.219.234
     * 081-254-316   verdulera                  5.52.140.58    via server  TCP
       083-324-547   licuadora                  5.51.236.176
       083-861-081   sabandija                  5.92.53.168
       098-845-416   peper                      5.121.121.142
       091-045-595   anonymous                  5.139.128.135
       092-402-648   lagartillo                 5.156.181.226
 * [VPNCasera]
       085-054-603   cigarra                    5.18.6.92
       087-389-571   sodipodi                   5.39.224.253
     * 091-332-879   casita                     5.117.152.16   via relay   TCP

En el listado se observa que estoy unido a dos redes , VPNWorking007 tiene 9 nodos unidos, y VPNCasera tiene 3, y se ve que hay un equipo (cigarra) en común en ambas redes .

Si sos mas de las ventanitas…

Y de ves en cuando ando algo vago y no quiero tipear todo asi que bue, me baje e instale haguichi, un Gui para hamachi2 , ciertamente hay que tener instalado hamachi en el sistema.

 Url de descarga: http://www.haguichi.net/

Versiones viejas para Linux

Buscando por la red encontré una version 0.9 de Hamachi para Linux, es totalmente funcional al dia de la fecha, la contra que tiene es que no hay versiones disponibles para plataformas de 64 bits y que si bien una vez que la tenemos funcionando permite conectarse a otras redes  no permite acceder a otros  equipos que no tengan instalada la misma version.

Un punto bueno, si se lo puede ver asi,  es que esta versión es  una alternativa para aquellos equipos con distribuciones Linux viejas y con  arquitectura de 32 bits donde no pueda instalarse la version 2 de hamachi.

Url de descarga: http://files.hamachi.cc/linux/

En conclusión

Hamachi me ha salvado de horas de viaje  hasta equipos ubicados en  entornos  donde me he visto restringido de realizar algún tipo de gestion en los permisos de accesos desde/hacia Internet y  por consiguiente impedido de  implementar otras alternativas.  También ha sido de mi agrado la disponibilidad de esta herramienta para plataformas windows, linux y mac, puesto que cubre el espectro de arquitecturas en las que usualmente trabajo.  Tal cual dice la leyenda de hamachi , es una herramienta de cero configuración y así es como ha sido,  fácil , y rápido.  Aun así me reservo un grado de paranoia al momento de recordarme algo que no me cae bien en los servicios Cloud,  y que  es algo inherente a ellos ,  el desconocimiento que tiene el usuario acerca de lo “que se hace” y “como se hace ” dentro de la dichosa nube, mas aun en permitir el trafico de una parte de nuestra red privada a través de un servidor de terceros.

En lo que respecta a los resultados de  mis búsquedas aun no he podido  encontrar una alternativa similar en software libre, algo que es de mi preferencia.