Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Gandalf2434

#1
Hallo zusammen,

ich habe bei mit Suricata laufen und erhalte durch einen Windowsrechner dauernd "ET SHELLCODE Common 0a0a0a0a Heap Spray String"-Meldungen. Da ich mir die Meldungen per Mail senden lasse und die alle paar Minuten kommen ist das sehr nervig.
Wie mal liest handelt es sich dabei wohl um eine Regel die zu False Positives neigt und anscheinend gerade mit Windows-Updates gerne mal fälschlicherweise anschlägt. Da es auch kein konkretes Angriffspattern ist, sondern eben Heap Spraying würde ich die Regel gerne deaktivieren.

So habe ich die Regel nun unter "Rules" deaktiviert und auch Suricata neu gestartet. Leider bekomme ich dennoch, sobald der Windows-Rechner läuft, die Meldungen vom System.

Kann mir jemand einen Stoß geben, was ich hier so grundlegend falsch mache? Ich hatte ich in der Vergangenheit schon andere Meldungen deaktiviert (z.B. .cc-Domains, da ich gerne dict.cc nutze), was da immer funktionierte.

Vielen Dank
#2
German - Deutsch / Re: OpnSense als Mailrelay [gelöst]
December 03, 2023, 10:42:30 AM
Der Aufwand den Postfix zu betreiben um alle Systeme im internen Netz auf einem einheitlichen Weg mit Mailanbindung zu versorgen.
Der Aufwand Container mir OpenSMTPd aufzusetzen um eine Kamera an diesen Standardisierten Weg anzubinen? Ja.

Wäre der Weg den Du beschreibst einfacher? Evtl. ja, aber es ist nunmal nicht der Weg den ich angestrebt habe. Zumal ich auch gewissen akademischen Antrieb hatte das so umzusetzen und keine Abkürzung zu nehmen.

Grüße
#3
German - Deutsch / Re: OpnSense als Mailrelay [Gelöst]
December 01, 2023, 08:09:20 AM
Vielen Dank nochmal für eure Hilfe!
Ich habe die Relay-Thematik in den Griff bekommen und das funktioniert nun. Danke. Ich weiß am Ende nicht genau was der springende Punkte war, aber ich glaube es hing damit zu sammen, dass ich den fqdn in eckige Klammern gepackt habe.

Die Authentifizierungs-Thematik konnte ich hierüber nicht umsetzen. Ich habe dafür einen Linux-Container hergenommen der mittels OpenSMTPd und Authentifizierung die Mails annimmt, an die OpnSense weitergibt, und die gibt sie dann an Posteo.

OpenSMTPd weil mir der doch deutlich sympathischer ist, eine klare und einfache Syntax hat und für mich schneller umzusetzen war.

Hier nochmal meine Zusammenfassung, sollte es später für jmd interessant sein:

Das Plugin `os-postfix` muss installiert werden. Nach einem refresh der
GUI ist der entsprechende Menüpunkt unter Services vorhanden.

Es wird zunächst ein neues internes Server-Zertifikat erstellt! (System -> Trust -> Certificates)
 
Anpassen der Postfix-Config:
* enable: <aktivieren>
* System Hostname: <Eigener Domainname, z.B. mail.meinedomain.de>
* IP Version: IP4
* Trusted Networks: <Die Netze und/oder Hosts die den Relay nutzen>
* Masquerade Domains: <entsprechend z.B. meinedomain.de>
* Server Certificate: <das erzeugte Zertifikat>
* Root CA: <Die CA des Zertifikats>
* SMTP Client Security: encrypt
* Smart Host: [posteo.de]:587
* Enable SMTP Authentication: <aktivieren>
* Authentication Username: <Die Mailadresse des Posteo-Kontos>
* Authentication Password: <Passwort des Accounts>
* Reject Unknown Sender Domain: <deaktivieren>
* Reject Unknown Recipient Domain: <deaktivieren>
* Permit SASL Authenticated: <deaktivieren>
* Permit TLS Client Certificate Authenticated Users <deaktivieren>

Um später eine Mail von einem Service zu senden müssen folgende
Voraussetzungen erfüllt sein:
* Port 25/TCP vom Host auf die Firewall muss allowed sein
* Der Host muss im Postfix über die "Trusted Networks" abgedeckt sein.
  Hier können ganze Netze (z.B. /24) oder einzelne Hosts (/32) angegeben
  werden
* in der sendenden Applikation:
    * Port 25
    * Adresse der Sense im jeweiligen Netzwerk
    * Authentifizierung deaktivieren
    * STARTTLS

Viele Grüße
#4
German - Deutsch / Re: OpnSense als Mailrelay
November 28, 2023, 08:32:25 AM
Quote from: Patrick M. Hausen on November 27, 2023, 09:55:33 PM
Also bei der lokalen Geschichte kann ich dir nicht helfen, weil ich genau das nicht will. Ich benutze den Postfix als Relay für meine ganzen Systemnachrichten hier. Isoliertes privates Netz, und das NAS, die USV, etc. pp. sollen da einfach die Mail abkippen.

Die geht dann authentifiziert über meinen Provider raus. Ich bastel mal einen hinreichend anonymisierten Screenshot. Bezgl. Posteo musst du dann leider selbst gucken.

Zwei Fragen hätte ich zu den Screenshots
1. Was steht in "Masquerade Domains"? Ist das dein Hostname der auch in "System Hostname" steht?
2. In welchem Format hast Du den Eintrag in "Smart Host" hinterlegt? Auch "Hostname:Port" ?

Ja ohne Authentifizierung ist im internen Netz natürlich schon praktisch und würde ich auch gerne so machen, wenn diese Reolink-Kameras nicht zwingend einen Benutzernamen und ein Passwort in der Oberfläche verlangen würden.

Vielen Dank.
#5
German - Deutsch / Re: OpnSense als Mailrelay
November 28, 2023, 08:24:54 AM
Also die Ports erreiche ich von der Sense aus, daran sollte es nicht hängen:


# telnet posteo.de 587
Trying 185.67.36.168...
Connected to posteo.de.
Escape character is '^]'.
220 submission01.posteo.de ESMTP Postfix



# telnet posteo.de 465
Trying 185.67.36.168...
Connected to posteo.de.
Escape character is '^]'.


VIelen Dank nochmal für due Hilfe.
#6
German - Deutsch / Re: OpnSense als Mailrelay
November 27, 2023, 09:43:27 PM
Das funktioniert leider nicht. Das Log sagt folgendes.


2023-11-27T21:31:41 Informational postfix/smtp 6F18A223D10: to=<XXXXX@XXXXXXXXX>, relay=mx01.posteo.de[185.67.36.61]:25, delay=0.64, delays=0.01/0/0.63/0, dsn=4.7.0, status=deferred (host mx01.posteo.de[185.67.36.61] refused to talk to me: 421 4.7.0 mx01.posteo.de Error: too many errors)
2023-11-27T21:31:40 Informational postfix/smtp 6F18A223D10: host mx04.posteo.de[185.67.36.64] refused to talk to me: 421 4.7.0 mx04.posteo.de Error: too many errors
2023-11-27T21:31:40 Informational postfix/smtp 6F18A223D10: host mx03.posteo.de[185.67.36.70] refused to talk to me: 421 4.7.0 mx03.posteo.de Error: too many errors
2023-11-27T21:31:40 Informational postfix/smtp 6F18A223D10: host mx01.posteo.de[185.67.36.62] refused to talk to me: 421 4.7.0 mx01.posteo.de Error: too many errors
2023-11-27T21:31:40 Informational postfix/smtp 6F18A223D10: host mx03.posteo.de[185.67.36.63] refused to talk to me: 421 4.7.0 mx03.posteo.de Error: too many errors
2023-11-27T21:31:40 Informational postfix/smtpd disconnect from unknown[10.10.99.102] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
2023-11-27T21:31:40 Informational postfix/qmgr 6F18A223D10: from=<XXXX@XXXXXX>, size=666, nrcpt=1 (queue active)
2023-11-27T21:31:40 Informational postfix/cleanup 6F18A223D10: message-id=<f20ef58dbb60bfbcb35146d1ad6b31f3e66b5fd9.camel@XXXXXX.XX>
2023-11-27T21:31:40 Informational postfix/smtpd 6F18A223D10: client=unknown[10.10.99.102]
2023-11-27T21:31:40 Warning postfix/smtpd warning: permit_tls_clientcerts is requested, but "smtpd_tls_ask_ccert = no"
2023-11-27T21:31:40 Error postfix/smtpd OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied
2023-11-27T21:31:40 Informational postfix/smtpd Anonymous TLS connection established from unknown[10.10.99.102]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
2023-11-27T21:31:40 Informational postfix/smtpd connect from unknown[10.10.99.102]


Mir ist dann aufgefallen, dass ich den Port nicht angegeben habe und habe dann für den SmartHost noch den Port angegeben, also "Posteo:587", doch auch das funktioniert nicht und liefert mir:

connect to mx04.posteo.de[185.67.36.71]:587: Operation timed out

Also dann noch ein Versuch über 465 (beide Ports bietet Posteo an, je nachdem ob STARTTLS oder normale TLS-Verbindung genutzt werden soll). Dafür muss ich dann noch bissl was umstellen: "requires setting "smtp_tls_wrappermode = yes", and "smtp_tls_security_level = encrypt" (or stronger)" sagt das Log.
Leider führt mich das auch wieder zu:
connect to mx01.posteo.de[185.67.36.62]:465: Operation timed out


Aber abgesehen davon, ist das alles ohne Authentifizierung gegen einen Usernamen. Tatsächlich würde ich ja aber gerne gegen einen Usernamen (Mail-Adresse & Passwort) authentifizieren.
#7
German - Deutsch / Re: OpnSense als Mailrelay
November 27, 2023, 09:07:46 PM
Vielen Dank für Deine schnelle Antwort.

Wenn ich das so einstelle, dann verlangt er eine Authentifizierung von mir. Aber mit dem Benutzername und dem Passwort das ich angelegt habe nimmt er es nicht an.

Ich hatte bisher meine Netzwerke in die Trusted Networks hinzugefügt, dann konnte ich ihne Authentifizierung versenden (aber genau das ist ja mein Problem im Moment) ;)  Wenn ich das rausnehme geht es nicht.

Das Log sagt:

2023-11-27T21:06:10 Warning postfix/smtpd warning: unknown[10.10.99.102]: SASL PLAIN authentication failed: authentication failure
2023-11-27T21:06:10 Warning postfix/smtpd warning: SASL authentication failure: Password verification failed
2023-11-27T21:06:10 Error postfix/smtpd OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied
2023-11-27T21:06:04 Warning postfix/smtpd warning: unknown[10.10.99.102]: SASL PLAIN authentication failed: authentication failure
2023-11-27T21:06:04 Warning postfix/smtpd warning: SASL authentication failure: Password verification failed
2023-11-27T21:06:04 Error postfix/smtpd OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied
2023-11-27T21:06:04 Informational postfix/smtpd Anonymous TLS connection established from unknown[10.10.99.102]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
2023-11-27T21:06:04 Informational postfix/smtpd connect from unknown[10.10.99.102]
#8
German - Deutsch / OpnSense als Mailrelay [gelöst]
November 27, 2023, 08:24:10 PM
Hallo zusammen,

ich möchte gerne meine Sense als Mailrelay nutzen, so dass die Systeme im internen Netz Mails an die Sense senden können und diese die Mails dann über einen öffentlichen Mailserver versenden.

Hierzu gab es auch schonmal eine Unterhaltung mit dem Ergebnis, dass diese Funktion hinzugefügt wurde: https://forum.opnsense.org/index.php?topic=7538.0

Leider steht hier gar nicht dabei wie das nun umzusetzen ist.
Ich habe das Plugin os-postfix installiert und habe es so konfiguriert, dass ich nun ohne Authentifizierung Mails von internen VLients in die Welt senden kann.
Was mir jedoch fehlt ist eben eine Authentifizierung an der Sense. Ich habe einen neuen User angelegt, finde allerdings keine Option um hier ein sasl für den smtpd zu setzen.

Auch kann ich nicht über den Smartrelay (in meinem Fall posteo) senden, ich kann nur direkt von der Sense an den Zielserver zustellen (damit komme ich z.B. nicht auf gmail-Adressen).

Ich habe eine Reolink-IP-Kamera die Mails bei Bewegungserkennung versenden kann. Das Interface der Kamera verlangt allerdings zwingend die Angabe einer Mailadresse und eines Passworts zur Authentisierung. Lasse ich die Felder einfach leer, kann ich die Konfiguration nicht speichern da es Muss-Felder sind. Ich will die Kamera aber nicht direkt ins Internet lassen damit sie mit einem Mailserver reden kann. Daher würde ich auch hierfür gerne die Sense nutzen, aber brauche wohl eine Authentisierung.

Gibt es hier evtl. jemand der mir hier einen guten Tipp geben könnte?
#9
General Discussion / Re: UDP Broadcast Relay
May 24, 2022, 10:42:34 AM
Hey there,

I already posted a thread in the german forum here (https://forum.opnsense.org/index.php?topic=28465.0) but I think this might be better placed here. I beg your pardon for  the crosspost.

I use the plugin to transmit some multicast packets between my vlans. This is working great for normal vlans, but not for my OpenVPN. I connect some devices per OpenVPN. Those devices are in the OpenVPN network (10.10.0.0/24 in my case).
The plugin lets me select the networks to serve, but the OpenVPN-network is not listed, so I can't use it over vpn.

Does anyone have suggestions how to solve this issue?

Thanks alot
#10
Hallo zusammen,

ich habe auf der Opnsense einen VPN aktiviert mit dem ich meine Mobilgeräte ins interne Netzwerk hole. Zusätzlich verwende ich "UDP Broadcast Relay" um Multicast-Messages (wie MDNS und SSDP) zwischen den VLANs zu verteilen. Das funktioniert auch grundsätzlich gut, nur kann ich es nicht für die Teilnehmer im VPN verwenden, da das VPN bei den Relay-Interfaces nicht zur Auswahl steht.

Das ist sehr schade, da ich damit einige Funktionen nicht nutzen kann, die ich gerne nutzen würde. Habt ihr da eine Idee für mich wie ich das noch umsetzen könnte?

Dankeschön!
#11
Problem gelöst....  Leider habe ich es trotz mehrmaliger Kontrolle übersehen, dass ich die pf-Regel auf tcp geetzt hatte.
#12
Hallo zusammen,

ich habe mein Netzwerk zu Hause angepasst und stolpere leider über ein sehr nerviges Problem bzgl. mDNS und hoffe ihr könnt mir auf die Sprünge helfen.

Ich habe einen Raspberry im Netzwerk der mittels Raspotify als "Spotify-Connect" Lautsprecher Musik abspielen soll. Gesteuert wird das Ganze über die Spotify-App die entweder auf dem Smartphone oder auf dem Notebook läuft. Alle Geräte befinden sich in unterschiedlichen vlans. Spotify benötigt mDNS um den Lautsprecher zu finden. Leider funktioniert das nur vom Notebook aus und nicht vom Smartphone. Ich bin mittlerweile etwas hilflos...
Das schönste Phänomen ist allerdings das folgende:

  • Der Rasperry ist gebootet
  • Ich starte die App auf dem Handy
  • Der Raspberry wird nicht gefunden (ich kann warten bis St. Nimmerlein)
  • Ich starte die Spotify-App auf dem Notebook
  • Der Raspberry erscheint sofort als Lautsprecher auf dem Notebook und auf dem Smartphone
Auf mich macht es also den Eindruck als kämen die mDNS-Anfragen aus dem WLAN-Netz nicht beim Raspberry an. Sobald das Notebook jedoch seine Anfrage losschickt bekommt das auch das Smartphone mit. Aber evtl liege ich auch völlig daneben.
Sobald ich das Notebook in das WLAN hänge findet es den Lautsprecher auch nicht mehr.

Im Anhang ist eine schematische Darstellung des Netzwerks.


  • 3 vlans

    • vlan10: vertrauenswürdige Geräte die per Ethernet verbunden sind (mein Notebook)
    • vlan50: vertrauenswürdige Geräte die per WLAN verbunden sind (mein Smartphone)
    • vlan70: Lautsprecher. Hier ist der Raspotify verortet
  • Die vlans werden durch eine OpnSense verbunden
  • Spotify benötigt mDNS zum Discovery der Lautsprecher (224.0.0.251:5353)
  • Auf der OpnSense ist das Plugin UDP Boradcast Relay konfiguriert um die mDNS-Pakete in die anderen Netze zu befördern.

    • Alle drei vlans sind eingetragen
    • Wie man am Notebook sieht scheint das ja auch grundsätzlich zu funktionieren
  • Smartphone ist ein Android
  • Notebook ist ein Linux mir Spotify-Linux-App
  • Raspotify ist ein Raspbian
  • WLAN AP ist ein Mikrotik, nachdem ich dachte, dass ich zu blöd bin das Ding zu konfigurieren habe ich es jedoch auch mit einem alten TP-Link mit OpenWRT versucht mit identischem Ergebnis.
Auch an den Firewall-Regeln auf der OpnSense könnte ich nun nicht erkennen wo da Problem liegen sollte:
Für das Lautsprecher-Netz

pass in quick on lagg0_vlan70 inet proto udp from (lagg0_vlan70:network) to 239.255.255.250 port = 1900 keep state
pass in quick on lagg0_vlan70 inet proto udp from (lagg0_vlan70:network) to 224.0.0.251 port = mdns keep state
pass in quick on lagg0_vlan70 inet proto tcp from (lagg0_vlan70:network) to <InterneDNS> port = domain flags S/SA keep state
pass in quick on lagg0_vlan70 inet proto udp from (lagg0_vlan70:network) to <InterneDNS> port = domain keep state
block drop in quick on lagg0_vlan70 inet from any to <InternetRouter>
block drop in quick on lagg0_vlan70 inet from any to (self)
pass in quick on lagg0_vlan70 route-to (igb0 192.168.1.1) inet from (lagg0_vlan70:network) to any flags S/SA keep state


Für das Trusted-Netz

pass in quick on lagg0_vlan10 inet proto icmp from (lagg0_vlan10:network) to any keep state
pass in quick on lagg0_vlan10 inet proto tcp from any to <InterneDNS> port = domain flags S/SA keep state
pass in quick on lagg0_vlan10 inet proto udp from any to <InterneDNS> port = domain keep state
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to (lagg0_vlan70:network) port = lupa flags S/SA keep state
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to (lagg0_vlan70:network) port = 60006 flags S/SA keep state
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to (lagg0_vlan70:network) port = http flags S/SA keep state
pass in quick on lagg0_vlan10 inet proto udp from (lagg0_vlan10:network) to 224.0.0.251 port = mdns keep state
pass in quick on lagg0_vlan10 inet proto udp from (lagg0_vlan10:network) to 239.255.255.250 port = 1900 keep state
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to (lagg0_vlan70:network) port = ssh flags S/SA keep state
block drop in quick on lagg0_vlan10 inet from any to (self)
block drop in quick on lagg0_vlan10 inet from any to <InternetRouter>
pass in quick on lagg0_vlan10 route-to (igb0 192.168.1.1) inet from (lagg0_vlan10:network) to any flags S/SA keep state


Für das WLAN-Netz

pass in quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to <InterneDNS> port = domain flags S/SA keep state
pass in quick on lagg0_vlan50 inet proto udp from (lagg0_vlan50:network) to <InterneDNS> port = domain keep state
pass in quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port = lupa flags S/SA keep state
pass in log quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port = 60006 flags S/SA keep state
pass in log quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port = http flags S/SA keep state
pass in log quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port = rtsp flags S/SA keep state
pass in log quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port 49152:49154 flags S/SA keep state
pass in quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to 224.0.0.251 port = mdns flags S/SA keep state
pass in quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to 239.255.255.250 port = 1900 flags S/SA keep state
block drop in quick on lagg0_vlan50 inet from any to <InternetRouter>
block drop in quick on lagg0_vlan50 inet from any to (self)
pass in quick on lagg0_vlan50 route-to (igb0 192.168.1.1) inet from (lagg0_vlan50:network) to any flags S/SA keep state


Vielleicht kann mir jemand einen Tipp geben warum das über das WLAN nicht funktioniert. Vielen Dank!

Edit: Ich habe mal ein Packet Capture der drei Interfaces gezogen und in Wireshark geworfen. Vom vlan50 kommen definitiv keine mDNS-Pakete im vlan70 an. Vom vlan10 jedoch kommen die mDNS-Pakete
#13
General Discussion / Re: Rule not shown in pfctl
October 02, 2021, 06:08:55 PM
Well it seems as OpnSense does not like to see backslashes in Descriptions...
I first thought so and changed the description of the rule, but nothing changed. (Of course I applied the changes every time). Then I created a new rule with a different desctiption (without special characters) and it was working. Deleted the old rule, changed the description of the new one to /!\ ANTI LOCKOUT /!\ and it was gone again.....
So... you have to be careful choosing descriptions.
#14
General Discussion / Rule not shown in pfctl
October 02, 2021, 05:52:28 PM
Hey there,
I deactivated the automatic anti-lockout-rules because they were put only on my IoT-VLAN-Interface (which doesn't make much sense). I have a seperate vlan for management-purpose (vlan90 and the OpnSense listens there on IP 10.10.90.1/24 for https and ssh). So I wanted to create my own anti-louckout-rules to allow my trusted network (vlan10 10.10.10.0/24) to connect there.
I created the following rules for my "Trusted" interface (see also attachment).


PASS in quick IPv4 TCP Trusted net * 10.10.90.1 443 (HTTPS) * * /!\ ANTI LOCKOUT /!\
PASS in quick IPv4 TCP Trusted net * 10.10.90.1 22 (SSH) * * /!\ ANTI LOCKOUT /!\


Well the rule for https is working, I can connect to the WebGui. But the rule for ssh is not working. That said I logged in to the OpnSense and did a pfctl -s rules and found that the ssh-rule isn't even there. I only find the rule for https:
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to 10.10.90.1 port = https flags S/SA keep state label "347979aabfc8b8e68a6b5c3fccb9ee7e" but no rule for the ssh traffic.

root@opnsense:~ # pfctl -s rules | grep 10.10.90.1
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to 10.10.90.1 port = https flags S/SA keep state label "347979aabfc8b8e68a6b5c3fccb9ee7e"


Could you give me a hint what  could do?! I already edited the rule several time, pushed it to different places in the ruleset and even did a reboot.

Thanks for your help, cause I feel not very confident.
#15
Thanks a lot. I am reading the posts and try to get my infos there.