Posted
Comments None

Hey! So I’ve been working really hard on converting BDisk over to Python (from bash). I am pleased to announce that version 3.00 (Beta) is complete and the documentation is done!

Head on over to https://bdisk.square-r00t.net to see why this software will change your life. Yes, there’s a lot of documentation. It’s worth it. Yes, I realize I sound like a telemarketer.

Note that this is still beta software, so I recommend doing your building in a VM and if you encounter any bugs (there’s sure to be some) or feature requests, you should DEFINITELY please let me know.

Author
Categories BDisk, Linux

Posted
Comments None

I do a lot of work with Arch Linux VMs. Mostly as part of testing my AUR packages, or for building BDisk.

BDisk builds take a long time if your Internet connection isn’t the greatest- the vast majority of this is the package installation in the chroots.

So I referenced this article and sync the repos I need to my virtualizer host. (For those curious, the community, core, extra, multilib, and iso/latest dirs on a mirror combined consume about 70GB. Not a lot at all.)

But now I have a problem- I don’t want to use my primary mirror as my lab’s host machine’s IP, since that breaks pacman functionality for builds in the wild.

So instead I picked a mirror, put it at the top of the mirrorlist, and in my libvirt setu on the host I set a DNS entry for that. Assuming my VM host is 1.2.3.4 (accessible to the VM guest) and I’m running an appropriately mapped web daemon on it (again, accessible to guests):

virsh net-update default add dns-host "<host ip='1.2.3.4'><hostname>foo.domain.tld</hostname></host>" --live --config

Ta-da!

Author
Categories SysAdmin, BDisk

Posted
Comments None

I keep forgetting how to test UDP with netcat. I found this which was a good reminder.

For instance:

echo -n "blah:36|c" | nc -w 1 -u -4 localhost 8125

on the client and:

tcpdump -i lo udp port 8125 -vv -X

on the target will give a stream in which you can easily find “blah”.

And this gives a pythonic way of doing it with the sockets module.

Author
Categories Linux, InfoSec

Posted
Comments None

If you use your own internal SSL PKI (private key infrastructure) – in other words, if you act as your own CA (certificate authority), you have some ways of verifying the certificates you generate. (Note that this also works for verifying without using s_client for third-party CA’s as well, if you have the root CA file and certificate in question. You’ll need to chain the intermediate cert(s) with the CA, though.)..

Where was I?

Ah! Right.

So! Given that CA.crt is our PEM-encoded CA certificate and client.crt is our PEM-encoded endpoint certificate:

openssl verify -verbose -CAfile CA.crt client.crt

And as a bonus, here’s how you get a certificate’s fingerprint:

openssl x509 -fingerprint -in client.crt -sha512 -noout

Of course, there’s always the tried-and-true method of s_client. s_client will connect to the given host:port and if all the certs check out, it will give a “Verify return code: 0 (ok)”. (In the below examples, we use ‘</dev/null’ to send a null byte to close the connection- otherwise you can use s_client as a sort of SSL-tunneled telnet of sorts.)

With full trust chain:

openssl s_client -showcerts -connect devblog.square-r00t.net:443 < /dev/null

And with fingerprints!

openssl s_client -showcerts -connect devblog.square-r00t.net:443 < /dev/null |& openssl x509 -fingerprint -noout

Author
Categories Linux, InfoSec

← Older Newer →