April 29, 2017

OpenBSD vmm hypervisor: Part 2HiR Information Report
This is going to be a (likely long-running, infrequently-appended) series of posts as I poke around in vmm.  A few months ago, I demonstrated some basic use of the vmm hypervisor as it existed in OpenBSD 6.0-CURRENT around late October, 2016. We'll call that video Part 1.

As good as the OpenBSD documentation is (and vmm/vmd/vmctl are no exception) I had to do a lot of fumbling around, and asking on the misc@ mailing list to really get to the point where I understand this stuff as well as I do. These are my notes so far.

Quite a bit of development was done on vmm before 6.1-RELEASE, and it's worth noting that some new features made their way in. Work continues, of course, and I can only imagine the hypervisor technology will mature plenty for the next release. As it stands, this is the first release of OpenBSD with a native hypervisor shipped in the base install, and that's exciting news in and of itself. In this article, we assume a few things:
  1. You are using OpenBSD 6.1-RELEASE or -STABLE (I'll likely start exploring -CURRENT again in a month or two)
  2. You're running the amd64 architecture version of OpenBSD
  3. The system has an Intel CPU with a microarchitecture from the Nehalem family, or newer. (e.g. Westmere, Sandy Bridge, Ivy Bridge). Basically, if you've got an i5 or i7, you should be good to go.
  4. Your user-level account can perform actions as root via doas. See the man page for doas.conf(5) for details.
 Notes on formatting:
  1. Lines in blue are text inside configuration files.
  2. Lines in green are shell commands to be executed on the command line.

Basic network setup

To get our virtual machines onto the network, we have to spend some time setting up a virtual ethernet interface. We'll run a DHCP server on that, and it'll be the default route for our virtual machines. We'll keep all the VMs on a private network segment, and use NAT to allow them to get to the network. There is a way to directly bridge VMs to the network in some situations, but I won't be covering that today.

We're going to be using "vether0" as the VM interface, and in my current configuration, "athn0" as the external interface. The below block of pf configuration was taken partially from /etc/example/pf.conf and some of the PF NAT example from the OpenBSD FAQ. Change your ext_if as needed, and save this as /etc/pf.conf:

ext_if="athn0"
vmd_if="vether0"

set skip on lo

block return
pass           
 

match out on $ext_if inet from $vmd_if:network to any nat-to ($ext_if)

Reload the pf configuration

doas pfctl -f /etc/pf.conf

Next, you'll need to specify an IP and subnet for vether0. I am going with 10.13.37.1 (and a 255.255.255.0 netmask for a /24 network) in my example. Place something like this in /etc/hostname.vether0:

inet 10.13.37.1 255.255.255.0

Bring vether0 online by running the following command:

doas sh /etc/netstart vether0

Create a basic DHCP server configuration file that matches the vether0 configuration. I've specified 10.13.37.32-127 as the default DHCP pool range, and set 10.13.37.1 as the default route. Save this in /etc/dhcpd.conf:

option  domain-name "vmm.openbsd.local";
option  domain-name-servers 8.8.8.8, 8.8.4.4;

subnet 10.13.37.0 netmask 255.255.255.0 {
        option routers 10.13.37.1;

        range 10.13.37.32 10.13.37.127;

}

Configure a switch for vmm, so the VMs have connectivity. Put the following in /etc/vm.conf:

switch "local" {
        add vether0
        up
}


Enable and start the DHCP server. We also need to set the flags on dhcpd so that it only listens on vether0. Otherwise, you'll end up with a rogue DHCP server on your primary network. Your network administrators and other users on your network will not appreciate this because it could potentially keep others from getting on the network properly.

doas rcctl enable dhcpd
doas rcctl set dhcpd flags vether0
doas rcctl start dhcpd

Enable vmd, then start it as well. For good measure, re-run fw_update to make sure you have the proper vmm-bios package.

doas rcctl enable vmd
doas rcctl start vmd
doas fw_update

You should notice a new interface, likely named "bridge0" in ifconfig now.

VM Creation and installation

Create an empty disk image for your new VM. I'd recommend 1.5GB to play with at first. You can do this without doas or root if you want your user account to be able to start the VM later. I made a "vmm" directory inside my home directory to store VM disk images in. You might have a different partition you wish to store these large files in. Adjust as needed.

mkdir ~/vmm
vmctl create ~/vmm/test.img -s 1500M

Boot up a brand new vm instance. You'll have to do this as root or with doas. You can download a -CURRENT install kernel/ramdisk (bsd.rd) from an OpenBSD mirror, or you can simply use the one that's on your existing system (/bsd.rd) like I'll do here.

The below command will start a VM named "test.vm", display the console at startup, use /bsd.rd (from our host environment) as the boot image, allocate 256MB of memory, attach the first network interface to the switch called "local" we defined earlier in /etc/vm.conf, and use the test image we just created as the first disk drive. 

doas vmctl start "test.vm" -c -b /bsd.rd -m 256M -n "local" -d ~/vmm/test.img

You should see the boot message log followed by the OpenBSD installer. Enter "I" at the prompt to install OpenBSD. I won't walk through how to install OpenBSD. If you've gotten this far, you've done this at least once before. I can say that the vm console works by emulating a serial port, so you should leave these values at their defaults (just press enter):
Change the default console to com0? [yes]
Available speeds are: 9600 19200 38400 57600 115200.
Which speed should com0 use? (or 'done') [9600]
You will also likely need to install packages without a prefetch area. Answer yes to this.
Cannot determine prefetch area. Continue without verification? [no] yes
After installation and before rebooting, I'd recommend taking note of the vio0 interface's generated MAC address (lladdr) so you can specify a static lease in dhcpd later. If you don't specify one, it seems to randomize the last few bytes of the address.
CONGRATULATIONS! Your OpenBSD install has been successfully completed!
To boot the new system, enter 'reboot' at the command prompt.
When you login to your new system the first time, please read your mail
using the 'mail' command.

# ifconfig vio0                                                               
vio0: flags=8b43 mtu 1500
        lladdr fe:e1:bb:d1:23:c4
        llprio 3
        groups: dhcp egress
        media: Ethernet autoselect
        status: active
        inet 10.13.37.39 netmask 0xffffff00 broadcast 10.13.37.255
Shut down the vm with "halt -p" and then press enter a few extra times. Enter the characters "~." (tilde period) to exit the VM console. Show the VM status, and stop the VM. I've been starting and stopping VMs all morning, so your VM ID will probably be 1 instead of 13.
# halt -p

(I hit ~. here...)
[EOT]
$ vmctl status
   ID   PID VCPUS  MAXMEM  CURMEM     TTY        OWNER NAME
   13 96542     1    256M   52.6M   ttyp3         root test.vm
$ doas vmctl stop 13
vmctl: terminated vm 13 successfully

VM Configuration

Now that the VM disk image file has a full installation of OpenBSD on it, build a VM configuration around it by adding the below block of configuration (with modifications as needed for owner, path and lladdr) to /etc/vm.conf.

# H-i-R.net Test VM
vm "test.vm" {
        disable
        owner axon
        memory 256M
        disk "/home/axon/vmm/test.img"
        interface {
                switch "local"
                lladdr fe:e1:bb:d1:23:c4
        }
}


I've noticed that VMs with much less than 256MB of RAM allocated tend to be a little unstable for me. You'll also note that in the "interface" clause, I hard-coded the lladdr that was generated for it earlier. By specifying "disable" in vm.conf, the VM will show up in a stopped state that the owner of the VM (that's you!) can manually start without root access.

Go ahead and reload the VM configuration with "doas vmctl reload", then look at the status again.
$ doas vmctl reload
$ vmctl status
   ID   PID VCPUS  MAXMEM  CURMEM     TTY        OWNER NAME

    -     -     1    256M       -       -         axon test.vm

DHCP Reservation (Optional)

I opted to set up a DHCP reservation for my VM so that I had a single IP address I knew I could SSH to from my VM host. This, to me, seems easier than using the VM console for everything.

Add this clause (again, modified to match the MAC address you noted earlier) to /etc/dhcpd.conf. You have to place this above the last curly-brace.

        host static-client {
                hardware ethernet fe:e1:bb:d1:23:c4;
                fixed-address 10.13.37.203;
        }

Restart dhcpd.

doas rcctl restart dhcpd

Go ahead and fire up the VM, and attach to the console.

vmctl start test.vm -c

You'll see the seabios messages, the boot> prompt, and eventually, all the kernel messages and the login console. Log in and have a look around. You're in a VM! Make sure the interface got the IP address you expected. Ping some stuff and make sure NAT works.
$ ifconfig vio0
vio0: flags=8b43 mtu 1500
        lladdr fe:e1:bb:d1:23:c4
        index 1 priority 0 llprio 3
        groups: egress
        media: Ethernet autoselect
        status: active
        inet 10.13.37.203 netmask 0xffffff00 broadcast 10.13.37.255
$ ping -c4 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=9.166 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=7.295 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=9.178 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=25.935 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.295/12.893/25.935/7.568 ms

Again, you can use <enter>~. to exit the VM console. You probably want to log off before you do that.  Go ahead and SSH in as well.

$ ssh axon@10.13.37.203
The authenticity of host '10.13.37.203 (10.13.37.203)' can't be established.
ECDSA key fingerprint is SHA256:f39GrAZouHQ3L+3/Qy3FHBma5K+eOe84B9QoFwqNpXo.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.13.37.203' (ECDSA) to the list of known hosts.
axon@10.13.37.203's password:
Last login: Sat Apr 29 14:21:54 2017
OpenBSD 6.1 (GENERIC) #19: Sat Apr  1 13:42:46 MDT 2017

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

$

Forward ports through the NAT (optional)

One last thing I did was to port-forward SSH and HTTP (on high ports) to my VM so that I could get to the VM from anywhere on my home network.

Add these lines to /etc/pf.conf directly under the vmd NAT rule we added earlier.

pass in on $ext_if proto tcp from any to any port 2200 rdr-to 10.13.37.203 port 22
pass in on $ext_if proto tcp from any to any port 8000 rdr-to 10.13.37.203 port 80

Reload the pf configuration

doas pfctl -f /etc/pf.conf

You should now be able to ssh to port 2200 on your host VM's IP. Obviously, browsing to port 8000 won't work until you've set up a web server on your VM, but this was how I started out when working on the PHP/MySQL guides.
Forcing the password gropers through a smaller hole with OpenBSD's PF queuesPeter Hansteen
While preparing material for the upcoming BSDCan PF and networking tutorial, I realized that the pop3 gropers were actually not much fun to watch anymore. So I used the traffic shaping features of my OpenBSD firewall to let the miscreants inflict some pain on themselves. Watching logs became fun again.

Yes, in between a number of other things I am currently in the process of creating material for new and hopefully better PF and networking session.

I've been fishing for suggestions for topics to include in the tutorials on relevant mailing lists, and one suggestion that keeps coming up (even though it's actually covered in the existling slides as well as The Book of PF) is using traffic shaping features to punish undesirable activity, such as


What Dan had in mind here may very well end up in the new slides, but in the meantime I will show you how to punish abusers of essentially any service with the tools at hand in your OpenBSD firewall.

Regular readers will know that I'm responsible for maintaining a set of mail services including a pop3 service, and that our site sees pretty much round-the-clock attempts at logging on to that service with user names that come mainly from the local part of the spamtrap addresses that are part of the system to produce our hourly list of greytrapped IP addresses.

But do not let yourself be distracted by this bizarre collection of items that I've maintained and described in earlier columns. The actual useful parts of this article follow - take this as a walkthrough of how to mitigate a wide range of threats and annoyances.

First, analyze the behavior that you want to defend against. In our case that's fairly obvious: We have a service that's getting a volume of unwanted traffic, and looking at our logs the attempts come fairly quickly with a number of repeated attempts from each source address. This similar enough to both the traditional ssh bruteforce attacks and for that matter to Dan's website scenario that we can reuse some of the same techniques in all of the configurations.

I've written about the rapid-fire ssh bruteforce attacks and their mitigation before (and of course it's in The Book of PF) as well as the slower kind where those techniques actually come up short. The traditional approach to ssh bruteforcers has been to simply block their traffic, and the state-tracking features of PF let you set up overload criteria that add the source addresses to the table that holds the addresses you want to block.

I have rules much like the ones in the example in place where there I have a SSH service running, and those bruteforce tables are never totally empty.

For the system that runs our pop3 service, we also have a PF ruleset in place with queues for traffic shaping. For some odd reason that ruleset is fairly close to the HFSC traffic shaper example in The Book of PF, and it contains a queue that I set up mainly as an experiment to annoy spammers (as in, the ones that are already for one reason or the other blacklisted by our spamd).

The queue is defined like this:

   queue spamd parent rootq bandwidth 1K min 0K max 1K qlimit 300

yes, that's right. A queue with a maximum throughput of 1 kilobit per second. I have been warned that this is small enough that the code may be unable to strictly enforce that limit due to the timer resolution in the HFSC code. But that didn't keep me from trying.

And now that I had another group of hosts that I wanted to just be a little evil to, why not let the password gropers and the spammers share the same small patch of bandwidth?

Now a few small additions to the ruleset are needed for the good to put the evil to the task. We start with a table to hold the addresses we want to mess with. Actually, I'll add two, for reasons that will become clear later:

table <longterm> persist counters
table <popflooders> persist counters 

 
The rules that use those tables are:

block drop log (all) quick from <longterm> 


pass in quick log (all) on egress proto tcp from <popflooders> to port pop3 flags S/SA keep state \ 
(max-src-conn 2, max-src-conn-rate 3/3, overload <longterm> flush global, pflow) set queue spamd 

pass in log (all) on egress proto tcp to port pop3 flags S/SA keep state \ 
(max-src-conn 5, max-src-conn-rate 6/3, overload <popflooders> flush global, pflow) 
 
The last one lets anybody connect to the pop3 service, but any one source address can have only open five simultaneous connections and at a rate of six over three seconds.

Any source that trips up one of these restrictions is overloaded into the popflooders table, the flush global part means any existing connections that source has are terminated, and when they get to try again, they will instead match the quick rule that assigns the new traffic to the 1 kilobyte queue.

The quick rule here has even stricter limits on the number of allowed simultaneous connections, and this time any breach will lead to membership of the longterm table and the block drop treatment.

The for the longterm table I already had in place a four week expiry (see man pfctl for detail on how to do that), and I haven't gotten around to deciding what, if any, expiry I will set up for the popflooders.

The results were immediately visible. Monitoring the queues using pfctl -vvsq shows the tiny queue works as expected:

 queue spamd parent rootq bandwidth 1K, max 1K qlimit 300
  [ pkts:     196136  bytes:   12157940  dropped pkts: 398350 bytes: 24692564 ]
  [ qlength: 300/300 ]
  [ measured:     2.0 packets/s, 999.13 b/s ]


and looking at the pop3 daemon's log entries, a typical encounter looks like this:

Apr 19 22:39:33 skapet spop3d[44875]: connect from 111.181.52.216
Apr 19 22:39:33 skapet spop3d[75112]: connect from 111.181.52.216
Apr 19 22:39:34 skapet spop3d[57116]: connect from 111.181.52.216
Apr 19 22:39:34 skapet spop3d[65982]: connect from 111.181.52.216
Apr 19 22:39:34 skapet spop3d[58964]: connect from 111.181.52.216
Apr 19 22:40:34 skapet spop3d[12410]: autologout time elapsed - 111.181.52.216
Apr 19 22:40:34 skapet spop3d[63573]: autologout time elapsed - 111.181.52.216
Apr 19 22:40:34 skapet spop3d[76113]: autologout time elapsed - 111.181.52.216
Apr 19 22:40:34 skapet spop3d[23524]: autologout time elapsed - 111.181.52.216
Apr 19 22:40:34 skapet spop3d[16916]: autologout time elapsed - 111.181.52.216


here the miscreant comes in way too fast and only manages to get five connections going before they're shunted to the tiny queue to fight it out with known spammers for a share of bandwidth.

I've been running with this particular setup since Monday evening around 20:00 CEST, and by late Wednesday evening the number of entries in the popflooders table had reached approximately 300.

I will decide on an expiry policy at some point, I promise. In fact, I welcome your input on what the expiry period should be.

One important takeaway from this, and possibly the most important point of this article, is that it does not take a lot of imagination to retool this setup to watch for and protect against undesirable activity directed at essentially any network service.

You pick the service and the ports it uses, then figure out what are the parameters that determine what is acceptable behavior. Once you have those parameters defined, you can choose to assign to a minimal queue like in this example, block outright, redirect to something unpleasant or even pass with a low probability.

All of those possibilities are part of the normal pf.conf toolset on your OpenBSD system. If you want, you can supplement these mechanisms with a bit of log file parsing that produces output suitable for feeding to pfctl to add to the table of miscreants. The only limits are, as always, the limits of your imagination (and possibly your programming abilities).

FreeBSD users will be pleased to know that something similar is possible on their systems too, only substituting the legacy ALTQ traffic shaping with its somewhat arcane syntax for the modern queues rules in this article.

Will you be attending our PF and networking session in Ottawa, or will you want to attend one elsewhere later? Please let us know at the email address in the tutorial description.



Update 2017-04-23: A truly unexpiring table, and downloadable datasets made available

Soon after publishing this article I realized that what I had written could easily be taken as a promise to keep a collection of POP3 gropers' IP addresses around indefinitely, in a table where the entries never expire.

Table entries do not expire unless you use a pfctl(8) command like the ones mentioned in the book and other resources I referenced earlier in the article, but on the other hand table entries will not survive a reboot either unless you arrange to have table contents stored to somewhere more permanent and restored from there. Fortunately our favorite toolset has a feature that implements at least the restoring part.

Changing the table definition quoted earler to read

 table <popflooders> persist counters file "/var/tmp/popflooders"

takes part of the restoring, and the backing up is a matter of setting up a cron(8) job to dump current contents of the table to the file that will be loaded into the table at ruleset load.

Then today I made another tiny change and made the data available for download. The popflooders table is dumped at five past every full hour to pop3gropers.txt, a file desiged to be read by anything that takes a list of IP addresses and ignores lines starting with the # comment character. I am sure you can think of suitable applications.

In addition, the same script does a verbose dump, including table statistiscs for each entry, to pop3gropers_full.txt for readers who are interested in such things as when an entry was created and how much traffic those hosts produced, keeping in mind that those hosts are not actually blocked here, only subjected to a tiny bandwidth.

As it says in the comment at the top of both files, you may use the data as you please for your own purposes, for any re-publishing or integration into other data sets please contact me via the means listed in the bsdly.net whois record.
As usual I will answer any reasonable requests for further data such as log files, but do not expect prompt service and keep in mind that I am usually in the Central European time zone (CEST at the moment).

I suppose we should see this as a tiny, incremental evolution of the "Cybercrime Robot Torture As A Service" (CRTAAS) concept.

Update 2017-04-29: While the world was not looking, I supplemented the IP address dumps with versions including one with geoiplocation data added and a per country summary based on the geoiplocation data.

Spending a few minutes with an IP address dump like the one described here and whois data is a useful excersise for anyone investigating incidents of this type. This .csv file is based on the 2017-04-29T1105 dump (preserved for reference), and reveals that not only is the majority of attempts from one country but also a very limited number of organizations within that country are responsible for the most active networks.

The spammer blacklist (see this post for background) was of course ripe for the same treatment, so now in addition to the familiar blacklist, that too comes with a geoiplocation annotated version and a per country summary.

Note that all of those files except the .csv file with whois data are products of automatic processes. Please contact me (the email address in the files works) if you have any questions or concerns.

April 28, 2017

Something for Apple dual-GPU usersDragonFly BSD Digest

Francois Tigeot has brought in the ‘apple_gmux’ driver.  If you have a Macbook with both Intel and NVIDIA video hardware installed, this driver lets you switch to the Intel hardware, and I assume take advantage of DragonFly’s accelerated i915 driver.

Removed, topbeat-1.2.3Removed OpenBSD packages
lightweight shipper for system metrics

April 27, 2017

BSDNow 191: I Know 64 & A Bunch MoreDragonFly BSD Digest

This week’s BSDNow covers a number of FreeBSD developments, Illumos network work, and an interesting in-depth discussion of the reasoning behind the transition from PC-BSD to TrueOS.

I Know 64 & A Bunch More | BSD Now 191BSD Now
We cover TrueOS/Lumina working to be less dependent on Linux, How the IllumOS network stack works, Throttling the password gropers, the 64 bit inode call for testing & more!
The many ways of running firefox on OpenBSDUndeadly
Landry Breuil, OpenBSD's firefox (and other Mozilla ports) maintainer, writes:

Maybe i haven't talked about it enough on the lists, but since i've been maintaining the various mozillas in the portstree (cvs log says i started around firefox 3.6.something... 7 years ago. *sigh*) a lot of things changed, so i wanted take the 6.1 release as an occasion to sum up the various ways one could run which version of which firefox on which version of OpenBSD.

Read more...

April 26, 2017

OpenBSD 6.1 Song ReleasedUndeadly
Every OpenBSD release since 3.0 (back in 2001) has had at least one relase song, and OpenBSD 6.1 is no different. Today, Theo de Raadt released the OpenBSD 6.1. The Songs page has download links, lyrics and a background story, which reads:

OpenBSD was only a few months old when we realized that read-only repository access for everyone was a critical concept.

Previously, open source projects would make occasional releases accompanied by tarballs of final source files and Changelogs files, but would not expose the step-by-step changes of the development process. Unwittingly all open source projects were operating with a walled garden approach.

Read more...

DragonFly and bhyveDragonFly BSD Digest

If you are using bhyve, and you want DragonFly on there as a ‘guest’ (not sure if that’s the right term), there’s a template available.  (via)

Retour sur dotSecurity 2017Antoine Jacoutot (ajacoutot@)

Avertissement parental : cet article est le fruit d’une opinion totalement subjective, toute ressemblance avec une opinion existante ou ayant existé ne saurait être que fortuite.

Le 21 avril 2017 avait lieu pour la deuxième année consécutive à Paris la dotSecurity, une conférence dédiée à la sécurité et ciblant principalement les développeurs. N’étant pas développeur et ne travaillant pas dans le domaine de la sécurité il était tout naturel que j’y assiste…

L’édition de l’année précédente m’avait quelque peu laissé sur ma faim et j’étais curieux de voir ce que la v2.0 nous réservait.

Tout d’abord, le lieu. Là, rien à dire c’est magnifique. La conférence se déroule au Théâtre des Variétés, érigé au tout début du XIX siècle et classé monument historique. On est loin de la salle de conférence d’un Novotel ! Rien à dire non plus sur l’accueil et l’organisation en générale : simple, rapide et efficace, tout ce que l’on attend de ce genre d’événement.

Un bien bel écrin donc, regardons le contenu.

La séance débute avec le traditionnel agenda de l’après-midi… Ah oui parce que bonne nouvelle pour ceux qui comme moi ont peur de s’ennuyer, dotSecurity ce n’est qu’un après-midi… pour se poursuivre avec quelques recommandations de bon sens.

Non monsieur, désolé mais vous ne pouvez pas rentrer dans un joyau du patrimoine avec votre Coke Float !

Et déja le souvenir de l’année dernière me revient, une nouvelle fois le présentateur semble aussi motivé que s’il s’agissait d’animer un meetup sur l’automatisation d’un mainframe. Je regarde de nouveau la liste des invités et je me dis qu’il pourrait faire un tout petit effort : le programme n’a pas l’air si ennuyeux que ça. Ou alors est-ce le fait de devoir parler anglais ? Nous sommes tous familiers de notre embarras à nous exprimer dans ce langage, un complexe lié à une éducation aux langues étrangères absolument exécrable. Mais je digresse, comme nous le savons tous, en informatique l’anglais n’a aucune importance…

Oui zoute meuche feurzeur euh doux…

C’est parti pour le premier intervenant, enfin pour la première intervenante puisqu’il s’agit d’Ingrid Epure, ingénieur produit à Intercom. Elle commence très vite par nous parler de ses origines roumaines qui feraient d’elle un vampire. Cela m’a interpellé et je me demande encore s’il n’y avait pas un sens caché à cette remarque. Il est vrai que j’ai moi-même côtoyé pas mal de monstres surnaturels dans le monde de l’infosec (Information security, N.D.L.R.). Ingrid nous parle beaucoup d’Ember.js et de ce qu’ils font chez Intercom puis elle nous fait une petite piqûre de rappel sur la vulnérabilité à présent bien connue liée à l’attribut target= »_blank » qui s’avère très efficace pour faire du phishing. Une explication et démonstration de cette « fonctionnalité » sont disponibles ici.

Vient ensuite le tour de Zane Lackey (Signal Sciences). Rien de passionnant, il nous parle de bug bounty et nous explique qu’en gros de nos jours le coût d’une attaque est si faible que n’importe qui peut en faire les frais n’importe quand. J’aurais tendance à vouloir dire que c’est enfoncer une porte ouverte mais l’on m’aurait accusé de vouloir faire un mauvais jeu de mots…

Le dernier intervenant de cette première session n’est autre que Mikko Hypponen, Chief Research Officer (CRO) chez F-Secure. On change tout de suite de niveau et je ne suis pas déçu ! Selon lui il n’y a pas plus important que la confiance dans le bon fonctionnement des échanges en ligne et il prend comme exemple une autorité de certification piratée par des hackers Iraniens qui a fait faillite non pas à cause du piratage en soit, mais parce qu’elle l’avait caché. Lorsque le pot aux roses fut découvert, la confiance en cette autorité fut totalement perdue (la confiance est le coeur d’une CA). Il me semble l’avoir entendu dire que cette autorité de certification était allemande alors que, je pense, il faisait allusion à DigiNotar, société néerlandaise.

Ensuite et d’une manière assez ludique, il nous raconte comment les criminels transforment la donnée en Rolls Royce. « Data is the new oil! » Comprenez que la donnée récupérée sur Internet (à l’insu du plein gré de la victime) c’est comme du pétrole. Il va jusqu’à pousser l’analogie puisque qu’après avoir récupéré cette donnée brute, il faut la raffiner (la profiler etc.) pour ensuite pouvoir la vendre et s’acheter plein de jolis véhicules.

The ‘S’ in IoT stands for security

Il dérive ensuite sur les dangers de l’IoT liés, selon lui, à deux facteurs majeurs : les mises à jour et la configuration. Le problème de la mise à jour de l’OS ou du firmware des appareils connectés est bien connu, mais il réussi à mettre en lumière celui de la configuration d’une façon très efficace. Il nous rappelle comment lors de son enfance, dans les années 80, chaque fois qu’il entrait dans un salon il y avait cet appareil sous la télévision, pourvu d’une diode clignotante qui affichait toujours : « 12:00 ». Pour les plus jeunes d’entre vous, je vous invite à aller au Musée des Arts et Métiers à Paris où est exposé ce genre d’appareil que l’on appelait au Moyen-Âge un magnétoscope, et qui servait à lire les cassettes vidéo au format VHS. Il raconte que cette fameuse diode était censée afficher l’heure courante mais que personne ne se donnait la peine de chercher dans la documentation de 85 pages comment la configurer.

Ça marche, on voit le film, touche plus !

La relation avec l’IoT et ses accès privilégiés en admin / admin devient alors évidente.

Elle est chouette la webcam dans la chambre de papa et maman…

Et pour finir, il nous dépose un petit truc comme ça, l’air de rien :

« You’re not securing the computer, you are securing the Society. »

Une fois que l’effet du Lexomil commença à se faire sentir, je revins pour la deuxième session. J’ai dans mes relations beaucoup de développeurs et savoir qu’ils sont en charge de la sécurisation de la Société me provoque des crises d’angoisse.

Jim Manico entre en scène. Fondateur de Manicode et « professeur en développement sécurisé d’applications ». Un très bon orateur, très agréable à écouter mais qui à mon goût, ne fait que survoler les sujets. Les problématiques liées à la sécurité doivent entrer en ligne de compte avant même le design initial d’une application, sécuriser n’est pas rajouter des couches a posteriori etc. certes mais il aurait été intéressant de le démontrer avec des exemples concrets. Il nous parle de l’enjeu des procédures dans le développement sécurisé et prend en exemple un contrat de concert du groupe Van Halen dans lequel il était stipulé que le groupe devait avoir dans sa loge un bol emplis de M&M’s de différentes couleurs, sauf marron. Dans le cas contraire, le spectacle serait annulé et non-remboursé. Ce qui ressemblait alors à un caprice de star était en fait une assurance que le contrat avait été correctement lu et assimilé. En effet, celui-ci contenait toutes les clauses liées aux bonnes pratiques de mise en place des éléments pyrotechniques du spectacle, intimement liés à la sécurité du groupe. Donc qu’on aime ou pas, les procédures de sécurité, que ce soit dans le développement ou ailleurs, sont importantes.

Vient ensuite le tour de Joseph Bonneau (chercheur en sécurité, enseignant et Technology Fellow à l’EFF, Electronic Frontier Foundation) de monter sur scène. Il nous parle rapidement de quelques projets emblématiques de l’EFF : Let’s EncryptPrivacy Badger et HTTPS Everywhere. Des projets indispensables à mon humble avis. Pour le reste on discute entre autre des contrats intelligents sécurisés via blockchain… Sympa mais je reste frustré : un peu court et en surface.

Everything is a freaking DNS problem!

Paul Mockapetris prend à présent la parole. Il était déja présent l’année dernière et je suis impatient d’écouter ce qu’il a à nous dire. Pour ceux qui ne le connaissent pas, il s’agit « simplement » de l’inventeur du DNS dont il dit lui-même qu’il n’aurait jamais pu imaginer l’impact. Il décrit les récentes tentatives des phishing liées au support de l’unicode dans les noms de domaine. En effet, ceux-ci ne sont plus limités à l’alphabet latin et par conséquent il devient possible d’enregistrer des domaines tels que google.com ou apple.com en remplaçant les « a » ou « o » avec leur équivalent cyrillique, qu’il est très difficile de distinguer. La majeure partie de sa présentation est essentiellement axée sur un concept encore jeune qu’il appelle le pare-feu DNS et qui utilise entre autres les RPZ (« Response Policy Zone ») afin de bloquer certaines menaces. Bon en gros, il nous encourage à utiliser ThreatSTOP dont il est le « Chief Scientist ». Voilà voilà…

Le chercheur en sécurité à l’École polytechnique fédérale de Lausanne Philipp Jovanovic vient ensuite nous parler des autorités de confiance sur Internet : les serveurs de temps, les serveurs DNS, les autorités de certification et les centres de mise à jour logiciels (e.g. Microsoft Update, les différents Stores) etc. En s’appuyant sur les tentatives de détournement de mise à jour demandées par le FBI dans des affaires récentes (FBI vs Lavabit, FBI vs Apple) il démontre l’importance de ces autorités tout en étant un maillon extrêmement faible. On peut imaginer qu’une d’entre elles soit compromise et commence à proposer des « mises à jour » logicielles qui en fait seraient d’anciennes versions (vulnérables) voir des versions malignes. Pour éviter ce genre de problème, il propose un collectif d’autorités couplé à un système d’agrégation de signatures : CoSi (Collective Signing). Une implémentation du framework est en cours sur GitHub : dedis/cothority. En gros, il s’agit de faire signer les mises à jour par plusieurs autorités de confiance indépendantes et non plus seulement par le vendeur (qui pourrait être victime de coercition, qu’elle soit criminelle ou venant de la tête d’un État).

On commence à se rapprocher dangereusement de beer o’clock lorsque Tanja Lange entre en scène. Professeur de cryptographie à l’Université Technologique de Eindhoven, elle vient nous parler de PQCrypto : Post Quantum Cryptography. Quel algorithme de chiffrement utiliser aujourd’hui si l’on part du principe que d’ici 15 à 25 ans, l’ordinateur quantique deviendra une réalité et que la grande majorité des chiffrements utilisés sur Internet, dérivés de l’algorithme de Shor, deviendra obsolète du jour au lendemain (RSA, DSA…). Elle pose cette question en affirmant que de nos jours, beaucoup de trafic chiffré est actuellement sauvegardé dans plusieurs centres de données à travers le monde, attendant leur déchiffrement rétroactif. Cette partie de son argumentation est peu étayée mais le questionnement sur la cryptographie à court ou long terme reste légitime à mon avis. Pour le moment, elle conseille fortement le chiffrement par courbes elliptiques. 18 minutes plutôt intéressantes, je suis content !

Il reviendra à Nick Sullivan, cryptographe en chef chez Cloudflare, de clôturer cette journée. Une grosse grosse déception pour moi… la seule chose que j’ai retenu étant que l’utilisation de TLS 1.3 était préférable à celle de TLS 1.2 qui elle même était préférable à TLS 1.1 qui…

C’est ainsi que s’achève cette édition 2017. J’ai la même impression que lorsque je sors d’un restaurant de nouvelle cuisine fusion : j’ai encore faim. Bien que j’apprécie particulièrement le format cours des présentations, je suis dubitatif sur le parti pris de la majorité des intervenants. L’exercice n’est certes pas aisé mais je pense qu’il faudrait resserrer les sujets afin de pouvoir entrer dans les détails (techniques ou non). Il y a un léger manque de focus à mon goût. J’aurais bien aimé également des présentations sur le développement ou l’implémentation de solutions de sécurité ou de cryptographie, on tourne presque exclusivement autour du web et des applications mobiles.

Certes dotSecurity n’a pas vocation à ressembler à une réunion de l’OSSIR (Observatoire de la Sécurité des Systèmes d’Information et des Réseaux) mais en ce qui me concerne, une présentation du type sandboxing d’application, seccomp etc. aurait été la bienvenue.

Cela étant et malgré ses défauts j’ai passé un bon moment et je retournerai à la prochaine édition ne serait-ce que pour encourager la démocratisation des procédures de sécurité et la protection de la vie privée dans les technologies de l’information.

Cet article Retour sur dotSecurity 2017 est apparu en premier sur D2SI Blog.

April 25, 2017

Penguicon 2017 ScheduleMichael Lucas

Next weekend, April 28-30 2017, I’ll be at Penguicon. Two weekends after that (12-14 May), I’ll be at Kansas LinuxFest. But we’re on Penguicon right now.

Here’s my events and the description for each. Each is 1 hour unless specified otherwise. And I’m asking your help for some of these events. (Updated to add the LN2 events, which I’m not running but a guy has to eat sometime.)

Friday:
8PM: LN2 Ice Cream
9PM: The OpenBSD Web Stack – OpenBSD is best known for security and networking. But they also have a highly secure web server and load balancer. This talk will take you through the OpenBSD web stack, presenting its strengths and disadvantages. We’ll cover the httpd web server, free globally valid SSL certificates through ACME, the Common Address Redundancy Protocol for two-server clusters, and the relayd load balancer. Many of the security issues common on web servers are simply not an issue on OpenBSD. Come find out why!

Saturday:
9 AM: Writers and Traditional Publishing – So you want to sell a book to a publisher. How do you do that? What should you expect? How do you optimize your chances of getting not just a deal, but the deal you want? What gets some people into traditional publishing, and keeps others out? Come hear authors discuss the good and bad of the publishing biz!

10-11:45AM: Author Meet & Read, Vol. 1 – A big room with Clif Flynt, Mary Lynne Gibbs, Jen Haeger, Christian Klaver, James Frederick Leach, David Erik Nelson, John Scalzi, Clarence Young, and myself, all showing off our books, talking to our readers, and signing books. I will have my books still in print for sale. I’m expecting that the others will all have long lines and I’ll be there alone, so this is your chance to heckle me in person.

10:54-11:03AM: reading from git commit murder – Readings are tightly scheduled, so I expect this to begin and end sharply on time.

1PM: self publishing in 2017 – Self-publishing is an increasingly important channel for authors to reach their readers. It also changes constantly, with new tools and distributors opening daily and existing platforms changing. This panel brings together veteran self-publishers to share their experiences, discuss the changes of the last year, and give new authors an edge in the business.

2PM: 90 second reads – Join a handful of Penguicon authors as they read 90-second passages from their novels. The selections will be thematically linked based on keywords, such as sorrow, fury, funny, love, etc. Timing is crucial! After, there will be a Q&A with the authors.

3PM: LN2 ice cream

5PM: Writing High-Performance Nonfiction – Writing nonfiction is not merely reciting facts. It’s a specialized form of storytelling, very different from your college essays and book reports. Whether you’re writing memoirs or computer texts, using storytelling techniques transforms your work for the better. This talk takes you through making your nonfiction not only readable, but memorable.

7PM: BSD Operating Systems in 2017 – I’ll be discussing the current options in BSD-based operating systems, the big news from recent projects, new developments, and where we’re going from here.

8-10PM: LN2 ice cream

Sunday:

10AM: breakfast – LN2 ice cream

11AM: Senior Sysadmin Panel – Storage – The years know things that the days and weeks never know. We’ve gathered half a dozen people who’ve been sysadmins for over 20 years to talk about the one of the most dreaded and annoying topics in computing: storage.

12PM: Self-Promotion for Creatives – Independent creators are their own PR departments. We have to not only make all the things, we have to spread the word about all the things. Here we have a bunch of artists and writer types who successfully spread their work across the world. What works? What doesn’t? How can you be shamelessly self-promoting without being a jerk? Come find out!

Where could I use help?

In the 90 second reads panel, I get a few 90 second periods to read a selection from my fiction. Each read should have a theme. Our group has four themes: Betrayal, Heartbreaking, Scary, Funny.

For those of you who have read my fiction: I could use suggestions for parts of my books that you thought fit these themes. I have a few thoughts, but what I think fits a theme is probably not what struck you lot as fitting that theme.

So: if you’ve read my fiction, what of mine would you suggest for a brief reading in any or all of those themes?

New package, gmime30-3.0.0OpenBSD packages
MIME messages creation and parsing library
Minor module modificationsDragonFly BSD Digest

For those of you who build custom kernels, the if_sl, if_ppp, and if_faith devices are now built as modules, not in the kernel.  This means you can remove references to them in your custom kernel config – if you have one.

myPhone Hammer Iron 2 - budget phone reviewAdam Walk

I hate Android phones. I had a few from higher to low end brands. They never received upgrades on a timely matter, had build quality issues and over time got bloated enough that the base system was not able to update the bundled apps anymore. Not to mention leaving enough space for anything else. The one I had with me during g2k16 wiped itself due to overheating and recently ended it’s life by being dropped off a 30cm table by our dog. To double the trouble my wifes phone decided it’s a good time to have a dying battery - so suddenly I was faced with the need of getting 2 new phones.

I didn’t want to go on another contract to get both of us iPhones and can’t justify spending that much money on two new models (or even used ones). It would also be nice to get something that won’t die from a single drop - I even considered dumb phones but we both want to use strava/endomondo on the upcoming dog trekking event and I need 2FA on my phone.

What phone could I get with a shoe string budget, that’s fairly decent and survives accidents that killed my previous phone?

Perhaps one that survives being treated with acid used to clear pipes as demonstrated on the video below (ignore the audio, I set the start time on the action)?

For just under 120 USD we get a phone with:

  • Android 6.0
  • 8 GB of built in storage
  • dual sim (not a hybrid slot)
  • microSD slot up to 32GB
  • quad-core, 1.3 GHz processor
  • 5 Mpx back and 2 Mpx front cameras
  • 4 inch display (480 x 800 px)
  • Li-Ion 2400 mAh battery (swappable!)

The specs aren’t impressive performance wise. The main selling point for this phone is being certified IP-68 this means that this phone can be submerged down to 3 meters under water while turned on and is completely dust tight. The case is also hardened and shock proofed plus it comes with a protective foil on the screen itself. If you go through more parts of the linked YouTube video you will see it being put through much more harsh tests.

I’m not delusional. I don’t expect it to survive anything, even the things I saw actual reviewers do. I am convinced though that it has a better survival chance against my typical use cases and accidents that can happen during my normal usage.

This phone literally has no ENG reviews online. Except the product page. The company is from Wroclaw Poland (so local country wise to me) and there has been a decent amount of reviews on the Polish interwebs. They obviously still manufacture in China.

Biggest flaws reviewers pointed out were:

  • battery readouts
  • lack of LTE (it has 3G)
  • audio issues on built in speaker, especially in low temperatures (craclking, glitching, voice going mute)
  • annoying sign up to myPhone community pop-up app

I hit all four and have one of my own to add.

The battery. Let’s start off saying I am completely happy and actually quite surprised with how long the battery holds. The battery warning went up after 45 hours of regular usage informing me of an estimated remaining charge for about 4-5h of usage.

Regular use means:

  • a few calls (~4)
  • a few pictures taken (~5-6)
  • WiFi always on
  • cell data on while out the house (6-8 hours)
  • a few Youtube videos (2-3 15 minute videos)
  • some browsing with chrome
  • email, signal (texts), 2FA apps, slack, twitter + mastodon

My current charge shows 38% battery left with a 74h 22m phone uptime and approx. 19 hrs left. On the initial charge what I noticed were huge drops in battery usage. You can see them on the shots below where the charge readout is flat for hours then drops by 20% or more. This seems to be evening out with usage but the initial charges were jumpy and that matches what the reviewers were reporting.

This is a screenshot from the initial discharge readouts: First charge

and here is one from my current charge: Current charge

All in all. I don’t think the battery is a problem and the fact that I can actually exchange it is a huge benefit. I had to buy two phones, out of which one was necessary only because the battery was not swappable in the one we had.

The lack of LTE is actually not a problem for me. The most network usage I have on my phone is at home with WiFi and during outside events like running/dog trekking I don’t need LTE, 3G is enough and adds to longer battery life.

Audio is another thing though. Everything the reviewers said on it is spot on. Crackling, glitches, phone going low volume and completely mute on occassions. Happened mostly on the built in speaker phone when it was not on. I am still not sure what and if I will do anything with it. It doens’t happen always and I don’t spend much time talking - could use a regular or bluetooth headset to workarond it. Not really keen to send it for repair and wait 2-3 weeks without a phone - especially since a lot of online reviewers reported that phones after repairs still had the same issue present.

Their app is indeed annoying. It doesn’t pop up randomly as reviewers suggested. The app shows up on first run and when the list of running apps is cleared from the task manager. What is it exactly? Just a simple brochure promoting the community that leads to a form where you put your email to sign up to the newletter. The biggest problem? It is always triggered, even if you decided to sign up. When I called up the company they said they were aware that it’s annoying to some users and are considering an update to remove, alter or disable it.

That covers what was online already. Now the one hit on my own.

The biggest flaw so far is an older security patch level (October 5 2016) which still is pretty good for a very low shelf device (note the price I gave was with no contract).

I called up the company and asked what’s their update policy. They don’t have any officially planned updates for this model but no-one said no. There is a possibility that something will be released but I’m not making bets on it. Bonus on their side is an unmodified stock android with some apps pre-installed (but quite sane choices and most allowing a full uninstall which is very rare).

The situation isn’t perfect but quite typical for most Android phones except top of the line models or purchases directly from Google. I don’t trust my phone at all (you will never find my PGP and SSH private key material on my phone) and it’s already a more recent patch from my previous phone. I personally think that selling hardware with outdated software should be treated the same as selling products past their due date but the reality is not there yet. I did voice my concerns over phone, myPhone does have a line of higher end rugged smartphones that are indeed very promising but I will be not buying anything else from them until I see a clear policy on software security updates.

Now the fun part. We got two identical phones, or so we thought. front

back

In case it’s hard to see. My model says ‘8.0 Mega’ next to the back camera lens. By the way, the screws visible on the photo are not just decoration - they hold the back lid from splitting apart when the phone falls preventing the battery from jumping out. They give you a nice custom screwdriver for those :)

The company confirmed on the phone that all models are 5 Mpx. They don’t know why mine has a surplus text printed on but found it interesting. I find it funny also but I expected differences in build quality between units of the same model - it is a budget phone after all.

Still, talking about the camera I am more than happy with the picture quality but I don’t have huge demands for a phone camera.

myDog photographed with myPhone

The GPS tested by my wife also behaved decently. The interface is snappy, nothing is lagging/sluggish - all my 2FA apps work. This phone pretty much covers mine and my wifes needs without ruining our budget. I would whole heartedly recommedend it if only myPhone provided up to date security updates for their phone models. One more thing. God damn, why did you pick a name that sounds like a cheap iPhone rip-off - rugged smartphones are an amazing product, have some guts and stand on your own. If anyone from myPhone is reading this, consider at least keeping your rugged phones line under the Hammer trademark and drop your company name from it.

PS.

It’s hard to get this phone outside of Poland. They have their own shop but no English interface and their resellers are also local. When talking on the phone I asked on the possiblities of purchasing from abroad. The company was not ready to handle sales to the USA but is able to sell anywhere inside the EU - when I confronted this with them not having a shopping frontend in English they said they can handle orders via email in English. I wanted to learn more but the audio in my phone went mute (and back then I assumed the call center person just muted me :) - but it was my audio getting glitched!)

PSS.

If you have any doubts. I was not paid in any way for this article, none of the links here are affiliate. Just my personal opinion on our recent purchase.

April 24, 2017

ASLR, PIE, NX, and other capital lettersDragonFly BSD Digest

As part of a larger conversation about security measures, NX bit capability was added to DragonFly.   You can turn it on or off, and it’s off by default so it doesn’t cause any surprises.  As the first link in this post points out, your installed third-party software is more of a security issue than processor features, in any case.

New package, keepassxc-2.1.4OpenBSD packages
management tool for sensitive data
New package, py-numexpr-2.6.2OpenBSD packages
fast numerical expression evaluator for NumPy
New package, xwallpaper-0.2.1OpenBSD packages
wallpaper setting utility for X

April 23, 2017

Lazy Reading for 2017/04/23DragonFly BSD Digest

Eclectic!  I cover everything this week: computer history, modern pessimistic computing, odd hardware, strange software stories, comics, and tea.

Your sorta-a-comics-link of the week: Liartown USA, the book.

April 21, 2017

clang(1) added to base on amd64 and i386Undeadly

A series of commits, culminating in this one, have seen clang(1) added to the base system (as a non-default compiler) on the amd64 and i386 platforms:

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2017/04/18 08:03:08

Modified files:
	share/mk       : bsd.own.mk 

Log message:
ship clang with i386 and amd64.  It does not become the main compiler YET.
ok kettenis

Those playing along at home (or elsewhere!) should be sure to check the Following -current FAQ.

April 20, 2017

New package, ucon64-2.0.3OpenBSD packages
swiss army knife for video game console emulators