<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Jacky Hammer on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/authors/jacky-hammer/</link>
    <description>Recent content in Jacky Hammer on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 02 Feb 2018 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/authors/jacky-hammer/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Virtualized Training Environment with Ansible</title>
      <link>https://insinuator.net/2018/02/virtualized-training-environment-with-ansible/</link>
      <pubDate>Fri, 02 Feb 2018 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2018/02/virtualized-training-environment-with-ansible/</guid>
      <description>&lt;p&gt;As Kai and I will be holding a &lt;a href=&#34;https://troopers.de/troopers18/trainings/tr18-automation-with-ansible/&#34;&gt;TROOPERS workshop on automation with ansible&lt;/a&gt;, we needed a setup for the attendees to use &lt;a href=&#34;https://www.ansible.com/&#34;&gt;ansible&lt;/a&gt; against virtual machines we set up with the necessary environment. The idea was, that every attendee has their own VMs to run ansible against, ideally including one to run ansible from, as we want to avoid setup or version incompatibilities if they set up their own ansible environment on their laptop.  Also they should only be able to talk to their own machines, thus avoiding conflicts because of accidental usage of wrong IPs or host names but also simplify the setup for the users.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Let’s talk about RFC 6980</title>
      <link>https://insinuator.net/2017/12/lets-talk-about-rfc-6980/</link>
      <pubDate>Fri, 01 Dec 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/12/lets-talk-about-rfc-6980/</guid>
      <description>&lt;p&gt;Following my work with the &lt;a href=&#34;https://insinuator.net/2017/06/testing-rfc-6980-implementations-of-freebsd/&#34;&gt;FreeBSD implementation of RFC 6980&lt;/a&gt; I was happy to present my work at last week’s DENOG 9 meeting.&lt;br&gt;&#xA;To make it available to anyone who did not meet me there and go into some more detail that would have exceeded the boundaries of the talk, I will cover the topic here.&lt;/p&gt;&#xA;&lt;p&gt;After the preceding work on &lt;a href=&#34;https://insinuator.net/2017/03/testing-rfc-6980-implementations-with-chiron/&#34;&gt;Windows Server 2016&lt;/a&gt; and the FreeBSD testing, as a Linux user, lover and administrator, I of course wanted to take a look at how different Linux systems complied with the RFC 6980 standard.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Testing RFC 6980 Implementations of FreeBSD</title>
      <link>https://insinuator.net/2017/06/testing-rfc-6980-implementations-of-freebsd/</link>
      <pubDate>Fri, 23 Jun 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/06/testing-rfc-6980-implementations-of-freebsd/</guid>
      <description>&lt;p&gt;Following Enno’s research on “&lt;a href=&#34;https://insinuator.net/2017/03/testing-rfc-6980-implementations-with-chiron/&#34;&gt;Testing RFC 6980 Implementations with Chiron&lt;/a&gt;“, we decided to redo the experiment with FreeBSD targets.&lt;/p&gt;&#xA;&lt;p&gt;The lab setup was very similar:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;A Cisco Catalyst 3560 switch running the software “C3560c405ex-UNIVERSALK9-M” version 15.2(2)E4 connecting&lt;/li&gt;&#xA;&lt;li&gt;A Linux based attacker system running Chiron and&lt;/li&gt;&#xA;&lt;li&gt;A FreeBSD target system, running different OS versions and configurations and&lt;/li&gt;&#xA;&lt;li&gt;A Linux based laptop running a control script that remotely performed the necessary tasks on the two machines mentioned above&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;The main question was: Would the impact on the target system and the possible attacks that were observed with the Windows Server 2016 victim be reproducible on other operating systems? Or would those behave totally differently?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Looking back on RIPE 74</title>
      <link>https://insinuator.net/2017/05/looking-back-on-ripe-74/</link>
      <pubDate>Fri, 19 May 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/05/looking-back-on-ripe-74/</guid>
      <description>&lt;p&gt;From May 8th to 12th I was able to attend the 74th RIPE meeting in Budapest, Hungary. Being rather new to the networking community, I enjoyed learning a lot of different things, not only from the various interesting talks but also from inspiring conversations with a variety of people from all areas during the beautiful social events.&lt;/p&gt;&#xA;&lt;p&gt;As it was the first RIPE meeting for me, I was very thankful for the “Newcomer’s Introduction” on Monday morning, containing a RIPE and RIPE NCC 101. It was quite helpful to get into the mindset and understand the structure of the meeting, like the division into different working groups based on the participants’ interests. After familiarizing myself with the concept, I chose to attend several sessions on Address Policy, IPv6, Routing, Open Source, and DNS working groups besides the general plenary sessions. I’ll be reviewing those sessions here.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
