OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of superwinni2 »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

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.

  • Messages
  • Topics
  • Attachments

Messages - superwinni2

Pages: 1 ... 28 29 [30] 31 32 ... 37
436
German - Deutsch / Re: ELK Stack / Logging / Rollup Job
« on: June 03, 2019, 08:54:30 am »
Habe vor einiger Zeit die config mal wie folgt angepasst:
Kannst du bitte mal drüber schauen ob es so richtig ist?


Code: [Select]
input {
  tcp {
    port => 5140
    type => syslog
  }


  udp {
    port => 5140
    type => syslog
  }
}


filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "<%{POSINT:syslog_pri}>%{SYSLOGTIMESTAMP:syslog_timestamp} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
    }


    mutate { strip => ["syslog_message"] }


    if [syslog_program] == "devd" {
      if "!system=CAM" in [syslog_message] {
        grok {
          match => {"syslog_message" => "Processing event %{QUOTEDSTRING:data}"}
        }


        kv {source => "data"}


        mutate { remove_field => 'data' }
      }


      drop { }
    }


    if [syslog_program] == "filterlog" {
      opnsensefilter { field_name => "syslog_message" }


      geoip { source => "source" }


      if [geoip.ip] {
        geoip {
          source => "source"
          target => "destination"
        }
      }


      if ![geoip.ip] {
        geoip { source => "destination" }
      }
    }


    if [syslog_program] == "suricata" {
      geoip { source => "src_ip" }


      if [geoip.ip] {
        geoip {
          source => "src_ip"
          target => "dest_ip"
        }
      }


      if ![geoip.ip] {
        geoip { source => "dest_ip" }
      }
    }


    if [syslog_program] == "opnsense" {
      if "for" in [syslog_message] and "from" in [syslog_message] {
        mutate { add_field => {'os_type' => 'auth'} }


        if "from:" in [syslog_message] {
          grok {
            match => {
              "syslog_message" => "%{DATA:scriptname}: %{DATA:login_status} for user '%{USERNAME:username}' from: %{DATA:ip}"
            }
          }
        } else {
          grok {
            match => {
              "syslog_message" => "%{DATA:scriptname}: %{DATA:login_status} for '%{USERNAME:username}' from %{DATA:ip}"
            }
          }
        }
      }
    }


    if [syslog_program] == "configd.py" {
      if "message" in ["syslog_message"] {
        grok {
          match => {
            "syslog_message" => "message %{UUID:uuid} \[%{DATA:action_name}\] returned %{WORD:status_word}.*"
          }
        }
      }


      if [syslog_message] =~ "^\[.+?\]" {
        grok {
          match => {"syslog_message" => "\[%{UUID:uuid}\] %{GREEDYDATA:configd_message}"}
        }
      }


      if [syslog_message] =~ "^\S+* generated \S+$" {
        grok {
          match => {"syslog_message" => "^%{NOTSPACE:component_name} generated %{NOTSPACE:file_name}$"}
        }
      }


      #mutate { remove_field => 'syslog_message' }
    }


    if [syslog_program] == "/usr/sbin/cron" {
      grok {
        match => {"syslog_message" => "\(%{USER:user}\) CMD %{GREEDYDATA:cron_message}"}
      }


      mutate { remove_field => 'syslog_message' }
    }


    if [syslog_program] in ["ospfd", "ospf6d"] {
      if ":" in [syslog_message] {
        grok {
          match => {"syslog_message" => "%{DATA:component}: %{GREEDYDATA:sub_message}"}
        }
      }


      if ":" in [sub_message] and "# Areas" not in [sub_message] {
        grok {
          match => {"sub_message" => "%{DATA:subcomponent}: %{GREEDYDATA:msg}"}
        }


        mutate { remove_field => "sub_message" }


        mutate { rename => {"msg" => "sub_message"} }
      }


      if [syslog_message] =~ /^\S+\(\S+\).*/ {
        grok {
          match => {"syslog_message" => "%{NOTSPACE:component}\(%{NOTSPACE:function_name}\) %{GREEDYDATA:sub_message}"}
        }
      }


      if [component] == "SPF" {
        grok {
          match => {"sub_message" => "Scheduled in %{NUMBER:scheduled} msec"}
        }
      }


      if [component] == "SPF processing" {
        grok {
          match => {"sub_message" => "# Areas: %{NUMBER:number_areas}, SPF runtime: %{NUMBER:runtime_sec} sec %{NUMBER:runtime_usec} usec, Reason: %{GREEDYDATA:reason}"}
        }
      }
    }


    #"SPF processing: # Areas: 1, SPF runtime: 0 sec 0 usec, Reason: R+, R-"
    #"OSPF6d (Quagga-1.2.1 ospf6d-0.9.7r) starts: vty@2606"
    if [syslog_program] == "zebra" {
      #"client 18 says hello and bids fair to announce only ospf6 routes"
    }
  }




  #Hier werden alle Felder/Keys eingegeben, welche nicht an Elasticsearch übermittelt werden sollen.
  mutate {
    remove_field => [
                      "ack_number",
                      "aid",
                      "ecn",
                      "direction_of_traffic",
                      "flags",
                      "[geoip][continent_code]",
                      "[geoip][country_code2]",
                      "[geoip][country_code3]",
                      "[geoip][ip]",
                      "[geoip][latitude]",
                      "[geoip][longitude]",
                      "[geoip][region_name]",
                      "[geoip][region_code]",
                      "[geoip][postal_code]",
                      "[geoip][timezone]",
                      "hop_limit",
                      "ip_version",
                      "length",
                      "message",
                      "myoffset",
                      "options",
                      "protocol_id",
                      "reason",
                      "sequence_number",
                      "subrule",
                      "syslog_message",
                      "syslog_pri",
                      "syslog_program",
                      "syslog_timestamp",
                      "tags",
                      "tcp_flags",
                      "tos",
                      "type",
                      "urgent_pointer",
                      "window"
                    ]
  }
}


output {
  #stdout { codec => rubydebug }
  elasticsearch {
    hosts =>  "http://localhost:9200"
    index => "logstash-opnsense-syslog-%{+YYYY.MM.dd}"
  }
}


Oder gibt es noch irgendwelche Verbesserungsvorschläge?


Danke und Gruß

437
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 27, 2019, 10:01:29 am »
Hi wirehire


also habe eben mal bei mir nachgeschaut... Ich habe ebenfalls HAProxy mit SSL Backends / Realen Servern am laufen. Dürfte somit kein Problem sein....


Was ich noch sagen/schreiben wollte: Wenn di e Anleitung fertig hast, schau ich gerne mal noch drüber... Habe wie gesagt auch schon probiert eine Anleitung zu schreiben... Ist jedoch nicht ganz so einfach... :P

438
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 25, 2019, 04:06:34 pm »
Sehr gut

Wenn man die Logik verstanden hat, ist es ganz einfach

Viel Spaß

Gesendet von meinem LG-H815 mit Tapatalk


439
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 11:49:19 pm »
Wenn ich alles beantworte ohne Fragen zu beantworten ist immer ein sehr gutes Zeichen ;)




Wenn du intern unbedingt verschlüsselt kommunizieren willst, mach nen selbst signiertes Zertifikat, richte den BackendServer dementsprechend ein und dann sollte es passen.
ACHTUNG hier kommen noch mehr Funktionen der OPNsense hinzu: (Zertifikatverwaltung)
Wenn du dem nicht ganz vertraust oder sichergehen willst, dass das Zertifikat nicht verändert worden ist, kannst du auch eine Certificate Authority (CA) erstellen. Dann das Zertifikat für deinen Server ausstellen und dort importieren und dann beim Backend auch noch das "Überpüfe Gültigkeit des Zertifikates" aktivieren.


Falls es auch morgen noch Probleme gibt.. Einfach melden ;)

440
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 11:29:38 pm »
schön zu hören das es funktioniert :)


Also eigentlich sollte es kein Problem geben, auch intern über https zu kommunizieren.
Muss mal schauen ob ich dies irgendwo so habe, aber ich glaube ich habe intern bisher immer so gut wie nur unverschlüsselte Verbindungen...
Kann ich aber sicher auch mal noch die Tage irgendwie testen wenn ich einen freien Moment dafür finde.


Das was du vorhast, könnte etwas knifflig werden oder sogar unmöglich sein...
Du willst den Backend Server mit LetsEncrypt verschlüsseln? Was genau willst du damit bezwecken? Normalerweise ist ja nun das schöne an dem HAProxy, dass er dir die ganzen "Sorgen" mit Letsencrypt und dem Reverse Proxy abnimmt. Somit braucht es deinen Server nicht mehr kümmern ob das Zertifikat gültig ist oder nicht.
Damit dein Server zudem über Letsencrypt ein Zertifikat bekommt, muss er öffentlich mit Port 80 erreichbar sein. Aber genau das wollen wir ja nicht und verstecken deshalb den Server hinter dem HAProxy.


Bei deiner Anleitung für mailcow wird  auch das ssl zertifikat vom HAProxy gegeben. Siehe "ssl crt mailcow.pem". Ich vermute "mailcow.pem" wird das gültige zertifikat sein.
Dieses wird dann vom HAProxy veröffentlicht. Im Backend redet der HAProxy mit mailcow unverschlüsselt über Port 8080. Denn verschlüsselt wäre der Port nur mit 8443 von mailcow.


Was du mir genau mit deiner Frage fragen willst verstehe ich nicht.. vielleicht bin ich aber auch schon zu müde dafür :P




441
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 10:40:31 pm »
Kein Problem ;)
Vielleicht kommt auch jemand und schreit "aber das geht viel besser" :)
Falls das jemand liest und dies denkt darf er gerne zwischen rein schreien :P
Ich bin immer offen für Kritik :D

442
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 10:35:31 pm »
Ahhh großer Fehler... Ich glaube der passiert jeden...
Du brauchst zwei Frontends...
 - ein http Frontend
 - ein https Frontend


Diese Frontend "reagieren" entweder auf deine http Anfragen bzw auf deine https Anfragen....
PS. Ich weiß nicht ob es funktioniert, dass man im Backend angibt die Regel "find_acme_challenge" benutzt... Ich benutze sozusagen meine eigene im Frontend... Aber auch hier führen vielleicht viele Wege nach Rom :)


Also ich würde folgendes machen:
Code: [Select]

"Ganz von vorne anfangen"
Frontend für http anlegen
Frontend für https anlegen
Conditions erstellen
  - host_ist_matterhost  -> Host matches matterhost.example.com
  - host_ist_nextcloud   -> Host matches nextcloud.example.com
  - find_acme_challenge  -> Pfad beginnt mit /.well-known/acme-challenge/
  - nicht_acme_challenge -> Pfad beginnt nicht mit /.well-known/acme-challenge/


Dann folgende Regeln erstellen
  - SSL_Redirect_matterhost -> host_ist_matterhost & nicht_acme_challenge -> http-request redirect "scheme https code 301"
  - SSL_Redirece_nextcloud  -> host_ist_nextcloud & nicht_acme_challenge  -> http-request redirect "scheme https code 301"
  - Backend_matterhost      -> host_ist_matterhost & nicht_acme_challenge -> Benutze backend "Matterhost"
  - Backend_nextcloud       -> host_ist_nextcloud & nicht_acme_challenge  -> Benutze backend "Nextcloud"
  - Backend_acme            -> find_acme_challenge                        -> Benutze Backend "acme"


Dann die Regeln aus deinen Backends löschen... Regeln benutze ich nur im Frontend.
Regeln für http Frontend:
  - SSL_Redirect_matterhost
  - SSL_Redirect_nextcloud
  - Backend_acme


Regeln für https Frontend:
 - Backend_matterhost
 - Backend_nextcloud


Dann nochmals probieren...
Ich hoffe ich habe nichts vergessen um alles bei dir abzubilden ;) Falls ja bitte ich um verzeihung.. Dann suchen wir den Fehler erneut ;)

443
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 09:53:35 pm »
Ich würde es auf den Hostnamen ändern... du brauchst auf jeden fall eine unterscheidung zwischen den eizelnen anfragen / servern... Hier bietet sich eigentlich so gut wie immer der FQDN an.
Daher würde ich die Condition z.B. ändern auf "mattermost.domain.xyz" und wenn beispielsweise irgendwann noch ne Wordpress dazu kommt dann gibts ne neue regel die besagt wenn wordpress.domain.xyz aufgerufen wird soll das Backend von Wordpress greifen.


Musst natürlich soweit mitdenken, dass bei dir auch noch letsencrypt läuft ;)
Darfst aber natürlich gerne wieder die config posten und dann schau ich mir an was du zusammen konfiguriert hast :)

444
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 09:24:04 pm »
Achsooo
Ja das ist natürlich mehr als sinnvoll ;)
Das mit dem Pfad finde ich nur relevant wegen der Acme challenge... Ansonsten will man die einzelnen Backends ja eher über den Domainnamen trennen


Hier mal noch spaßeshalber meine Config von mir zuhause:
Vielleicht liest du ja raus was du brauchst, ansonsten bin ich gerne für Fragen offen.
Habe zuhause aktuell jedoch nur eine Seite "öffentlich"... Mein WP Server ist deszeit "offline"
Code: [Select]
root@OPNsense1:~ # cat /usr/local/etc/haproxy.conf
#
# Automatically generated configuration.
# Do not edit this file manually.
#


global
    # NOTE: Could be a security issue, but required for some feature.
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket level admin
    nbproc                      1
    nbthread                    1
    tune.ssl.default-dh-param   1024
    spread-checks               0
    tune.chksize                16384
    tune.bufsize                16384
    tune.lua.maxmem             0
    log /var/run/log local0


defaults
    log     global
    option redispatch -1
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3


# autogenerated entries for ACLs


# autogenerated entries for config in backends/frontends


# autogenerated entries for stats




# Frontend: WAN_https ()
frontend WAN_https
    http-response set-header Strict-Transport-Security "max-age=15768000"
    bind 192.168.178.4:443 name 192.168.178.4:443 ssl no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 crt-list /tmp/haproxy/ssl/5c852b4aef9e88.45675078.certlist
    bind 192.168.178.191:443 name 192.168.178.191:443 ssl no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 crt-list /tmp/haproxy/ssl/5c852b4aef9e88.45675078.certlist
    mode http
    option http-keep-alive
    option forwardfor
    # tuning options
    timeout client 1m


    # logging options
    option httplog
    # ACL: Host_ist_push_domain_xyz
    acl acl_5cdf1ec3cfc2b4.19528643 hdr(host) -i push.domain.xyz


    # ACTION: SSL Redirect ungültig
    http-request redirect location http://google.de unless acl_5cdf1ec3cfc2b4.19528643


    # ACTION: Rule_backend_gotify
    use_backend BackendPool_Gotify if acl_5cdf1ec3cfc2b4.19528643


# Frontend: WAN_http ()
frontend WAN_http
    bind 192.168.178.191:80 name 192.168.178.191:80
    bind 192.168.178.4:80 name 192.168.178.4:80
    mode http
    option http-keep-alive
    # tuning options
    timeout client 30s


    # logging options
    option httplog
    # ACL: Pfad_beginnt_mit_acme_challenge
    acl acl_5ca7b6170c5440.28623250 path_beg -i /.well-known/acme-challenge/
    # ACL: Host_ist_push_domain_xyz
    acl acl_5cdf1ec3cfc2b4.19528643 hdr(host) -i push.domain.xyz
    # ACL: Pfad_beginnt_nicht_mit_acme_challenge
    acl acl_5cdf296b57e264.72995214 path_beg -i /.well-known/acme-challenge/


    # ACTION: SSL Redirect für gültige Seiten
    http-request redirect scheme https code 301 if acl_5cdf1ec3cfc2b4.19528643 !acl_5cdf296b57e264.72995214
    # ACTION: SSL Redirect ungültig
    http-request redirect location http://google.de unless acl_5cdf1ec3cfc2b4.19528643


    # ACTION: redirect_acme_challenges
    use_backend acme_challenge_backend if acl_5ca7b6170c5440.28623250


# Backend: BackendPool_WP ()
backend BackendPool_WP
    # health checking is DISABLED
    mode http
    balance source


    # tuning options
    timeout connect 1m
    timeout server 30s
    http-reuse never
    server realWP 10.10.20.101:80


# Backend: acme_challenge_backend (Added by Let's Encrypt plugin)
backend acme_challenge_backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse never
    server acme_challenge_host 127.0.0.1:43580


# Backend: BackendPool_Gotify ()
backend BackendPool_Gotify
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse never
    server gotify 10.10.20.110:8080

445
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 08:48:31 pm »
Das klingt ja schonmals nicht schlecht ;)


Wegen dem weiteren Dienst:
Backend anlegen, Pool anlegen und Regeln nicht vergessen ;)
Das Frontend ist ja das gleiche... Es greift dann nur eine andere Regel bei der Auswahl des Backends.

446
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 05:26:29 pm »
Theoretisch ja.. Wie gut oder schlecht das allerdings geht... Keine Ahnung mehr

Gesendet von meinem LG-H815 mit Tapatalk


447
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 05:00:31 pm »
Ansonsten mal ein zwei Sätze über HAProxy lesen und über dann Änderungen machen und die config über die Konsole anschauen und verstehen was es ändert...
Dann eine Logik entwickeln was wie reagieren soll und dann umsetzen ;)

Was ich noch sagen kann: Die redirect rules greifen immer vor dem anderen Regeln...
Als diesem Grund muss die http zu https redirect Regel auch das "nicht acme Pfad" sein haben...

Gesendet von meinem LG-H815 mit Tapatalk


448
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 04:07:38 pm »
Quote from: wirehire on May 24, 2019, 03:39:28 pm
bisher ist ja im client schon ssl in nginx hinterlegt. muss das raus?

ich muss mal schauen wie ich das mit dem letsencrypt plugin hinbekomme.

man merkt das Du dich sehr gut auskennst, ich finde immer das die Howtos generell so einen Weg einmal auch mit Bilder aufzeichenen sollten :), erstelle ichd ann auch gerne wenn es läuft. Ich glaube das geht vielen so das es bildlich mit einem example am besten in den Kopf sickert :).

Also ssl am Server muss nicht raus... Ich persönlich "vertraue" meinem DMZ Bereich und lasse hinter dem HAProxy alles als http laufen... Dann ist die Fehlerquelle "doppeltes https" auch weg...

Das ist relativ easy mit dem letsencrypt....
Plugin konfigurieren (am besten mit der HAProxy Unterstützung da er dann das backend automatisch anlegt)
Dann im http interface eine Regel anlegen mit
"wenn der Pfad der acme Pfad ist dann auf das backend vom acme"
 und Gleichzeitig eine Regel mit
"wenn der url deine gewünschten Domains und nicht acme Pfad dann auf https"

Kleiner Tipp wegen dem negieren von Sachen...
Lege eine Bedingung an mit
"ist acme Pfad" und  der mit "ist nicht acme Pfad"
Der Unterschied sollte nur der Haken "negate condition" oder wow es heißt sein...
Dann kannst dir deine Regeln zusammenbauen ;)

Falls es nicht klappt, bin nachher am Rechner, dann schreibe ich genauer mit Anleitung


PS Anleitung... Ja sowas wollte ich auch machen und habe mich bereits daran versucht... Aber damit das dann auch für alle gilt und gültig sein kann muss einiges beachtet werden...

Gesendet von meinem LG-H815 mit Tapatalk


449
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 03:29:31 pm »
Nochmals wieder kurz
Du musst auch ein frontend für https anlegen.
Ich gehe mal davon aus, dass alle deine Seiten am Ende auf https laufen sollen.

Dann im http frontend eine Regel anlegen das alles was nicht den Pfad ./well-known (oder wie der acme Pfad lautet) ist auf https weiterleitet.
Dann im https frontend die Regeln erstellen, damit er anhand vom Domain Namen das passende Backend nimmt...
Dann müsste es glaub klappen...
Das wegen dem acme brauchst du später für letsencrypt

Gesendet von meinem LG-H815 mit Tapatalk


450
German - Deutsch / Re: HAProxy: Rule Verständnisfrage
« on: May 24, 2019, 02:57:11 pm »
Sorry für die kurze Antwort... Bin grad am Handy und nicht am Rechner...
Das wegen der log liegt wahrscheinlich am frontend... Trage mal die richtige WAN Adresse oder einfach 0.0.0.0 ein... Dann solltest du auch was sehen...

Gute Ansatz zuerst zu schauen ob was in der log kommt *daumenhoch*

Und wegen deiner NAT rule... Ich glaub habe bei mir noch nie eine eingetragen... Immer nur die FW Regel gemacht...
Wenn du eine machst, musst glaub noch das "No RDR" aktivieren

Gesendet von meinem LG-H815 mit Tapatalk

Pages: 1 ... 28 29 [30] 31 32 ... 37
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2