arne.z's questions

I am trying to setup a simple Kerberos environment which consists of a Kerberos server (KDC), a client machine and a server machine running an OpenSSH daemon. The client is supposed to be authenticated through Kerberos when establishing an SSH connection to the server machine.

The name of the Kerberos user that I'm trying to authenticate is krbuser. This user exists on the service machine and has a uid of 1001. The strange thing is that I need to enter the Kerberos user's password when logging in with SSH. Each time I login. Not only for my first connection. This seems strange because the whole point of Kerberos is to authenticate without a password.

I took a tcpdump during the authentication process and noticed that the client is doing AS-REQs to the KDC with cname root. This Kerberos username does not and I have no idea why the client is using this name. As expected, the KDC responds with a eRR-C-PRINCIPAL-UNKNOWN message, since there is no root user in the database.

To me it seems that the main issue is the fact that the client tries to authenticate as root instead of krbuser.

I'll post some information about my current configuration below. Please let me know if you need any additional information.

On the KDC:

/etc/krb5.conf

[logging]
    default = FILE:/usr/local/krb5/var/log/krb5lib.log 
    kdc = FILE:/usr/local/krb5/var/log/krb5kdc.log
    admin_server = FILE:/usr/local/krb5/var/log/kadmin.log

[libdefaults]
    default_realm = metz.prac.os3.nl
    rdns = false

# The following krb5.conf variables are only for MIT Kerberos.
    krb4_config = /etc/krb.conf
    krb4_realms = /etc/krb.realms
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true

[realms]
    metz.prac.os3.nl = {
        kdc = krb-0.metz.prac.os3.nl
        admin_server = krb-0.metz.prac.os3.nl
    }

On the service machine:

/etc/ssh/sshd config (an extract)

# Kerberos options
KerberosAuthentication yes
# KerberosGetAFSToken no
# KerberosOrLocalPasswd no
# KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
# GSSAPICleanupCredentials yes

Captured log files during the SSH authentication:

debug1: rekey after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user root service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "root"
debug1: PAM: setting PAM_RHOST to "218.65.30.30"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: inetd sockets after dupping: 5, 5
Connection from 145.100.110.115 port 51946 on 145.100.110.116 port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: permanently_set_uid: 106/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: [email protected] [preauth]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none [preauth]
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: rekey after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: rekey after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user krbuser service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "krbuser"
debug1: PAM: setting PAM_RHOST to "145.100.110.115"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user krbuser service ssh-connection method gssapi-with-mic [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 2 failures 1 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 3 failures 2 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user krbuser service ssh-connection method password [preauth]
debug1: attempt 2 failures 0 [preauth]
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: restore_uid: 0/0
debug1: do_pam_account: called
Accepted password for krbuser from 145.100.110.115 port 51946 ssh2
debug1: monitor_child_preauth: krbuser has been authenticated by privileged process
debug1: monitor_read_log: child log fd closed
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: PAM: establishing credentials
User child is on pid 20617
debug1: SELinux support disabled
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1001/1001
debug1: rekey after 134217728 blocks
debug1: rekey after 134217728 blocks
debug1: ssh_packet_set_postauth: called
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype [email protected] want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: SELinux support disabled
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
Starting session: shell on pts/2 for krbuser from 145.100.110.115 port 51946 id 0
debug1: Setting controlling tty using TIOCSCTTY.
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 4 failures 3 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 5 failures 4 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
debug1: userauth-request for user root service ssh-connection method password [preauth]
debug1: attempt 6 failures 5 [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: Kerberos password authentication failed: Client '[email protected]' not found in Kerberos database
debug1: krb5_cleanup_proc called
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 218.65.30.30 port 18460 ssh2
maximum authentication attempts exceeded for root from 218.65.30.30 port 18460 ssh2 [preauth]
Disconnecting: Too many authentication failures [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 20604
debug1: audit_event: unhandled event 12
debug1: inetd sockets after dupping: 5, 5
Connection from 218.65.30.30 port 58146 on 145.100.110.116 port 22
debug1: Client protocol version 2.0; client software version nsssh2_4.0.0032 NetSarang Computer, Inc.
debug1: no match: nsssh2_4.0.0032 NetSarang Computer, Inc.
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: permanently_set_uid: 106/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: diffie-hellman-group14-sha1 [preauth]
debug1: kex: host key algorithm: ssh-rsa [preauth]
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none [preauth]
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none [preauth]
debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]

On the client machine:

kinit and klist before authentication:

$ kinit -p krbuser
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting     Expires            Service principal
06/15/17 00:24:05  06/15/17 10:24:05  krbtgt/[email protected]
    renew until 06/16/17 00:23:56

/etc/ssh/ssh config (an extract):

    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no

And finally the SSH authentication:

$ ssh [email protected] -vvv
...
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "service-0.metz.prac.os3.nl" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to service-0.metz.prac.os3.nl [145.***.***.***] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
...
debug1: Found key in /home/client/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/client/.ssh/id_rsa ((nil))
debug2: key: /home/client/.ssh/id_dsa ((nil))
debug2: key: /home/client/.ssh/id_ecdsa ((nil))
debug2: key: /home/client/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: send packet: type 50
debug2: we sent a gssapi-with-mic packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
...
debug1: Next authentication method: password
[email protected]'s password: <entering PW of Kerberos user> !!!
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to service-0.metz.prac.os3.nl ([145.***.***.***]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
...
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Thu Jun 15 00:28:57 2017

Connection established

Now klist shows the following tickets:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting     Expires            Service principal
06/15/17 00:24:05  06/15/17 10:24:05  krbtgt/[email protected]
    renew until 06/16/17 00:23:56
06/15/17 00:27:37  06/15/17 10:24:05  host/service-0.metz.prac.os3.nl@
    renew until 06/16/17 00:23:56
06/15/17 00:27:37  06/15/17 10:24:05  host/[email protected]
    renew until 06/16/17 00:23:56

So, to sum up: The Kerberos user on the client can establish an SSH session to the server by entering its Kerberos (!) password. Not its UNIX password. The tcpdump showed that the client authenticates as root which is not a Kerberos user and I have no idea why it is using this username instead of krbuser. Which is the one I used with the kinit command.

Can anyone tell me why this authentication is not working correctly? Please let me know if you need additional information. I tried to keep it short.

The MIT Kerberos Documentation lists seven different ways to store Kerberos credentials:

1. API
2. DIR
3. FILE
4. KCM
5. KEYRING
6. MEMORY
7. MSLSA

At the moment my Kerberos setup is storing credentials in a file in the /tmp directory. In my krb5.conf file the ccache_type option is set to 4 by default:

# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

And in the MIT Kerberos Documentation about the krb5.conf file it says about the ccache_type option:

This parameter determines the format of credential cache types created by kinit or other programs. The default value is 4, which represents the most current format. Smaller values can be used for compatibility with very old implementations of Kerberos which interact with credential caches on the same host.

It seems that the value of the ccache_type option does not correspond to the seven ccache types that the documentation lists. Since 4 specifies to use the "most current format" and not "KCM".

Therefore, my question is: How can I configure Kerberos to use a different ccache type, for example a keyring or memory?

I am trying to setup a simple Kerberos environment in which a client server authenticates to a webservice (in my case OpenSSH) via a Kerberos server.

I generated a keytab file on the KDC but am not quite sure which servers to copy the file to. Do I only need to copy it to the machine that is offering the service or also to the client machine that wants to authenticate to the service?

I am trying to detect DNS requests of type NULL using Snort. I located the type field of the request packet using Wireshark:

I found the following rule on McAfee:

alert udp any any -> any 53 (msg:"NULL request"; content:"|01 00|"; offset:2; within :4; content:"|00 00 0a 00 01|"; offset:12; within:255; threshold: type threshold, track by_src, count 10, seconds 5; sid: 5700001; rev: 1)

However, first of all this rule does not work for me as it throws the following error message:

ERROR: /etc/snort/rules/local.rules(7) within can't be used with itself, protected, offset, or depth

Which is odd, because apparently using within in combination with itself, protected, ... wasn't a problem for McAfee. I am using Snort version 2.9.9.0.

Furthermore, I also hoped that there would be a better way to address the type field of the DNS request. Instead of using a fixed offset to specify where in the packet you are looking for a specific pattern. Isn't there a way to look for the Type field in the Queries field of the Domain Name System section. This would also make the rule a lot more readable than using offsets and hexcode patterns.

So, my question is: Does anyone know a Snort rule that detects DNS requests of type NULL?

I just ran an experiment to find out how long it takes Weave to recover from a broken connection. In my test setup node A is connected to node B through two paths. Path 1 has one hop and path 2 has two hops. So, initially, Weave routes the traffic through path 1 since it is shorter.

When breaking path 1 by bringing down the interface of one of the hops it takes around 60 seconds for Weave to react and reroute the traffic through path 2.

I am checking the routing by having a look at the weave report output. More precisely, I am checking the information at Router.Peers.UnicastRoutes:

    "UnicastRoutes": [
        {
            "Dest": "2a:e4:6e:f0:57:ef",
            "Via": "76:5d:78:64:6d:a6"
        },
        {
            "Dest": "66:c6:2f:12:02:05",
            "Via": "00:00:00:00:00:00"
        },
        {
            "Dest": "76:5d:78:64:6d:a6",
            "Via": "76:5d:78:64:6d:a6"
        },
        {
            "Dest": "a2:eb:a7:ed:41:b8",
            "Via": "76:5d:78:64:6d:a6"
        },
        {
            "Dest": "06:8c:d2:06:2b:eb",
            "Via": "76:5d:78:64:6d:a6"
        },
        {
            "Dest": "aa:be:7b:8b:a2:75",
            "Via": "76:5d:78:64:6d:a6"
        }
    ]

In this case the connection is already broken and all traffic is routed via the longer path 2.

As mentioned, it takes around 60 seconds for Weave to notice that path 1 is broken. I am assuming, that there is a timeout to make sure that the connections is really down and won't recover. When I fix path 1 by bringing the interface back up, Weave updates its topology within less than one second, which indicates that it can react a lot faster.

So I was wondering if there is a way to specify the time that Weave keeps trying to connect before accepting that this connections is broken.

I am using Weave Net to connect my Docker containers across different hosts. Weave is making use of "Fast Datapath" which handles the routing in Kernel Space (inside the OVS (Open vSwitch) Module as shown in the diagram below.)

In oder to get a better understanding about how Weave routes traffic, I would like to see the routing entries of the OVS Module. There are commands like ovs-vsctl show which "prints a brief overview of the database contents" but this didn't work. Seems like Weave is running its own OVS instance which cannot be accessed with this command.

I also tried inspecting Weave with the

weave status        [targets | connections | peers | dns | ipam]

commands but that didn't show any detailed routing information either.

So, does anyone know how to see the routing table that weave uses to decide where to route packets destined to a certain docker container?

nmap offers OS-detection functionality based TCP/IP fingerprinting by sending six probing packets and analyzing their responses. In the documentation is says that some of them are send to an open port and some are sent to a closed port.

Does anyone know how nmap decides which port to send the probes to? Does it just look for the first closed port and the first open ports it can find? Does it search for them in a certain order? Or does it randomly pick a port?

I want to evade nmap's TCP/IP fingerprinting, which it uses to detect the OS on a machine. I read A practical approach for defeating Nmap OS-Fingerprinting which explains how this can be done. It also suggests a few programs which can do this. Most of them manipulate the TCP/IP implementation in the kernel. But they're are all outdated and not maintained anymore.

So I would like to ask if anyone knows another way of achieving this. Can I configure the responses to nmap's os-probing packets manually?

I am trying to configure EXIM to use Rspamd as a spam filter. I am running Exim version 4.87 and installed Rpsam from the repositories using apt-get as explained here. Then I added the suggested configuration from the Rspamd documentation to my config file:

begin acl

# configure Rspamd
# Please note the variant parameter
spamd_address = 127.0.0.1 11333 variant=rspamd   # error occurs here

acl_smtp_data = acl_check_spam

acl_check_spam:
  # do not scan messages submitted from our own hosts
  accept hosts = +relay_from_hosts

  # do not scan messages from submission port
  accept condition = ${if eq{$interface_port}{587}}

  # skip scanning for authenticated users
  accept authenticated = *

  # add spam-score and spam-report header when told by rspamd
  warn  spam       = nobody:true
        condition  = ${if eq{$spam_action}{add header}}
        add_header = X-Spam-Score: $spam_score ($spam_bar)
        add_header = X-Spam-Report: $spam_report

  # use greylisting available in rspamd v1.3+
  defer message    = Please try again later
        condition  = ${if eq{$spam_action}{soft reject}}

  deny  message    = Message discarded as high-probability spam
        condition  = ${if eq{$spam_action}{reject}}

  accept

When I try to restart Exim I get the following error message:

error in ACL: unknown ACL condition/modifier in "spamd_address = 127.0.0.1 11333 variant=rspamd"

Which refers to the 4th line of the config code I posted above: spamd_address = 127.0.0.1 11333 variant=rspamd. I found the exact same line in the official Exim documentation. So it should work. Did anyone encounter that problem before, when configuring Exim to use Rspamd?

I am using Ubuntu:

$ uname -a
Linux calais 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I would like to find out if my Ubuntu VM uses tcp-offloading to increase the performance of VXLAN encapsulation. Where can I find this information on my machine?

I wrote a Python program that runs iperf3 in a for loop with different datagram sizes. I am using Python's subprocess.call function to run iperf3 like this:

 iperf3 -u -c 185.82.21.60 -b 100M -t 5 -l <datagram size>

My datagram size starts with 1000 and increases by 100 after each iteration and should run until it reaches a size of 2000. Every time I am running my program, iperf3 keeps hanging after the 6th time and starts using 100% of one of my CPUs. After this I cannot use iperf3 anymore until I kill the running client process and restart the iper3 server.

Here is a picture to illustrate my problem:

I am measuring the UDP throughput between two Docker containers that are connected by Docker's native overlay network. I already used iperf but also want to measure the throughput with nuttcp. But when I am starting the server instance and then start the client instance, the server instance crashes with the following error message: Segmentation fault (core dumped). This is how I started the server:

nuttcp -S -u --nofork

and this is how I started the client:

nuttcp -u -T 115 10.0.0.3

The server instance crashes directly after starting up the client. I used the same commands to run nuttcp outside of Docker without any problems.

Here is some additional informations about the versions I am using:

# inside the container:
$ uname -a
Linux 310d92462ac0 3.19.0-58-generic #64~14.04.1-Ubuntu SMP Fri Mar 18 19:05:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ nuttcp -V
nuttcp-6.1.2

# outside the container:
$ uname -a
Linux libAMS 3.19.0-58-generic #64~14.04.1-Ubuntu SMP Fri Mar 18 19:05:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ docker -v
Docker version 1.10.3, build 20f81dd

Does anyone have an idea how to solve this?

I am currently examining the performance (especially UDP throughput) of different Docker overlay networks. I do this by creating point-to-point connections between two hosts that are connected with a Docker overlay network and then run iperf inside the Docker containers to examine the throughput. I noticed that everytime I am running iperf as a client to send data to the other container that runs iperf as a server, the CPU usage of the client host reaches 100%. I got that result by running the following command I found on here:

top -bn1 | grep "Cpu(s)" | \
       sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | \
       awk '{print 100 - $1"%"}'

So, to me it seems that the limiting factor of my throughput tests is the CPU capacity of my host, since it runs at 100% and is not able to generate more traffic to saturate the network connection. I am wondering if this is an iperf specific issue so I wanted to run the same tests with a different tool but am not sure which alternative would be best. The hosts are running Ubuntu. For example, I found qperf, uperf and netpipe.

Also, more generally, I started to wonder what normally is the bottleneck for throughput performance. Isn't it always either the CPU capacity or the bandwidth of the link? Which are factors that are not directly related to the overlay networks.

Does that mean that the throughput of an application (or overlay network) just depends on how many CPU cycles it needs to transfer a certain amount of data and how it compresses it to fit it through the network (if that would be the bottleneck).