Enable IP Ban - no IPv4 address?

Configuration
1

I would like to setup automatic IP ban like described in the http module here: https://www.home-assistant.io/components/http/

But I’m noticing a strange behaviour. If i add this configuraion, all failed logins look like this in the logfile:

2018-11-19 14:42:18 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from ::ffff:5148:21f1

I would expect to see the IPv4 address here like i do when sniffing the traffic with ngrep (please not that I have anonymized the IP):

T 127.0.0.1:52916 -> 127.0.0.1:8123 [AP]
  POST /auth/login_flow/9e6e21bddd86441eafa0e37d7d7bec55 HTTP/1.1..Host: urltoha.li..Connection: upgrade..X-Real-IP: ::ffff:123.236.123.236..X-Forwarded-For: ::ffff:123.236.123.236..Content
  -Length: 70..Origin: http://urltoha.li..User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36..Content-Type:
  text/plain;charset=UTF-8..Accept: */*..Referer: http://urltoha.li/frontend_latest/authorize.html?response_type=code&client_id=http://urltoha.li/&redirect_uri=http://urltoha.li/?auth_callb
  ack%3D1&state=eyJoYXNzVXJsIdggR0cDovL2hvbWllLmxpIiwiY2xpZW50SWQiOdfgHRwOi8vaG9taWUubGkvIn0%3D..Accept-Encoding: gzip, deflate..Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.
  7....{"username":"sfsfsf","password":"sfsf","client_id":"http://urltoha.li/"}

This is what my nginx reverse proxy configuration and configuration.yaml look like:

http:
  use_x_forwarded_for: True
  trusted_proxies:
    - 127.0.0.1
    - ::1
  trusted_networks:
    - 127.0.0.1
    - ::1

nginx config:

location / {
    proxy_pass http://127.0.0.1:8123;
    proxy_set_header Host $host;
    proxy_http_version 1.1;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Anybody have an idea how to get the IPv4 address?

1 Like
2

::ffff:5148:21f1 is the IPv6 representation of an IPv4 address, probably the one you are looking for.

3

Thats not a valid IPv6 address… even if it would, i need the V4 address.

4

It actually (almost) is. Have a look at this. The only thing odd about your example is, that the last two parts are hex. ::ffff:81.72.33.241 would be a valid IPv6 address. Haven’t seen it with hex anywhere yet.

5

I’m having a similar issue. I’m running Nginx and my ip bans were showing 172. bans for everything. I added the trusted proxies and use_x_forwarded: True and am now getting the IPv6ish addresses (::ffff:aed8:172b). So how do I get the real IP? The issue is that if there is a real attack and ban, the 172 address locks up everything and I have to go in and clear it before I can access from anywhere. This is fine if I’m at home but not if I’m away.

6

You take those 4 HEX parts and convert them to integers. In Python it’s done like this (with your example IP):

"%i.%i.%i.%i" % (int("ae", 16), int("d8", 16), int("17", 16), int("2b", 16))

Which gives us the IP 174.216.23.43. The command whois 174.216.23.43 then tells us, that this IP belongs to Cellco Partnership DBA Verizon Wireless (CLLC).

7

Great, Thanks! I have an automation that sends me a notification of a failed login attempt, is there a way to have it send the real IP in stead of the Hex parts? OR should I modify the config to show it differently? Sorry for the ignorance, I’m new to all this.

8

You could try to use a template like this to convert the address:

{% set ip = "".join("::ffff:aed8:172b".split(':')[3:]) %}
{{ ip[:2] |int(ip[:2],16) }}.{{ ip[2:4] |int(ip[2:4],16) }}.{{ ip[4:6] |int(ip[4:6],16) }}.{{ ip[6:8] |int(ip[6:8],16) }}

But I don’t know enough about how such templates can be used for notifications. At least this example works in the template-editor of the HASS UI.

9

I had been having this problem also, running Hassbian on RPi, nginx on Windows 10 in WSL. After a bit of digging, I believe that the two nginx.conf lines listen [::]:80 default_server ipv6only=off; and listen [::]:443 default_server ipv6only=off; at https://www.home-assistant.io/docs/ecosystem/nginx/ are responsible for this.

I found the solution (that works for me, at any rate), and the explanation, at

In a nutshell, the ipv6only=off parameter produces this effect, and to avoid it the server needs to have two directives for each port, i.e.

    listen 80 default_server;
    listen [::]:80 default_server;

and

    listen 443 default_server http2;
    listen [::]:443 default_server http2;

ipv6only=on is the default, so omitting it entirely works. The discussion above also says that listen 80 should be sufficient to channel both IPv4 and IPv6, but I don’t know how to test this, and the above works.

Hope this helps.

10

can you please post your nginx config? I having same problem.

11

My nginx version is 1.10.3.

worker_processes  5;
error_log  /var/log/nginx/error.log;
pid   /var/log/nginx/nginx.pid;
worker_rlimit_nofile 8192;

events {
  worker_connections  4096;
}

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
}

    server {
        server_name <yourdomain>;
        listen 80 default_server;
        listen [::]:80 default_server;
        return 301 https://$host$request_uri;
    }

    server {
        server_name <yourdomain>;
        ssl_certificate <yourpath>/fullchain.pem;
        ssl_certificate_key <yourpath>/privkey.pem;
        ssl_dhparam <yourpath>/dhparams.pem;

        listen 443 default_server http2;
        listen [::]:443 default_server http2;
        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
        ssl on;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;
        proxy_buffering off;

        location / {
            proxy_pass http://<IP/HOSTNAME/localhost>:8123;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
    	}
    }
}

Hope this helps.

12

The reason for this issue is that:

listen [::]:80

opens a socket which supports ipv6 AND ipv4. But to do so, the operating system has to translate a IPv4 address to a ipv6 address internally which leads to the described “problem” above. The address above is the valid ipv6 representation of an ipv4 address.

If you want to avoid this, just open a ipv4 only socket if you don’t mind in using ipv6:

listen 80;

1 Like