This is me, Wu!
August 2015
Sun Mon Tue Wed Thu Fri Sat
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
About
This site is an effort to share some of the base knowledge I have gathered through all this years working with Linux, FreeBSD, OpenBSD, Python or Zope, among others. So, take a look around and I hope you will find the contents useful.
Recent Entries
Recent Comments
Recent Trackbacks
Categories
OpenBSD (8 items)
BSD (0 items)
FreeBSD (19 items)
Linux (3 items)
Security (3 items)
Python (18 items)
Zope (13 items)
Daily (139 items)
e-shell (9 items)
Hacks (14 items)
PostgreSQL (3 items)
OSX (8 items)
Nintendo DS (0 items)
enlightenment (0 items)
Apache (3 items)
Nintendo Wii (1 items)
Django (23 items)
Music (12 items)
Plone (7 items)
Varnish (0 items)
Lugo (2 items)
Sendmail (0 items)
europython (7 items)
Cherokee (1 items)
self (1 items)
Nature (1 items)
Hiking (0 items)
uwsgi (0 items)
nginx (0 items)
cycling (2 items)
Networking (1 items)
DNS (0 items)
Archives
Links

Syndicate this site (XML)

RSS/RDF 0.91

23 agosto
2015

My personal review of the Kona Jake 2014

... short story: I love it!

So, now that I've officially announced my new bicycle, which I've been riding for almost a year now, it is time already to give a more detailed review of it.

The specs for the 2014 model of the Kona Jake can be found here:

http://2014.konaworld.com/jake.cfm

I'm not an expert, in fact I'm pretty clueless about techie stuff regarding bicycles, so take your time going through them and getting your own conclusions.

My Jake's size is 53cm. I can't tell you exactly the measures/distances of the seat post, reach, etc (I didn't measure them, I just tried until I got to something that fits me and feels comfortable). What I can do is show you a pic of what the bike looks like now:

Me and the Jake, so you can get an idea of the height/distances

Continue reading "My personal review of the Kona Jake 2014"
Posted by wu at 13:12 | Comments (0) | Trackbacks (0)
15 agosto
2015

Got a new bike (II)

Well, actually I got it one year ago O:)

My new Kona Jake 2014

What can I say? I guess the cycling bug bit me already and now there is nothing we can do to stop it.

Since I got the Giant Argento two years ago, I started to go on slightly longer rides. That bike felt (and still feels) great, it was a good choice back then but, at one point, I started to feel like if I'd need something more road oriented. The Argento is a really nice bike for moving around town and for some relaxing offroad rides (specially when we talk about mud/sand/dirt slippery paths) but as soon as you try to go on a road for more than 20-30 kms, and specially if you want to go a bit faster, it is not the best choice.

And so my search for a new bike began.

Continue reading "Got a new bike (II)"
Posted by wu at 11:08 | Comments (0) | Trackbacks (0)
08 agosto
2015

Unexpected https connections coming out of my laptop

or why you have to be careful with default setups

Today, while debugging some local network connections with netstat in my laptop (running OSX 10.8.5) I noticed a very weird thing:

tcp4       0      0  192.168.43.201.56227   17.143.164.144.443     ESTABLISHED

"A connection to https somewhere, while all I'm doing is debug some local stuff in a shell and edit some files in emacs?" - I thought. Something smell badly.

I did a whois on the ip address:

whois 17.143.164.144

And I saw there to whom the address belong:

OrgName:        Apple Inc.
OrgId:          APPLEC-1-Z
Address:        20400 Stevens Creek Blvd., City Center Bldg 3
City:           Cupertino
StateProv:      CA
PostalCode:     95014
Country:        US
RegDate:        2009-12-14
Updated:        2011-03-08
Ref:            http://whois.arin.net/rest/org/APPLEC-1-Z

"Ok, this has to be one of those services running by default on the background by OSx then, let's find out which one" - I told myself.

At first thought I decided to use netstat itself to find out which process was sending such a long-term request (the connection did stay open for quite some time). Too bad OSX's netstat does not have a -p flag to show the processes (or at least not in this OSx version). OSx's fuser cannot be used for that purpose neither, and it does not have FreeBSD's sockstat or fstat tools.

It has lsof though, which is good enough for the job:

sudo lsof -n -i 4 -a|grep 56227

There it was:

apsd        317           root   10u  IPv4 0xf041bb92eb553d51      0t0  TCP 192.168.43.201:56227->17.143.164.144:https (ESTABLISHED)

"apsd? wtf is apsd?" - Question popped in my mind, and all of a sudden the name become familiar - "I'd say we have met before... let's look at the man page":

APSD(8)                   BSD System Manager's Manual                  APSD(8)

NAME
     apsd -- Apple Push Notification service daemon

SYNOPSIS
     apsd

DESCRIPTION
     apsd ApplePushService daemon for Apple Push Notification service.  This
     is part of the ApplePushService framework.

     There are no configuration options to apsd.  Users should not run apsd
     manually.

Mac OS X                         Feb 10, 2009                         Mac OS X

HA!, I loved this part: "Users should not run apsd manually", which we could translate into "Hey you!, do not mess with this stuff that could be sending some data back to us here!".

The man page did not return too much info, but a bit of searching through the Internet for Apple Push Notification service daemon returned a couple of helpful links:

Good enough for me (specially the second one). A quick read through the documentation told me that this probably is used by Apple to send me upgrade notifications and things like that, which I don't care about, specially when I'm working from a remote location, connected through my mobile phone and a limited bandwidth line.

So, I did shut it down:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.apsd.plist

(turn it back on is easy, just replace unload with load there).

Finally, I added this alias to my ~./profile, so I could list processes listening on tcp4 ports quickly:

alias tcp4_procs='sudo lsof -n -i 4 -a'

(sudo is needed in order to see process my user does not own).

Posted by wu at 08:23 | Comments (0) | Trackbacks (0)
14 julio
2015

Juniper NetworkConnect for OSx

nice to know if you need to quickly connect to a Juniper VPN

Some days ago I got this support request from a customer, asking me if I could take a look at some servers in trouble (someone got in and they wanted to see if any backdoor was left behind, even if they already cleaned the server).

"Sure" - I replied - "just gimme access over SSH and I'll take a look"

All I got instead was an email with an https address, user, password and the words it is a Juniper VPN.

"Ok" - I thought - "let's get a client to connect to that vpn"

It wasn't that easy though. I went to Juniper's downloads website, but in order to download anything, it seemed that first I should know which kind of Juniper product they had installed there.

Reading a bit more, it seems those VPNs over https work directly from the browser. You only had to open that url and identify yourself, and a plugin should run some kind of Java application and open the connection to the VPN.

Well, that did not work for me. For some reason it kept telling me I had a missing plugin and when trying to find out which plugin that was, it was sending me to the Java download page (even if I've Java installed already).

This being a momentary access to a server I won't be accesing anymore, the least thing I wanted was to start installing stuff on my laptop "a lo loco". So I was in kind of a dead end, and I could not connect to the server.

Searching a bit further down Internet Lane, I found this post here: Manually download the Juniper VPN client for mac, which probed to be quite useful.

It seems you can get the proper version of NetworkConnect for OSx directly from the VPN service itself. All you have to do is open the VPN url in your browser, log in, and then access this url:

/dana-cached/nc/NetworkConnect.dmg

For example, if the address of the VPN is https://my-juniper-vpn, it should be something like:

https://my-juniper-vpn/dana-cached/nc/NetworkConnect.dmg

Download that and proceed with the install. After opening it for the first time, you will have to provide the https url for the vpn, then the login credentials. Done.

Finally I had access to the server and I was able to confirm there were some backdoors in there, time for some clean up!

Also, a ver interesting link for the time you are done with the Juniper VPN, if you don't need it anymore, how to uninstall/remove it completely:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB16265

Posted by wu at 06:26 | Comments (1) | Trackbacks (0)
30 junio
2015

Bogons in your DNS setup

Nothing is forever, you know

This morning, on IRC, my friend betabug reported that he had some problems while trying to resolve a domain name which DNS servers are under my control.

Each time he queried any of those servers, he got a timeout.

We went through a debugging process, but we weren't lucky. We found nothing that could have been causing such a behaviour.

Until I asked the magic question, which opened the door to where the problem was laying:

10:00 < Wu> betabug: which is your ip address there?
10:01 < betabug> Wu: 127.0.0.1
10:02 < Wu> public ip address ;D
10:02 < betabug> hahahaha
10:02 < betabug> 2.84.XX.XXX
10:02 < betabug> nice ip

Somehow that ip address in the 2.0.0.0 block looked a bit suspicious. I checked the named.conf file in one of the DNS servers and...

acl "bogon" {
      0.0.0.0/8;
      1.0.0.0/8;
      2.0.0.0/8;
      10.0.0.0/8;
      192.0.2.0/24;
      172.16.0.0/12;
      224.0.0.0/3;
};

And a bit further down the config file:

blackhole { bogon; };

This means that any ip address in those ranges will be kind of blacklisted for the DNS server.

And now, probably, you are asking yourself why this guy blocks those ranges?. Well, to understand why, first you have to know what a bogon is. One good explanation can be found here: http://packetlife.net/blog/2009/jan/21/whats-bogon

A bogon route is a type of route which shouldn't exist on the
global Internet. More specifically, "bogon" (derived from the
word "bogus") refers to an advertisement for a prefix within a
reserved or otherwise unallocated IP network.

Team Cymru has also a couple of interesting pages about bogons:

So, it seems that in the last days of the ipv4 era, registrars are opening/releasing blocks that have been reserved since the beginning. This means that my DNS servers have been blocking queries from licit ip addresses on those ranges for some time.

Removing them was easy, problem solved.

Reminder: Even as this all will change when the last of the ipv4 block is sold out, take care, as stated in The bogon reference that:

It is important to realize that the bogon and fullbogon lists are NOT static lists.

Posted by wu at 10:20 | Comments (0) | Trackbacks (0)
19 febrero
2014

Setup chroot for bind 9 in FreeBSD 10

simple instructions if you are upgrading from freebsd 8.x or 9.x

FreeBSD 10 has been released some days ago and this new version comes with lots of new stuff (just take a look at the release notes to learn more about it).

One of those changes is the removal of BIND from the base system, being it replaced by Unbound. More information about this move from the FreeBSD project can be found here:

Maybe you would find interesting this thread from the freebsd-stable mailing list too:

http://blog.des.no/2013/09/dns-again-a-clarification/

(also available here: http://marc.info/?t=138606115200005&r=2&w=2)

There some people complain about the differences between the scripts and setup we had in the base system vs what is available in the bind9 port. Setting up a chrooted dns server was quite easy when BIND was in the base system, as the configuration files and rc.d scripts were already prepared for such a setup, but it seems that what is installed by the port does not handle that so well.

Or so it seems...

These are the steps I followed to keep my BIND servers chrooted after upgrading to FreeBSD 10:

Warning: The following assumes you have a default BIND setup, chrooted under /var/named and with all the config files in /etc/namedb, which should be a symbolic link to /var/named/etc/namedb.

  1. Install BIND 9.x from ports:

    cd /usr/ports/dns/bind99 && sudo make install clean
    

    or, if you prefer to use pre-built packages:

    sudo pkg install bind99
    
  2. The port/package will install the configuration files under /usr/local/etc/namedb, move them aside:

    sudo mv /usr/local/etc/namedb /usr/local/etc/namedb.default
    
  3. Link the existing configuration from our previously chrooted setup to the place where the port will look for them:

    sudo ln -s /var/named/etc/namedb /usr/local/etc/namedb
    
  4. Now, as the configuration files have been moved from /etc/namedb to /usr/local/etc/namedb, we have to recreate such a route inside the chroot environment, ensuring the management scripts will find the configuration files:

    sudo mkdir -p /var/named/usr/local
    
    cd /var/named/usr/local && sudo ln -s ../../etc .
    
  5. Remove the old link under /etc:

    sudo rm /etc/namedb
    
  6. Create a custom devfs ruleset to be used with our chroot environment, adding the following to /etc/devfs.rules:

    # Custom rules for the named chroot dev
    [devfsrules_named_chroot=4]
    add hide
    add path run unhide
    add path random unhide
    
  7. Mount the devfs filesystem from the chroot environment. First add the following to /etc/fstab:

    devfs             /var/named/dev  devfs   rw,ruleset=4      0     0
    

    Then mount it:

    sudo mount /var/named/dev
    
  8. Enable chroot when starting BIND, adding the following line to /etc/rc.conf:

    named_flags="-t /var/named"
    

    You don't have to set the -u flag, because it is already passed by the rc.d script (user bind).

  9. Fix the /usr/local/etc/rc.d/named script, so it will be able to find the proper pidfile when stopping the daemon. Add the following line inside the named_stop() function, just below find_pidfile:

    test "${named_flags#*-t}" != "$named_flags" && pidfile="/var/named${pidfile}"
    

    This will check for the presence of the -t flag in the provided flags and, if exists, will add the path of our chroot directory to the already existing pid file path.

  10. Start BIND:

    sudo /usr/local/etc/rc.d/named start
    

et voilà, BIND should be running now, chrooted under /var/named as user bind, just like in your previous setup.

UPDATE 2014-02-25: Added the mount of the devfs filesystem as mentioned by APz in the comments.

Posted by wu at 12:08 | Comments (12) | Trackbacks (0)
09 agosto
2013

Got a new bike

and it took damned too long to get it!

Me and the new bike

I already wrote some stuff about my habit of moving around town by bycicle (here and here too for example) so this won't be a surprise.

For the last few years I've been riding an old mountain bike that wasn't even mine to begin with (dolo's brother wasn't using it at all, so I just borrowed it) and lately I've been riding my father's old trekking bike, which was nicer than the mountain bike, but not my bike:

This is the old MTB I've been ride for some time This is my father's old trekking bike

Also, after getting the bike trailer for lara, we have been doing rides^excursions more often now (dolo, lara and me) and we didn't have a bike that was really comfortable for dolo, so we started to think about getting a new bike for both of us (a proper one for her, and one for me so we could return those bikes to their real owners).

So, for now we have bought a Giant Argento rs4 GTS (from a local dealer, mtcbicis). The plan is that I will use this one when going for lone rides, and dolo will use it during family rides. This will get me back to the old mountain bike, but I don't think it will take too much time for dolo to decide herself about which new bike we should get for her.

The argento, tron-style The same pic as before, but without using the flash to take it Another shot of the new bike, different perspective.

UPDATE: This evening I did a test ride (around 7.5 kms) and the bike is really really good. Fast, comfortable... Really worth the money we've put in it.

Posted by wu at 09:41 | Comments (1) | Trackbacks (0)