GO - Create a dependency graph en

By Spider.007 on Wednesday 04 December 2013 11:02 - Comments are closed
Category: go, Views: 1.931

Creating a dependency graph for your go file is simple; but I couldn't really find what I needed; so I created this simple script. It creates graphs from the `go list` output. Usage is simple, install graphviz and type:

$ go build dependency-graph.go
$ ./dependency-graph FILE.go | dot -Tpng > FILE.png


You can also pass go-packages as starting point:
$ ./dependency-graph net/mail | dot -Tpng > FILE.png


The code:

go:
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
package main

import (
    "encoding/json"
    "fmt"
    "os"
    "os/exec"
)

type goList struct {
    Imports []string
}

var done = make(map[string]bool)

func getDeps(p string) []string {
    o, err := exec.Command("go", "list", "-json", p).Output()

    if err != nil {
        fmt.Fprintf(os.Stderr, "Error: %s", err)
    }

    list := goList{}
    json.Unmarshal(o, &list)

    return list.Imports
}

func printRecursive(p string) {
    done[p] = true

    for _, d := range getDeps(p) {
        fmt.Printf("\t\"%s\" -- \"%s\";\n", p, d)

        if !done[d] {
            printRecursive(d)
        }
    }
}

func main() {
    fmt.Println("graph G {")
    printRecursive(os.Args[1])
    fmt.Println("}")
}

A safe backup-server with rsync, chroot and forced commands en

By Spider.007 on Saturday 10 November 2012 14:59 - Comments (4)
Category: code, Views: 4.196

I recently needed to create a backup-server, and since my final solution was not described anywhere so I decided to show you how I did this. While creating solutions like this, I like to think about the worst possible situations I needed to prevent. So lets assume:
  • Compromised clients shouldn't affect backups from other clients
  • Compromised clients shouldn't be able to access parts of the server they shouldn't
  • Adding new clients shouldn't cause any downtime for existing clients
  • The 'management' overhead of the solution should be minimal
This is what I came up with; first of all we are going to create a chroot for a user called 'backup', to prevent this user from accessing anything except backups. Start with useradd -m backup (all these command should be executed as root).

We will create this chroot in /srv/rsync/ using a simple script which uses ldd to copy binaries and their libraries to our chroot:

Put the following in /srv/rsync/bin/chroot_update and chmod it executable, then execute it too:
bash:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#!/bin/bash
cd `dirname $0`/../
mkdir -p ./bin ./usr/bin ./.lock/

function mcp {
    [[ ! -d .`dirname $1` ]] && mkdir -p .`dirname $1`
    cp -v $1 .$1
}

mcp `ldd /bin/bash | grep ld-linux | cut -d' ' -f1`

for b in bash rsync ln rm date mkdir
do
    b=`which $b`
    cp -v $b .$b
    ldd $b | cut -d' ' -f3 | while read l
    do
        [[ -z $l || -f .$l ]] && continue
        mcp $l
    done
done

Test if the chroot is functional by executing chroot /srv/rsync rsync. Now we'll setup our sshd, add the following lines to /etc/ssh/sshd_config and restart your sshd
code:
1
2
3
Match user backup
        ChrootDirectory /srv/rsync
        AllowTcpForwarding no
With our chroot we have shielded the backup environment from the rest of the server; but we still need to make sure clients can only access their own backups. We'll use ForcedCommands for this, combined with (passwordless) ssh keys. Also, in this example I will restrict the source IP, to allow only a single host from using this key. This line should be put in /home/backup/.ssh/authorized_keys, and you should repeat this for each client you add (obviously you need to use your own public key instead of our RANDOM version):

code:
1
from="192.168.7.*",command="/bin/rsync_wrapper client.example.com" ssh-rsa ssh-rsa AAARANDOM== root@client.example.com


An additional advantage of this forced command is that we can define most of the rsync options in our script, making it easy to configure clients. For example, we don't need our clients to specify the target-directory on the server. Our wrapper will also take care of locking, so a single client cannot connect multiple times simultaneously.

Put this script in /srv/rsync/bin/rsync_wrapper and chmod it executable:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#!/bin/bash
# this will be a forced command which passes the hostname as first argument
set -e
HOST=$1

if [[ -f /.lock/$HOST ]]
then
    echo ERROR: Target $HOST is locked >&2
    exit 1
else
    trap "{ c=$? ; rm -f /.lock/$HOST ; exit $c ; }" EXIT
    >/.lock/$HOST
fi
# echo DEBUG: $SSH_ORIGINAL_COMMAND >&2

[[ ! -d /backups/$HOST/ ]] && mkdir /backups/$HOST/
rsync --server -logDtprxze.iLsf --delete-during --delete-excluded . /backups/$HOST/

Testing this setup from our client is pretty easy; just execute rsync using your preferred source directories and possible excludes:
code:
1
rsync -xaz --delete --exclude=*.mp3 /home/ /etc backup@server.example.com:/

Notice how we don't define a target directory, since our forced-command will ignore this. The --delete is necessary for our client to understand the output from our server (which also uses --delete). Extending this setup with hard links is trivial.

You know you've got to Back the fuck up

KPN Glasvezel zonder Experia box

Door Spider.007 op zaterdag 24 maart 2012 15:30 - Reacties (22)
Categorieën: hack, internet, Views: 20.230

Al enige tijd had ik thuis een glasvezelverbinding van KPN die via de Experia box (een ZTE zxv10 H220N) liep. KPN zelf noemt dit apparaat soms zelfs de 'modem', dus je zou denken dat je daar niet zomaar een Draytek tegenaan kan hangen. Vandaag had besloten eens te kijken of dit magische kasje eruit valt te halen; en dat is mogelijk en bleek niet zo moeilijk. Ik gebruik overigens alleen internet en geen TV / telefonie via deze aansluiting.

In mijn Draytek 2130n heb ik de volgende instellingen doorgevoerd:

Connection type: PPPoE
Username: kpn@direct-adsl
Password: KPN
Fixed IP: No
Clone MAC: Yes
MAC Address: (overgenomen van Experia Box)

Dit is nog niet alles, onder Multi-VLAN moet je ook dit nog instellen:

Enable: Yes
WAN VLAN ID: 6

Gebruikte bronnen:Dit instellen was voor mij voldoende om keihard te kunnen internetten ;)

NetQ noemt beveiligingsfout 'een feature'

Door Spider.007 op maandag 28 november 2011 22:57 - Reacties (12)
Categorieën: code, hack, internet, Views: 3.023

Vrijdag kwam op T.net het artikel reviews: Een datalek: wat nu? voorbij. Het niveau van de gegeven tips is dusdanig basaal dat je zou denken dat elk persoon met enige ervaring op het internet hetzelfde allang bedacht heeft.

Toch vergaat het lachen je al snel als je bedenkt dat ook basale fouten door grote bedrijven worden gemaakt; en wel door bedrijven die omgaan met jouw informatie. Of dit nou persoonsgegevens zijn die je niet wilt laten lekken; of enquêtes op basis waarvan andere bedrijven beslissingen nemen; het blijft toch informatie waarvan je hoopt dat deze veilig verzameld, opgeslagen en ontsloten wordt.
Nadat ik mij eerder had verbaasd over de daadwerkelijke vragen in een enquête, ben ik afgelopen week bezig geweest om een bedrijf te overtuigen van een beveiligingslek.

Dit keer ging het om Oasen die via NetQ een enquête afneemt. NetQ is een bedrijf wat als primaire bezigheid het aanbieden van een online enquête-tool heeft. Je zou verwachten dat beveiliging hier een belangrijk onderdeel van de bedrijfsvoering is, maar de praktijk wijst anders uit.

De uitnodiging die ik ontving, leidde mij naar een website en bevatte een unieke identifier die mij identificeert. Deze bestond uit een UUID, die eigenlijk gegarandeerd uniek is.

Tot zo verre geen probleem, maar ik dacht; laat ik eens twee karakters aan het einde van mijn UUID weghalen. Tot mijn verbazing stuurde de applicatie mij terug naar het originele UUID. Natuurlijk probeerde ik direct hoeveel karakters ik dan kon weghalen. Hier kwam ik tot de conclusie dat het merendeel van de karakters kon worden verwijderd. Uiteindelijk had ik van de oorspronkelijke 32 karakters nog 4 karakters over; en dit bleek genoeg om een enquête op te halen, en in te vullen.

Van de oorspronkelijke 340.282.366.920.938.463.463.374.607.431.768.211.456 opties bleven er dus nog 65.536 over. Dit is een fout die zo evident is dat het weinig moeite zou moeten kosten om de ontwikkelaars hiervan te overtuigen. Grappig genoeg is dat me niet gelukt.

Uiteraard heb ik direct netjes contact opgenomen met NetQ, en na enkele malen telefonisch en per e-mail het probleem te hebben toegelicht kreeg ik uiteindelijk de volgende reactie:
[...]

Dit is destijds expres zo ontworpen omdat meerdere situaties denkbaar zijn waarin respondenten een incomplete link gebruiken.

[...]

omdat het niet bekend is welke persoon/persoonsgegevens bij deze unieke link horen, of bij welke enquête de link hoort, is het onmogelijk voor hackers om op een systematische manier de data te manipuleren.
Het bedrijf is dus volledig op de hoogte van de fout en biedt deze 'feature' dus willens en wetens aan. Nu zou ik denken dat het garanderen van 'echte' reacties bij een enquête één van belangrijkste eigenschappen van dergelijke software is, maar blijkbaar ben ik hierin abuis.

Met de hoop NetQ alsnog te overtuigen van hun fout, biedt ik hierbij dus de NetQ enquete-bot aan. Deze bot vult een enquête voor alle mogelijke respondenten automatisch in. Mocht je een enquête zoeken is een eenvoudige Google query voldoende. De bot geeft momenteel altijd dezelfde antwoorden, maar dit is natuurlijk eenvoudig te veranderen.

Update: inmiddels heb ik van NetQ de uitleg ontvangen dat de unieke link nooit als veilig is bedoeld en dat ze bekijken of ze het minimale aantal karakters in het unieke ID kunnen verhogen

Enquête's maken, waarom zo moeilijk?

Door Spider.007 op maandag 21 november 2011 09:35 - Reacties (16)
Categorie: -, Views: 3.859

Bedrijven willen graag feedback van hun klanten, en als dat in gestructureerde vorm kan is dat natuurlijk ideaal. Dat snap ik best, en toch kom ik zo vaak voorbeelden van enquête's (een goede manier om deze gestructureerde feedback te krijgen) tegen die mij al snel de zin tot invullen ontnemen. Als het niet de vormgeving of het gebrek daaraan is dan zijn het wel de vragen waar het goede antwoord niet bijzit, of die zo krom geformuleerd zijn dat je ze sowieso over wilt slaan.

Deze week heb een enquête van KPN ingevuld en daar was ik niet ontevreden over; deze bestond uit korte duidelijke vragen met een duidelijke doelstelling. Deze had ik dan ook binnen 2 minuten ingevuld.

Gister kreeg ik een herinnering binnen van een ander bedrijf (in dit geval Argeweb) dat mijn aandacht wilde, en hier haakte ik bij de eerste vraag al af.

Probeer je de context even voor te stellen, het uitnodigende bedrijf weet al behoorlijk veel van de klant (wat men afneemt, per jaar betaalt, evt. zelfs gevoerde mail-communicatie indien een zinnig CRM in gebruik is). De klant daarentegen, ziet het bedrijf als een van de tientallen service-verlenende entiteiten in zijn leven en heeft daarbij mogelijk een goed of minder goed gevoel.

Met dit in het achterhoofd kunnen jullie je vast mijn irritatie over onderstaande eerste vraag en bijbehorende antwoorden voorstellen (en nee, deze enquête was niet anoniem, ik werd automatisch ingelogd in mijn account):
Hoeveel jaar bent u klant van Argeweb?
* Minder dan een jaar
* 1-3 jaar
* 3-5 jaar
* ≥ 5 jaar
Dit kun je toch niet menen? Wie weet er nog wanneer hij voor het eerst in een Albert Heijn of Dynabyte kwam? Hoelang heeft u uw bankrekening al, en wanneer kocht u uw tweede fiets? Ga je je enquete serieus beginnen met een vraag waar je als bedrijf het antwoord zo uit je database kan trekken, maar je je klant zijn complete archief voor moet gaan doorspitten?

Moet ik nu mijn snailmail-archief gaan doorzoeken wanneer ik klant ben geworden? Moet ik mijn gmail gaan doorzoeken hoe lang ik al klant ben? En met welk doel? Als er één vraag is die Argeweb zijn klanten zou kunnen stellen, is het dan hoe lang ze al klant zijn?

En als je dan bij jezelf denkt, 'tjah, dat weet ik niet meer', dan denkt men bij Argeweb: 'Jammer joh! Dan ben je niet goed genoeg voor deze enquête'. Geen 'weet ik niet' optie, geen enkele mogelijkheid om deze vraag niet te beantwoorden, gewoon keihard het einde van je mogelijkheid om feedback te geven.

Ik kan er echt niet bij, je laat een enquête maken, regelt de techniek, zorgt ervoor dat mensen automatisch ingelogd worden bij het klikken op de enquête-link, koopt een paar cadeaubonnen en bereidt een mailing voor; kan er dan echt geen minuut vanaf om te kijken hoe snel je klanten door een enquête heen zullen lopen? Ik kan me namelijk niet voorstellen dat er meer dan 10% van de klanten weet hoe lang ze al klant zijn.

Het resultaat van deze knullige eerste vraag is dus ook dat ik mijn positieve gevoel niet kwijt kan; maar wel kwijt ben geraakt.


Nu denk ik stiekem wel te weten waarom deze vraag erin zit, namelijk om de betrouwbaarheid van de enquête te kunnen meten; als het antwoord wat de persoon geeft teveel afwijkt van wat je al weet, dan zijn de antwoorden op andere vragen ook niet betrouwbaar. Echter vindt ik dit verschrikkelijk slechte positionering en formulering voor een dergelijk type vraag dus dit doet weinig af aan mijn rant.