Messages

Ahoi hoi und tüdelü

[...]

Nice Geschichte, Danke!

Ja, das ist Cisco. Da gibt es auch eine Security Weiterbildung.
[...]

Top, schaue ich mir mal an, Danke!

Sinnvoll wäre abgesehen von LPIC noch zum Beispiel
* CCNA oder ähnliches
* was halt mit ISO 27001 zusammen hängt.
* BSI Grundschutz

CCNA ist das Cisco Zertifikat? Das habe ich bereits, das wurde damals in meiner Ausbildung mit gemacht, ist aber auch schon über 10 Jahre her. Da gibt es glaube ich aber auch noch weiterführende Programme von Cisco, müsste ich mich mal schlaumachen.

Und speziell im Firewall und Security/Pentesting Sektor, gibt es dort auch noch Spezialisierungen? Im CCNA haben wir viel mit Routing, Subnetting und IP-Protokollen gemacht, wenn ich mich richtig erinnere, wie gesagt, ist schon ziemlich lange her.

Hallo,

diese Frage ist zwar eher offtopic aber dennoch würde mich generell mal interessieren, welche Zertifikate und Weiterbildungen im Linux/Unix Umfeld am meisten Sinn ergeben? Es gibt da zum Beispiel die LPIC Reihe, wie gefragt sind Leute mit solchen Zertifizierungen - wie ist es mit den beruflichen Aussichten wie Aufstiegschancen und Gehälter?

Gibt es für IT-Security und Firewalls gleichwertige Zertifizierungen? Wenn ja welche Auswahl gibt es hier konkret?

Würde mich auch über Erfahrungsberichte freuen, Danke!

Grüße

Verstehe das Problem nicht, warum soll die sense nicht auflösen können? Alternativ kann man Unbound auch als Forwarder konfigurieren, mit Windows Domain Controller kenne ich mich nicht aus, aber wenn du vom DC selber einen lokalen revers DNS aufgelöst bekommst, warum sollte dann die Sense dies nicht auch können, quasi respektive als Forwarder?

Es funktioniert, hab gerade die Einstellung nochmal überprüft :)

Bei Einstellung -> System -> Allgemein -> Verwenden Sie den lokalen DNS-Dienst nicht als Nameserver für dieses System

Als DNS Dienst verwende ich Unbound und überschreibe dort einfach meine Lokalen Hosts.

Nur fürs Protokoll, habe es selber gelöst in dem ich die beiden anderen Anschlüsse noch als Gateways hinzugefügt habe, also keine Portweiterleitung oder Ähnliches erforderlich. Jetzt funktioniert die Synchronisierung mittels NTP wieder.

Okay, ich glaube ich habe eine Idee. Mein gesamter LAN traffic geht über einen TCPStack von zwei DSL Anschlüssen zu einem VPS. Nun habe ich mit einer test Linux Server VM, direkt über eine der beiden DSL Leitungen NTP synchronisiert und siehe da, hier erhalte ich eine Antwort.

root@debian-test-server:/# nano /etc/hosts
root@debian-test-server:/# ntpdate -d 0.opnsense.pool.ntp.org
29 Jul 03:49:18 ntpdate[505]: ntpdate 4.2.8p12@1.3728-o (1)
Looking for host 0.opnsense.pool.ntp.org and service ntp
213.172.105.106 reversed to ns1.blazing.de
host found : ns1.blazing.de
transmit(213.172.105.106)
receive(213.172.105.106)
transmit(217.144.138.234)
receive(217.144.138.234)
transmit(185.120.22.14)
receive(185.120.22.14)
transmit(136.243.66.91)
receive(136.243.66.91)
transmit(213.172.105.106)
receive(213.172.105.106)
transmit(217.144.138.234)
receive(217.144.138.234)
transmit(185.120.22.14)
receive(185.120.22.14)
transmit(136.243.66.91)
receive(136.243.66.91)
transmit(213.172.105.106)
receive(213.172.105.106)
transmit(217.144.138.234)
receive(217.144.138.234)
transmit(185.120.22.14)
receive(185.120.22.14)
transmit(136.243.66.91)
receive(136.243.66.91)
transmit(213.172.105.106)
receive(213.172.105.106)
transmit(217.144.138.234)
receive(217.144.138.234)
transmit(185.120.22.14)
receive(185.120.22.14)
transmit(136.243.66.91)
receive(136.243.66.91)

server 213.172.105.106, port 123
stratum 2, precision -20, leap 00, trust 000
refid [213.172.96.14], root delay 0.000351, root dispersion 0.000183
transmitted 4, in filter 4
reference time:    e4ac8777.f0ffc7a5  Thu, Jul 29 2021  3:48:39.941
originate timestamp: e4ac87a4.ceff8897  Thu, Jul 29 2021  3:49:24.808
transmit timestamp:  e4ac87a6.163b49c7  Thu, Jul 29 2021  3:49:26.086
filter delay:  0.05145  0.05064  0.05032  0.05026
         0.00000  0.00000  0.00000  0.00000
filter offset: -1.29039 -1.29048 -1.29036 -1.29064
         0.000000 0.000000 0.000000 0.000000
delay 0.05026, dispersion 0.00020
offset -1.290640

server 217.144.138.234, port 123
stratum 2, precision -18, leap 00, trust 000
refid [26.91.187.18], root delay 0.015701, root dispersion 0.022079
transmitted 4, in filter 4
reference time:    e4ac8613.e9786818  Thu, Jul 29 2021  3:42:43.911
originate timestamp: e4ac87a5.028c3053  Thu, Jul 29 2021  3:49:25.009
transmit timestamp:  e4ac87a6.496ea449  Thu, Jul 29 2021  3:49:26.286
filter delay:  0.05415  0.05365  0.05389  0.05379
         0.00000  0.00000  0.00000  0.00000
filter offset: -1.29105 -1.29096 -1.29068 -1.29108
         0.000000 0.000000 0.000000 0.000000
delay 0.05365, dispersion 0.00012
offset -1.290967

server 185.120.22.14, port 123
stratum 2, precision -25, leap 00, trust 000
refid [131.188.3.221], root delay 0.003952, root dispersion 0.001129
transmitted 4, in filter 4
reference time:    e4ac8779.ef297fc9  Thu, Jul 29 2021  3:48:41.934
originate timestamp: e4ac87a5.35d14eb0  Thu, Jul 29 2021  3:49:25.210
transmit timestamp:  e4ac87a6.7c9df6e5  Thu, Jul 29 2021  3:49:26.486
filter delay:  0.05252  0.05127  0.05148  0.05136
         0.00000  0.00000  0.00000  0.00000
filter offset: -1.28956 -1.28937 -1.28964 -1.28950
         0.000000 0.000000 0.000000 0.000000
delay 0.05127, dispersion 0.00014
offset -1.289373

server 136.243.66.91, port 123
stratum 2, precision -24, leap 00, trust 000
refid [178.189.127.147], root delay 0.016251, root dispersion 0.027786
transmitted 4, in filter 4
reference time:    e4ac84c1.3bbb619e  Thu, Jul 29 2021  3:37:05.233
originate timestamp: e4ac87a5.694e44d5  Thu, Jul 29 2021  3:49:25.411
transmit timestamp:  e4ac87a6.afd2ae70  Thu, Jul 29 2021  3:49:26.686
filter delay:  0.05286  0.05257  0.05267  0.05238
         0.00000  0.00000  0.00000  0.00000
filter offset: -1.28890 -1.28866 -1.28893 -1.28885
         0.000000 0.000000 0.000000 0.000000
delay 0.05238, dispersion 0.00011
offset -1.288854

29 Jul 03:49:26 ntpdate[505]: step time server 213.172.105.106 offset -1.290640 sec


Das erklärt auch warum das mit der anderen Sense funktioniert, die verwendet ebenfalls als standard Gateway nur eine der DSL Leitungen... aber seit wann blocken die das im Rechenzentrum und warum, hat doch bisher immer funktoniert?

Wie kann ich nun NTP per FW Rule auf einen der anderen GW's umleiten, wenn mir da noch jemand behilflich sein könnte^^ würde gerne die Zeitauflösung über meine Primäre Sense für das interne LAN zur Verfügung stellen? :)

Hallo,

heute ist mir aufgefallen, dass NTP nicht mehr synchronisiert, hatte gehofft mit dem Update auf 21.7 behebt  sich das Problem von alleine.

Einige Versuche, das Problem einzugrenzen:

root@opnsense:~ # ntpd -q -g
28 Jul 23:11:44 ntpd[41978]: ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
28 Jul 23:11:44 ntpd[41978]: Command line: ntpd -q -g
28 Jul 23:11:44 ntpd[41978]: ----------------------------------------------------
28 Jul 23:11:44 ntpd[41978]: ntp-4 is maintained by Network Time Foundation,
28 Jul 23:11:44 ntpd[41978]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
28 Jul 23:11:44 ntpd[41978]: corporation.  Support and training for ntp-4 are
28 Jul 23:11:44 ntpd[41978]: available at https://www.nwtime.org/support
28 Jul 23:11:44 ntpd[41978]: ----------------------------------------------------
28 Jul 23:11:44 ntpd[41978]: proto: precision = 0.420 usec (-21)
28 Jul 23:11:44 ntpd[41978]: getconfig: Couldn't open </etc/ntp.conf>: No such file or directory
28 Jul 23:11:44 ntpd[41978]: unable to bind to wildcard address :: - another process may be running - EXITING


root@opnsense:~ # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
time.cloudflare .INIT.          16 u    -   64    0    0.000   +0.000   0.000
a08.alphasrv.ne .INIT.          16 u    -   64    0    0.000   +0.000   0.000
ntp2.m-online.n .INIT.          16 u    -   64    0    0.000   +0.000   0.000
5.145.135.89 (s .INIT.          16 u    -   64    0    0.000   +0.000   0.000
ptbtime1.ptb.de .INIT.          16 u    -   64    0    0.000   +0.000   0.000
ptbtime2.ptb.de .INIT.          16 u    -   64    0    0.000   +0.000   0.000
ptbtime3.ptb.de .INIT.          16 u    -   64    0    0.000   +0.000   0.000
lucy.thehomeofa .INIT.          16 u    -   64    0    0.000   +0.000   0.000
clock2.infonet. .INIT.          16 u    -   64    0    0.000   +0.000   0.000
where-you.at    .INIT.          16 u    -   64    0    0.000   +0.000   0.000


root@opnsense:~ # ntptime
ntp_gettime() returns code 5 (ERROR)
  time e4ac4b00.de4dd000  Wed, Jul 28 2021 23:30:40.868, (.778868375),
  maximum error 16640000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 41.639 ppm, interval 4 s,
  maximum error 16640000 us, estimated error 16000000 us,
  status 0x41 (PLL,UNSYNC),
  time constant 3, precision 0.000 us, tolerance 496 ppm,
  pps frequency 41.639 ppm, stability 0.000 ppm, jitter 0.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.


Warum synchronisiert NTP nicht mehr, was kann ich tun?

Was ich ebenfalls probiert hatte war, den Dienst neu zu installieren, leider hat dies auch nichts gebracht. Laut Firewallprotokoll, sind die NTP Server über den Port 123 erreichbar.

Allerdings verstehe ich nachfolgend nicht, warum NTP keine Daten bekommt?

root@opnsense:~ # ntpdate -d 0.opnsense.pool.ntp.org
29 Jul 00:22:05 ntpdate[91089]: ntpdate 4.2.8p15@1.3728-o Thu Jul 22 12:42:45 UTC 2021 (1)
transmit(144.76.76.107)
transmit(162.159.200.123)
transmit(194.36.144.87)
transmit(185.242.112.53)
transmit(144.76.76.107)
transmit(162.159.200.123)
transmit(194.36.144.87)
transmit(185.242.112.53)
transmit(144.76.76.107)
transmit(162.159.200.123)
transmit(194.36.144.87)
transmit(185.242.112.53)
transmit(144.76.76.107)
transmit(162.159.200.123)
transmit(194.36.144.87)
transmit(185.242.112.53)
144.76.76.107: Server dropped: no data
162.159.200.123: Server dropped: no data
194.36.144.87: Server dropped: no data
185.242.112.53: Server dropped: no data

29 Jul 00:22:14 ntpdate[91089]: no server suitable for synchronization found


Anmerkung: NTP kann über 0.opnsense.pool.ntp.org von einer andere Sense problemlos synchronisiert werden.

Hallo,

das Upgrade auf Version 21.7 lief bei mir mit meiner Konfiguration reibungslos durch.
Es scheint auf den ersten Blick alles sauber zu laufen.

Besten Dank allen, die daran mitgearbeitet haben, das macht Spaß  :)

Top, lief bei mir auch ohne Probleme so weit durch.

Hallo.

Ich verwende privat TP-Link OMADA Serie. Aktuell gibt es dirt noch keinen Cloud Zwang.

Fg

Top, den schau ich mal an, danke!

Bin ebenfalls auf der Suche nach einem AP, Unifi wird immer wieder empfohlen, unserer ist nun 7 Jahre alt und stürzt regelmäßig ab. Eigentlich lief er zufriedenstellend, nur frage ich mich, gibt es keine adequate Alternative zu Unifi? Da muss es doch noch andere Hersteller geben oder soll ich wieder zu unfi greifen?

evtl. schaffe ich es diesesmal auch

Abend,

mal eine Frage, weil das denke ich hier evtl. gut rein passt, habt ihr euch mittlerweile noch mal mit DoH beschäftigt und eine Möglichkeit gefunden? Ich weiß, ist ein leidiges Thema, dennoch würde es mich interessieren wie man dabei vorgeht oder das konkret realisiert, Sensei und SSL Bump wären ja soweit ich gelesen habe, prädestiniert für ein solches Vorhaben?

Schade eigentlich, das DoH hier nicht mal ausführlicher Diskutiert wird.

Der Traffic scheint über die Sense zu gehen, siehe Paketaufzeichnung, aber was passiert dort genau, ein einfacher FW Eintrag mit "block ip any * *" usw. hatte auch nicht das gewünschte Ergebnis gebracht, also warum kann der AP über die Sense mit dem Pi-Hole kommunizieren?



Netzwerkplan:


WAN / Internet
            :
            :
            :
      .-----+-----. 
      |  Gateway|  (Fritzbox)
      '-----+-----'
            |
         DMZ   192.168.1.0/24
            |
         Pi-Hole 192.168.1.8
            |
      .-----+------.   192.168.1.1
      |  OPNsense
      '-----+------'  192.168.0.12
            |
        LAN | 192.168.0.0/24
            |
        AP 192.168.0.154


Keine Vlans, ist geplant aber entsprechende Hardware muss noch angeschafft werden.

Hi,

eigentlich sollen nur zwei Hosts mittels Aliase geblockt werden aber irgendwie bekomme ich auf meinem Pi-Hole immer noch DNS abfragen vom AP.

Lange rede kurzer Sinn, so weit die Konfiguration, siehe Bilder:


[Edit]

Das Problem hat sich nach einem Neustart der Sense von alleine gelöst.