<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dw="https://www.dreamwidth.org">
  <id>tag:dreamwidth.org,2010-03-06:483469</id>
  <title>Move along, nothing to read</title>
  <subtitle>A dis-illusioned software engineer</subtitle>
  <author>
    <name>robbat2</name>
  </author>
  <link rel="alternate" type="text/html" href="https://robbat2.dreamwidth.org/"/>
  <link rel="self" type="text/xml" href="https://robbat2.dreamwidth.org/data/atom"/>
  <updated>2017-05-21T05:45:16Z</updated>
  <dw:journal username="robbat2" type="personal"/>
  <entry>
    <id>tag:dreamwidth.org,2010-03-06:483469:238949</id>
    <link rel="alternate" type="text/html" href="https://robbat2.dreamwidth.org/238949.html"/>
    <link rel="self" type="text/xml" href="https://robbat2.dreamwidth.org/data/atom/?itemid=238949"/>
    <title>ebtables for EC2-like metadata server on 169.254.169.254 AND bridge</title>
    <published>2017-05-21T05:45:16Z</published>
    <updated>2017-05-21T05:45:16Z</updated>
    <category term="networking"/>
    <category term="metadata"/>
    <category term="amazon"/>
    <category term="ec2"/>
    <category term="bridge"/>
    <dw:security>public</dw:security>
    <dw:reply-count>0</dw:reply-count>
    <content type="html">&amp;lt;&amp;gt;Playing with the concepts around Cloud metadata services, specifically those that are network-based, rather than the ConfigDrive or serial port variants. 

&lt;p&gt;EC2 ensures that 169.254.169.254 is magically provide your instance with your data, and it won't be accessible to another instance.  This is trivial to achieve if your instances are using routed or tap network; but is more complex if you are on a bridged network: the client will try to send the packets for 169.254.169.254 to the MAC of the default gateway. &lt;/p&gt;

&lt;p&gt;So far I can force bridged packets that would otherwise be headed for the gateway to be routed locally (and put  169.254.169.254/32 locally on the host). I don't have a good way to associate the packets with a specific instance yet. Using kernel packet marks work, but  isn't really scalable. Main requirement is that a simple web service should be able to uniquely identify the client, even if they try to spoof themselves (learn mac+IP of another instance on the same hypervisor &amp; bridge, and ask for it's metadata from the wrong interface)&lt;/p&gt;

&lt;h3&gt; Variant 1&lt;/h3&gt;
&lt;pre&gt;  ebtables -t nat -N metadata || ebtables -t nat -F metadata
for i in $(seq 0 20) ; do
   ebtables -t nat -A metadata -i vnet$i -j mark --mark-set $((256+$i)) --mark-target CONTINUE
done
ebtables -t broute -A metadata --limit 10/minute --limit-burst 2 --log --log-level debug --log-prefix "ebtables metadata" --log-ip
ebtables -t nat -A metadata -j redirect
ebtables -t nat -F PREROUTING
ebtables -t nat -A PREROUTING -p IPv4 --logical-in br0 --ip-src 169.254.169.254 -j metadata
ebtables -t nat -A PREROUTING -p IPv4 --logical-in br0 --ip-dst 169.254.169.254 -j metadata
&lt;/pre&gt;

&lt;h3&gt;Variant 2&lt;/h3&gt;
&lt;pre&gt;
ebtables -t broute -N metadata || ebtables -t broute -F metadata
ebtables -t broute -F BROUTING
ebtables -t broute -A BROUTING -p IPv4 --ip-src 169.254.169.254 -j metadata
ebtables -t broute -A BROUTING -p IPv4 --ip-dst 169.254.169.254 -j metadata
ebtables -t broute -A metadata --limit 10/minute --limit-burst 2 --log --log-level debug --log-prefix "ebtables metadata" --log-ip
# Repeat the marks if you want them.
ebtables -t broute -A metadata -j redirect
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;&lt;img src="https://www.dreamwidth.org/tools/commentcount?user=robbat2&amp;ditemid=238949" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/&gt; comments</content>
  </entry>
  <entry>
    <id>tag:dreamwidth.org,2010-03-06:483469:238770</id>
    <link rel="alternate" type="text/html" href="https://robbat2.dreamwidth.org/238770.html"/>
    <link rel="self" type="text/xml" href="https://robbat2.dreamwidth.org/data/atom/?itemid=238770"/>
    <title>gnupg-2.1 mutt</title>
    <published>2015-06-05T17:25:29Z</published>
    <updated>2015-06-12T17:54:14Z</updated>
    <category term="gentoo"/>
    <category term="cli"/>
    <category term="gnupg"/>
    <category term="gpg"/>
    <category term="mutt"/>
    <category term="pgp"/>
    <dw:security>public</dw:security>
    <dw:reply-count>0</dw:reply-count>
    <content type="html">&lt;p&gt;For the mutt users with GnuPG, depending on your configuration, you might notice that mutt's handling of GnuPG mail stopped working with GnuPG. There were a few specific cases that would have caused this, which I'll detail, but if you just want it to work again, put the below into your &lt;tt&gt;Muttrc&lt;/tt&gt;, and make the tweak to &lt;tt&gt;gpg-agent.conf&lt;/tt&gt;. The underlying cause for most if it is that secret key operations have moved to the agent, and many Mutt users used the agent-less mode, because Mutt handled the passphrase nicely on it's own.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;tt&gt;-u&lt;/tt&gt; must now come BEFORE &lt;tt&gt;--cleansign&lt;/tt&gt;&lt;/li&gt;
&lt;li&gt;Add &lt;tt&gt;allow-loopback-pinentry&lt;/tt&gt; to &lt;tt&gt;gpg-agent.conf&lt;/tt&gt;, and restart the agent&lt;/li&gt;
&lt;li&gt;The below config adds &lt;tt&gt;--pinentry-mode loopback&lt;/tt&gt; before &lt;tt&gt;--passphrase-fd 0&lt;/tt&gt;, so that GnuPG (and the agent) will accept it from Mutt still.&lt;/li&gt;
&lt;li&gt;&lt;tt&gt;--verbose&lt;/tt&gt; is optional, depending what you're doing, you might find &lt;tt&gt;--no-verbose&lt;/tt&gt; cleaner.&lt;/li&gt;
&lt;li&gt;&lt;tt&gt;--trust-model always&lt;/tt&gt; is a personal preference for my Mutt mail usage, because I do try and curate my keyring&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;
set pgp_autosign = yes
set pgp_use_gpg_agent = no
set pgp_timeout = 600
set pgp_sign_as="(your key here)"
set pgp_ignore_subkeys = no

set pgp_decode_command="gpg %?p?--pinentry-mode loopback  --passphrase-fd 0? --verbose --no-auto-check-trustdb --batch --output - %f"
set pgp_verify_command="gpg --pinentry-mode loopback --verbose --batch --output - --no-auto-check-trustdb --verify %s %f"
set pgp_decrypt_command="gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --batch --output - %f"
set pgp_sign_command="gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --batch --output - --armor --textmode %?a?-u %a? --detach-sign %f"
set pgp_clearsign_command="gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --batch --output - --armor --textmode %?a?-u %a? --detach-sign %f"
set pgp_encrypt_sign_command="pgpewrap gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --batch --textmode --trust-model always --output - %?a?-u %a? --armor --encrypt --sign --armor -- -r %r -- %f"
set pgp_encrypt_only_command="pgpewrap gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --batch --trust-model always --output --output - --encrypt --textmode --armor -- -r %r -- %f"
set pgp_import_command="gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --import -v %f"
set pgp_export_command="gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --export --armor %r"
set pgp_verify_key_command="gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --batch --fingerprint --check-sigs %r"
set pgp_list_pubring_command="gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --batch --with-colons --list-keys %r"
set pgp_list_secring_command="gpg %?p?--pinentry-mode loopback --passphrase-fd 0? --verbose --batch --with-colons --list-secret-keys %r"

&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;&lt;img src="https://www.dreamwidth.org/tools/commentcount?user=robbat2&amp;ditemid=238770" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/&gt; comments</content>
  </entry>
</feed>
