Messages

1

German - Deutsch / Re: Verdächtiges Verhalten - Ursache finden

« on: February 26, 2019, 06:59:34 pm »

Der Webserver ist auf der gleichen Maschine (alles ESXi) und die verschiedenen Dienste werden über HAProxy auf den Server geproxyt (auf die jeweilige IP / den Port des Services). Das ist (zumindest soweit ich Firewall-Anfänger das verstehe UND kann) wohl die sicherste Methode. Die Dienste sind zudem mit htpasswd abgesichert.

Die 2FA mit Authenticator App - wobei man das ja umstellen kann auf Email. Die ist aber (fast sicher  ) nicht kompromittiert, das läuft über Google mit 2FA und da bekomme ich jede Anmeldung gemeldet. Da gab es keine. Und die ganzen anderen Accounts sind hoffentlich auch "ohne", die haben alle ganz andere Passwörter (keepass). Ich denke für einen Hobby-PC-Freak ist das ganz ordentlich abgesichert. Aber ich lerne gerne immer dazu. Ich hoffe, dass das aus Russland also nur ein Anmeldeversuch war, der hoffentlich gescheitert ist. Und den Account habe ich wegen OneDrive... Ich habe auch schon mal ne Nextcloud hinter OpnSense überlegt, aber ich traue Microsoft noch eher zu, die Daten zu sichern (noch dazu alle mit Boxcryptor verschlüsselt) als mir selbst beim Betrieb der OPNSense. Dafür bin ich da zu noobig.

Viele Grüße
doc

2

German - Deutsch / Re: Verdächtiges Verhalten - Ursache finden

« on: February 26, 2019, 05:22:24 pm »

@uneu: mist, dann war die Größe der Protokolldatei zu klein - hab mal auf 1000000 (hoffentlich wirklich Byte und nicht kB  )erhöht, Speicherplatz ist zu genüge da. Tja und ich hoffe, dass nichts reinkommt, auf der WAN Schnitstelle sind nur der https port und der vpn port freigegeben. Aber über die lässt sich bestimmt auch viel Humbug treiben.
@chemlud: jo, die stehen unter besonderer Beobachtung... wobei die Geschichte echt merkwürdig ist. Angeblich hat sich jemand in den Account eingeloggt - ich habe aber 2FA also kann ich mir das kaum vorstellen (aber gut, wer weiß). Die Infos die MS dazu gibt sind aber auch echt dürftig... Gerät/Plattform: Windows, Browser/App:
Firefox, IP-Adresse: 178.206...., Ungefährer Standort: Russische Föderation... wäre halt toll zu wissen, ob erfolgreich angemeldet oder nicht ;-)
Komisch ist vor allem die Kombination der beiden Dinge am gleichen Abend.
Viele Grüße
doc

3

German - Deutsch / Re: Verdächtiges Verhalten - Ursache finden

« on: February 26, 2019, 10:00:08 am »

;-) die zwei Dinge habe ich nur in einen Topf geworfen, um mein aktuelles Bedrohungsgefühlt zum Ausdruck zu bringen...
Email war von MS, im MS-Account war auch der Zugriff aus Russland dokumentiert. Das ist erledigt.
Der TV hat eine feste IP und es geht nicht drum, dass der telefoniert, sondern dass jemand auf ihn zugreifen wollte (Steuerungsanfrage, die ich über die Fernbedienung abgelehnt habe). Jetzt wüsste ich natürlich gerne, von welcher IP gestern auf meinen TV um ca. 19:50 Uhr zugegriffen wurde.
Viele Grüße
doc

4

German - Deutsch / Verdächtiges Verhalten - Ursache finden

« on: February 26, 2019, 07:47:35 am »

Hallo zusammen,
ich hatte gestern eine Steuerungsanfrage auf meinem TV, die ganz sicher von niemanden aus meinem Haushalt ausgelöst wurde. Zudem habe ich von Microsoft eine Email bekommen, daass jemand meinen Account aus Russland benutzt. Jetzt würde ich natürlich gerne schauen, was gestern Abend auf meinen TV zugegriffen hat. Wenn ich auf  Firewall: Protokolldateien: Originalansicht gehe und dort nach der IP vom TV suche, kommt kein Ergebnis - meine Befürchtung, dass die Datei schon wieder überschrieben wurde, weil zu viele Einträge waren. Daher meine Fragen:
- wie / wo sucht man denn üblicherweise, wenn man etwas Verdächtiges entdeckt?
- kann ich noch wo suchen außer in den Firewall Protokolldateien?
- Ich habe ca. 70 Netzwerkgeräte, wie groß sollte ich die Logdateien machen, damit ein paar Tage gespeichert bleiben?
Viele Grüße
doc

5

German - Deutsch / Re: HA-Proxy Pfad abschneiden - NEUES Problem

« on: February 09, 2019, 09:51:36 pm »

Servus,
eigentlich war die Lösung ganz einfach: die Regel musste einfach so aussehen (letzte Zeile - set Path:/)

Code: [Select]

Name: Pfad_delete
Testtyp: if
Bedingung: acl_bit
Logischer Operator: none
Funktion: http-request set-path
Set Path: /Jetzt erreiche ich zwar den Server, habe aber ein neues Problem: alle Serverseiten sind relativ aufgebaut, also zum Beispiel

Code: [Select]

<link href="app/main.ffb91956f020dfe11902.css" rel="stylesheet"></head>und da wird der Pfad leider nicht automatisch nicht mit ersetzt, so dass ich letztlich eine leere Seite angezeigt bekomme und wenn man sich die Quelltexte ansieht, natürlich solche Fehler findet:

Code: [Select]

<p>The requested URL <code>/test/bit/app/main.ffb91956f020dfe11902.css</code> was not found on this server.Was muss ich denn dem HAProxy sagen, damit er mir das auch ersetzt bzw. wie kann ich die Umleitung richtig bauen?
Viele Grüße
doc

6

German - Deutsch / Re: HA-Proxy Pfad abschneiden

« on: January 28, 2019, 04:21:51 pm »

So, hier mal meine improvisierte Lösung - die leider nicht funktioniert:
Ich lasse das Pfad_delete weg und leite nicht direkt auf den Bitwarden Nginx um, sondern auf einen Apache mit Reverse Proxy, der dann das Directory /test/bit abfängt und auf den Bitwarden Nginx umleitet. Quasi von hinten durch die Brust ins Auge, aber zu mehr bin ich Noob nicht fähig ;-)
Das Problem ist nur, dass ich jetzt auf den Bitwarden Container komme, wenn ich allerdings was machen will (z.B. Einloggen oder Konto anlegen), dann kommt immer "NetworkError when attempting to fetch resource." Wenn ich ohne die Proxys direkt drauf gehe, funktioniert alles einwandfrei. Von daher wäre ich für Tipps dankbar.
Ach ja - und ich musste die Bedingung ändern
Name: acl_test
Bedingungstyp: Path starts with -> das ist erforderlich, weil Bitwarden ein /#/ hinten dran hängt
Pfad enspricht: /test/bit

Viele Grüße
doc

7

German - Deutsch / Re: HA-Proxy Pfad abschneiden - NEUES Problem

« on: January 28, 2019, 09:42:58 am »

Hallo zusammen, ich versuche gerade über HAProxy auf meinen Bitwarden docker weiterzuleiten. Ich muss die Anfrage, die über einen Pfad (ich habe mal /test/bit definiert) allerdings ohne den Pfad ans Backend (IP:81) weiterleiten. Ich habe hier https://forum.opnsense.org/index.php?topic=10114.0 schon mal was gefunden, aber das klappt nicht so ganz. Hier mal mein Aufbau:

Bedingung:
Name: acl_test
Bedingungstyp: Path matches
Pfad enspricht: /test/bit

Regel:
Name: bit_weiterleiter
Testtyp: if
Bedingung: acl_bit
Logischer Operator: none
Funktion: Verwende den angegebenen Backendpool
Use backend pool: bit

Name: Pfad_delete
Testtyp: if
Bedingung: acl_bit
Logischer Operator: none
Funktion: http-request set-path
Set Path: /test/bit%[path,regsub(/,)]

Backend: bit
IP: 192.168....
Port: 81

Und im Frontend habe ich unter Regeln sowohl Test_weiterleiter als auch Pfad_delete drin. Wenn ich das Pfad_delete rausnehme schaut es so aus als würde er auf den richtigen Server weiterleiten nur bekomme ich keine Anzeige (weil eben der Pfad mit übermittelt wird und da finded ngingx nichts). Und den Pfad bei ngingx selbst einzutragen wäre ziemlich sinnlos, denn das wäre bei jedem update des containers weg.
Leider gibt das Log von HAProxy nicht viel her was schief gehen könnte und der Ngingx von Bitwarden protokolliert von Haus aus nichts. Daher tue ich mir schwer - aber ich schätze es hängt einfach an meinem "Pfad_delete".
Viele Grüße
doc

8

German - Deutsch / Re: Unbound und BIND anwenden als alternative fuer Pi-Hole

« on: December 15, 2018, 05:04:58 pm »

Yuhuu, p1n0ck10 Dankeschön - so läuft es!!! Geniale Sache, echt top. Die DNS-Server unter System/Settings/General muss ich allerdings drin lassen, sonst geht nix. Aber jetzt greift BIND, DANKE!!!
Allerdings hast du mich jetzt auch mit dem DNSCrypt neugierig gemacht  Kann man beides, also BIND und DNSCrypt betreiben / die DNS Abfrage nacheinander irgendwie von Unbound zu BIND und zu DNSCrypt biegen?
Viele Grüße
doc

9

German - Deutsch / Re: Unbound und BIND anwenden als alternative fuer Pi-Hole

« on: December 15, 2018, 04:02:51 pm »

Das habe ich gerade mal versucht - allerdings geht dann gar keine DNS Anfrage mehr - das ist zu effektiv ;-)
Hab ich vielleicht grundsätzlich was falsch eingesellt? Mein OPNSense ist hinter einer Fritzbox 6590 Cable.

10

German - Deutsch / Re: Unbound und BIND anwenden als alternative fuer Pi-Hole

« on: December 15, 2018, 02:09:13 pm »

Na da hat der mimugmail leider recht...
unbound: [2736:0] error: duplicate forward zone . ignored.

11

German - Deutsch / Re: Unbound und BIND anwenden als alternative fuer Pi-Hole

« on: December 15, 2018, 12:14:12 pm »

Hi Rocker,
ansonsten hast du kein NAT eingerichtet, sondern nur den Code im Unbound bei erweitert eingegeben?
Muss man bei den Einrückungen im Code etwas beachten?
Bei mir geht es so nämlich leider nicht - das Queries oder Blocked Protokoll im BIND bleibt leer...
Viele Grüße
doc

12

German - Deutsch / Re: PI-Hole

« on: December 07, 2018, 06:06:16 pm »

So, Verkehr mal mitgeschnitten. Nachdem DNS Abfragen bei mir anscheinend über ipv4 und 6 parallel laufen, habe ich mal noch ein ipv6 Port Forward gemacht. Jetzt komme ich auch nicht mehr auf die OPNSense Oberfläche, weil mir UnboundDNS das nicht mehr umbiegt (also nur noch über IP). Allerdings komme ich immer noch auf die unerwünschte Seite. Der Mittschnitt ist eigentlich ganz simpel. PC fragt vom Port 51117 bei OPNSense auf Port 53 an und bekommt dann dann die Antwort (je auf IPV4 und 6).
Ich habe jetzt allerdings im BIND-Protokoll etwas komisches gefunden:

Code: [Select]

07-Dec-2018 17:52:12.692 query-errors: warning: client @0x1ff68461a00 IP#52859 (www.youporn.com): rpz QNAME rewrite youporn.com via youporn.com.blacklist.localdomain query_getzonedb()failed: : zone not loadedWas bedeutet denn das?

Und kann man dem Unbound bei den erweiterten Einstellungen

Code: [Select]

do-not-query-localhost: no
forward-zone:
name: „.“
forward-addr: 127.0.0.1@53530auch irgendwie ipv6 beibringen?
Viele Grüße

13

German - Deutsch / Re: PI-Hole

« on: December 05, 2018, 08:09:41 pm »

Nope, nur HAProxy, aber der sollte damit ja gar nix zu tun haben...

14

German - Deutsch / Re: PI-Hole

« on: December 05, 2018, 05:52:30 pm »

Hm, aber irgendwie läuft das zumindest nicht so, wie ich dachte - meine Vorstellung von Bind war, dass er den Zugriff verhindert, oder? Ich habe jetzt nämlich zwar Einträge bei blocked:

Code: [Select]

client @id IP#56442 (youporn.com): query: youporn.com IN AAAA + (127.0.0.1)aber die Seite öffnet sich einfach trotzdem im Browser.  Und das würde ich ja gerne verhindern ;-)
Bin über jeden Tipp dankbar - viele Grüße
doc

15

German - Deutsch / Re: PI-Hole

« on: December 05, 2018, 05:42:04 pm »

So, also mit deinem Port Forward funktioniert es - lustigerweise geht der Unbound trotzdem und biegt mir die DNS anfragen um, die ich brauche. Scheint also zu klappen ;-)
Vielen Dank und viele Grüße
doc