GO - Create a dependency graph en

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

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: 8.741

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

NetQ noemt beveiligingsfout 'een feature'

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

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