Failed Login Detection

Share your Projects!
12

Finally got it working , don’t ask me why though :frowning:
I was about to open a bug to HS, i was repeating the steps by steps to give as much information as possible and “bam” it worked

First off i updated to 0.32.3 this morning
second, the first entry will always be a failed command message since the grep command did not find any entry ( this could be reported as a bug since normally it should just report a 0 as on the command line
Third , the looked for string is not valid anymore as the error message changed from a few version down the road

So here’s my config that IS working

configuration.yaml

sensor 6:
  platform: command_line
  name: badlogin
  command: grep -c 'Login attempt' /home/hass/.homeassistant/home-assistant.log

logger:
  default: warning

home-asssistant.log

Result at startup
16-11-11 14:15:59 homeassistant.components.sensor.command_line: Command failed: grep -c 'Login attempt' /home/hass/.homeassistant/home-assistant.log

Result when login failed

16-11-11 14:17:07 homeassistant.components.http: Login attempt or request with an invalid password from 70.83.11.62
16-11-11 14:17:08 homeassistant.components.http: Login attempt or request with an invalid password from 70.83.11.62
16-11-11 14:17:11 homeassistant.components.http: Login attempt or request with an invalid password from 70.83.11.62

Screen shot of the result in HA

As you can see, the result will always be +1 as it the actual bad login attempt

Also , if you reduce the Logger level ( or the component level ) above “warning” the failed command will still be logged in but not the entry as above, so you will always staty with Value = 1 with your grep -c

Hopefully it will help some of you :slight_smile:

Also, i will submit an updated documentation as the example on the site is not up to date anymore

cheers

13

A little addition

The following loggger setting will remove the +1 caused by the first command which is failing and will give you the proper count
if you can live with those http log setting :slight_smile:

logger:
  default: critical
  logs:
    homeassistant.components.http: warning
14

Any way to do some kind of fail2ban setup? Too many wrong passwords and the IP gets locked out for a certain amount of time? Might be useful to prevent brute-force attempts as the project continues to grow

1 Like
15

What i did for mine after 10 failed attempt I stop HA

Easy to do with the command line and automation
Not the best but for now it’s the only thing I have :slight_smile:

1 Like
16

Thats a good solution. I may implement this, but instead of stopping HA just shut down my Raspberry Pi, that way the device they are trying to access is gone along with the HA instance.

Anyone know how to attach a file (home-assistant.log) to a STMP notification. It would be nice to get the log file so I can see what the IP address is.

17

@silvrr
If you get to have this running please share your findings
I have not been able to issue a sudo reboot command from HA and I did not want to grant my hass user root access to perform it

Thanks

18

I wouldn’t want some bot hammering my login screen to completely shut down my entire Home Automation/Monitoring system.

I posted a feature request at Failed Login Lockout / Brute Force Protection for native support

1 Like
19

I noticed after my update to 34.3/4 that there is a persistent notification for a failed login attempt. The state of this trigger includes the IP the failed login was made from.

Anyone have any idea on how to automate this for a notification? Only part I don’t have is the trigger. Not sure how to trigger off a persistent notification.

20

You could try a state trigger with entity_id: persistent_notification.httplogin. Don’t specify state or from/to on this trigger as the content of the persistent notification is variable. So something like this:

- alias: "Send notification upon failed login attempt"
  trigger:
    - platform: state
      entity_id: persistent_notification.httplogin
  condition:
    - condition: template
      value_template: "{{ trigger.to_state.state != 'None' }}"
  action:
    - service: notify.pushover
      data_template:
        title: "Failed login!"
        message: "{{ trigger.to_state.state }}"

Bare in mind I haven’t tested the code above, so it may contain errors. The template condition is there to avoid sending a notification when dismissing the persistent notification (at which point the state of the persistent notification goes from Invalid password used from xxx.xxx.xxx.xxx to None).

The alternative for this condition would be to include from: 'None' in the trigger, but then you risk not getting notified if the persistent notification is overwritten before it gets dismissed.

And, of course, replace the pushover notify service in my code with whatever notify service you use.

1 Like
21

Haven’t tried, but what happens when you test for it with a template trigger?

trigger:
  - platform: template
      value_template: '{% if (states.persistent_notification.name_of_notification.state) %}true{% else %}false{%endif%}'

edit: @fanaticDavid came to the rescue while I was testing my syntax

22

The notification works, however, it does give another notification when you dismiss. Ill have to work on the condition.

23

Hmmm try removing the single quotes around None, so:

condition:
  - condition: template
    value_template: "{{ trigger.to_state.state != None }}"
1 Like
24

That did the trick :slight_smile:

Update: It does create an empty notification (only the title, message is blanc) after dismissing the login failure persistant notification in the frontend which is kind of annoying. Any idea how to dismiss these in silence (or even better: dismiss them at once since I will allready be notified anyway)?

2 Likes
25

Found it.

The condition must be:

condition:
  - condition: template
    value_template: "{{ trigger.to_state.state != off }}"
26

Doesn’t work anymore after upgrading to 0.38.2 since there is no entry in the logfile anymore.

Update: same issue on 0.38.3

1 Like
27

And same on 0.38.4.

28

Works like a charm on 0.39 :slight_smile:

29

I have solved this by adding a value_template that always subtracts 1 :

- platform: command_line
  name: bad_login
  command: "grep -c 'Login attempt' /home/homeassistant/.homeassistant/home-assistant.log"
  value_template: '{{ value | int - 1 }}'

My sensor reports 0 after a restart and the actual number of bad logins when they occur.

1 Like
30

anyone using this be sure to validate that it still works after the 0.86 update. I noticed that persistent_notification.httplogin has become persistent_notification.http_login on my configuration which breaks the automation many are using.

(unique content to make the forum not freak out)

1 Like
33

Thanks a lot. This saved me a huge head ache.

1 Like