Mai 31

ipv6 ist nett. Aber der User bekommt halt jedes mal idR ein /64 Subnet. Für so Tools wie fail2ban, die einzelne IPs blocken, wenn irgendetwas komisches auftaucht irgendwie schlecht. Der Angreifer schnappt sich halt irgendeine neue IP, denn die unteren 64bit stehen ja voll zu seiner Verfügung.

Jetzt verhält es sich mit dem originalen fail2ban so, dass das nicht mal ipv6 kann. Zeit sich auf die Suche zu machen. In einem github-Repo bin ich fündig geworden. Der gute Mensch hat fail2ban so erweitert, dass es v6-fähig wird. Also flugs mal installiert, um direkt die Ernüchterung zu spüren: Es blockt mit /128 🙁

Also erweitern:

Die /etc/fail2ban/action.d/iptables-46-multiport-log.conf passen wir wie hier in diesem gist sichtbar an. Hinzugekommen ist lediglich <mask> bei der ban und unban-Regel sowie unter init. Das bedeutet, dass – sofern nicht anders angegeben – immer eine /32er CIDR-Mask gelegt wird, also die gesamte v4-IP (bei v6 halt ebenfalls /32 – aber dazu später mehr) geblockt wird.

Da die fail2ban-Variante von “usrweiss” im Wrapperscript nicht so granular zwischen v4 und v6 differenzieren kann, als dass wir da andere cidr-Masken drauflegen könnten, legen wir einfach in der /etc/fail2ban/jail.conf ZWEI Jails an:

[web_v4]
enabled = true
filter  = web_v4
action = ip64tables-multiport-log[name=web_v4, protocol="tcp", port="80,443", mask=32]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

[web_v6]
enabled = true
filter  = web_v6
action = ip64tables-multiport-log[name=web_v6, protocol="tcp", port="80,443", mask=64]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

									

Die benötigen wiederrum auch 2 Configs in der /etc/fail2ban/filter.d:

/etc/fail2ban/filter.d/web_v4.conf:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v4 (<HOST>) Detaillierte Fehlermeldung .*

									

/etc/fail2ban/filter.d/web_v6.conf:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v6 (<HOST>) Detaillierte Fehlermeldung .*

									

Der Haken ist, dass unsere Applikation, die die Events auslöst (hier eine Loginseite, die die Fehlversuche nach /var/log/apache2/web_f2b/fail.log wegschreibt) an die Zeile dranschreiben muss, ob es sich um v4 oder v6 handelt. Bezogen auf die o.g. Configs sieht das in dem fail.log der App so aus (Von der Applikation generierte Einträge. Erster: v6, zweiter v4)

[May 31 10:08:12] Applikation: v6 (2a03:2880:2130:cf05:face:b00c:0:1) fehlerhafter Loginversuch blabla
[May 31 10:09:12] Applikation: v4 (173.252.120.6) fehlerhafter Loginversuch blabla
									

Von nun an blockt fail2ban die Ports 80 und 443 sobald in der Logdatei der Applikation (/var/log/apache2/web_f2b/fail.log) 5 mal innerhalb von 60 Sekunden die selbe IP mit einem Fehler aufschlägt für 60 Sekunden. Und zwar bei einer v4 halt die v4, bei einer v6 das /64er Subnet der v6. Die gerade greifende Netzmaske wird in der/etc/fail2ban/jail.conf als Variable “mask” in der action mit angegeben – sollte dort nichts stehen, gilt der Defaultwert von /32 aus der iptables-46-multiport-log.conf

 

Wie üblich, geht das sicherlich noch eleganter. Bin gespannt, wann fail2ban endlich eine v6-Variante releast.

Tagged with:
Mai 24

Wie hier im Blog schon beschrieben, habe ich mir mit einem Pi A einen kleinen Statusscreen gebastelt, der sich immer dann anschaltet, wenn jemand in die nähe des Pi’s kommt. Realisiert wurde das mit der PiCam – basierend auf Helligkeitsänderungen beim Snapshot. Soweit so gut. Seit 2 Monaten hängt sich der olle Pi jedoch regelmässig auf. So schlimm, dass ich Ihm einen crontab-Eintrag verpasst habe, mit dem er jede Nacht neu bootet.

Zeit der Sache mal auf den Grund zu gehen. Das Problem war: Zu wenig RAM. Der Pi A hat gerade 256MB davon (eigentlich mehr als genug, für soetwas). Dummerweise hängt in PiCam direkt an der GPU des kleinen Rechners. Was bedeutet, dass man dem Ding in der /boot/config.txt den Parameter gpu_mem=128 mitgeben muss. Heisst: 128MB für die GPU (drunter funktioniert die cam nicht) und 128MB für das OS. Sofern man nun nicht eine extraschlanke Distribution mit busybox und dem ganzen Small-Mem-Footprint-gedönse nutzt, ist das verdammt mau. Erst recht mit der extrem aufgeblasenen Raspianedition.

Also mussten Lösungsansätze her. Die Cam mit weniger als 128MB GPU-RAM zu betreiben funktioniert also schon mal nicht. Dann halt komplett anders.  Für gerade mal 1,10 Euro/Stück gibt es bei Amazon PIR-Sensoren. PIR steht für Pyroelektrische Passive Infrarot Sensoren. Die Dinger, die man aus den Bewegungsmeldern an Aussenlampen kennt. Das besondere an diesen PIRs ist, dass sie out-of-the-box mit dem Pi über GPIO spielen können.

Obwohl das Chinaware ist, ist es relativ gut dokumentiert. In dieser Grafik findet sich alles, was man wissen muss:

Wir sehen zwei Potentiometer, mit denen man die Empfindlichkeit und eine Art “Nachlaufwert” einstellen kann. Den Timer stellt man am besten auf “0” (Anschlag ganz links), das “Distanz”-Poti nach Gusto. Nun zum elektrischen:

  • VCC bei dem Ding ist 5V – der kommt also an PIN2 des GPIO’s (+5V OUT)
  • GND auf GND – PIN 6
  • OUT ist der PIN, der “HIGH” wird, wenn sich was vor dem Sensor bewegt. Und coolerweise spuckt das Ding ca. 3,3V aus – also genau richtig für den GPIO. Den hängen wir an GPIO18 (PIN 12)

Hier eine Übersicht der GPIO-PINs des raspis:

Nach dem das nun alles Erledigt ist, geht es zum simpleren Teil. Der Software. Ich habe das ganze, wie bereits beim Cam-Script in Python realisiert:

#!/usr/bin/python
import subprocess
import os
import time
import RPi.GPIO as io
from datetime import datetime
delay=60
monitor='on'
pir_pin = 18
io.setmode(io.BCM)
io.setup(pir_pin, io.IN)         # activate input

def turnMonitorOn(extrarg):
  global monitor
  monitor='on'
  subprocess.call("/usr/bin/screen.sh on "+extrarg, shell=True)

def turnMonitorOff(extrarg):
  global monitor
  monitor='off'
  subprocess.call("/usr/bin/screen.sh off "+extrarg, shell=True)
   
# Reset last capture time
lastCapture = time.time()
# added this to give visual feedback of camera motion capture activity.  Can be removed as required

while True:
  time.sleep(0.5)
  if io.input(pir_pin):
    lastCapture = time.time()
    if (monitor == 'off'):
      turnMonitorOn("y")

  if (time.time()-lastCapture > delay):
    if (monitor == 'on'):
      turnMonitorOff('x')

									

In der Variable “delay” kann man einstellen, wie lange der Screen nach einer Bewegungserkennung angeschaltet bleiben soll. Es sind natürlich auch andere Pins als GPIO18 möglich (bspw. GPIO4 / Pin7)

Das Shellscript, “screen.sh” ist dasselbe, wie im Cam-Post:

#!/bin/bash
tvstat=$(tvservice -s |grep off)
if [[ $tvstat == *off* ]]; then
TV=OFF
else
TV=ON
fi

if [ "$1" == 'on' ] && [ "$TV" == "OFF" ]; then
/usr/bin/tvservice -p;
#fbset -depth 8;
#fbset -depth 16;
chvt 2;
sleep 1
chvt 1;
chvt 2;
chvt 1;
#echo 'Switched Screen ON!'
fi
if [ "$1" == 'off' ] && [ "$TV" == "ON" ]; then
/usr/bin/tvservice -o
echo 'Switched Screen OFF!'
fi

									

Nun noch in der /boot/config.txt den Wert gpu_mem auf 32 oder gar 16 stellen, rebooten, und wir haben wieder mehr als genug RAM. Dass die CAM nun nicht mehr funktioniert, sollte jedem klar sein – aber das war ja auch Sinn und Zweck der Sache.

Tagged with:
Mai 02

Für mich selbst als Merker, damit ich das nächste mal nicht wieder in Panik ausbreche.

Besonderheiten beim “Internet” via Telekom Hotspot:

  • Öffentliche IP’s gibt es per se nicht – man bekommt irgendwas privates aus dem 10er-Space zugewiesen.
  • V4 only
  • Jede Ziel-IP (egal ob Online oder Offline) ist aus dem Hotspot-Netz ein DNS-Server. Führt zu leichten Panikattacken, wenn man meint seine eigenen Kisten von aussen damit auditieren zu wollen. Vermutung: Alles was auf Port 53 rausgeht, wird von der T abgefangen und dann unter falscher Flagge beantwortet, als wäre es ein openrelay.

Besonderheiten beim “Internet” via Telekom LTE:

  • Öffentliche IP’s gibts mit LTE nicht mehr (LTE akzeptiert ausschliesslich “internet.telekom” oder “internet.t-mobile” als APN – und da gibts halt nur “Private-Address-Space”)
  • v4 Only
  • Port 80 und Port 8080 unterliegen irgendeiner Art Deep-Packet-Inspection (kann nur raten, ob das was mit diesem Zwangsproxy zu tun hat, der jpgs/gifs noch mal nachkomprimiert hat). Fakt ist: Egal ob die Ziel-Adresse offline ist, oder gar keinen Dienst auf den beiden Ports anbietet – es gibt IMMER einen sauberen 3-Wege Handshake. Interessant in dem Zusammenhang: Irgendein Netzelement leitet die Anfragen (so denn die “Echte Ziel-IP” online ist, und auch n Listener hat) mit leichtem Delay an die Richtige IP weiter. Wenn Ziel-IP offline / kein Dienst, gibts ein “FIN” per TCP – aber erst nach erfolgtem SYN/SYNACK/ACK.
Tagged with:
preload preload preload