Beiträge von sandmann

VPN Firewall muss aktiviert sein, da ansonsten der Traffice geblockt wird.

Mal ne frage:
Bei mir läuft eine 3.0 mit dem SNORT Parameter "ac" seit ca. 3 Tagen. Keine Probleme, kein Cache Overflow, nichts.
Alles Problemlos. Nur einer der 4 Kerne steht seitdem permanent bei 100%.
2 GB RAM sind ca. 91% ausgelastet.

Ist bei der 3.0 der Parameter "ac" komplett wirkungslos?

Lt. Hotline (ich habe neben der Community noch eine Hardware UTM) sollte "ac" auch in der 3er funktionieren...

3.0 läuft seit 3 Tagen, keine Probleme. Transparenter Proxy lässt Traffic durch.

Super.
Wo steht die Information? Die habe ich irgendwie total überlesen.

Ich habe immer versucht, direkt vom Client per SSL auf 1und1 zu kommen...

Probier ich am Montag mal aus...

Bzgl. Tobit: Nicht wirklich eine Ahnung. Manche Programme haben ein Extra Feld für die Portauswahl, bei einigen heisst es mit :port erweitern. Z.B. "pop.server.xy:995" oder "123.456.789.012:995" (Möge man mir verzeihen, dass die angegebene IP V4 sinnfrei ist).

Habs gefunden. Bei der VMware Workstation ist in der jeweiligen .vmx der Wert
ethernet0.noPromisc = "true"
pro Netzwerkanschluss einzustellen.

Hat aber keine Veränderung gebracht.

Mittlerweile habe ich die Endian auf einer Hardware installiert.

Ergebnis:
Proxy aus und POP3 SSL funktioniert.
Mit Proxy funktioniert es nicht. Keine Fehlermeldung, nur Timeout. Im Logbuch steht nur
scan(28876)POP3S Connection from ---.----.----.---:-----
PROXIES:POP-PROXY:-TCP(br0)---.---.---.---:---- -> ---.---.---:995

Hat überhaupt jemand POP3 mit SSL am funktionieren?

Zitat

Gibt es keine Möglichkeit in der Endian zu sagen
mail.domianname.de wird auf 192.168.200.19 umgeleitet

mail.domainname.de -> endian -> 192.168.200.19

einfach antwort:
NÖ. Weil das hat nichts mit der Senderkennung in den Emailheadern zu tun.
Der DNS-MX Eintrag "mail.domainname.de" muss in den DNS Einstellungen des Internetproviders eingestellt werden. Nicht in der Firewall.
Ausserdem ist die Endian nicht dafür gedacht, einen Webserver nach aussen abzusichern. Daher DMZ = Datenweiterleitung ohne jeder Änderung.

Der EMAILSERVER erstellt den IP Eintrag im Header der Email und nicht irgendeine Firewall, UTM, etc.
Wie gesagt, bei Ipswitch nachfragen, wie das einzurichten ist.

Anbei ein Muster, wie die Zeile im Emailheader aussieht. Diese kommt vom EMAILSERVER.

Received: from domaenenname ([---.---.---.---]) by domaenenname with emailserver Empfaenger id nachrichtenid der email for
 Empfaenger; datum-uhrzeit

Alles rot markierte sind informationen vom Sender-Server und Empfänger-Server. Die IP ---.---.---.--- ist entweder von dem PC, wo der Emailserver installiert ist, oder von einem Internetprovider, der als Relais gilt.

Mal ne andere Frage: Ist die öffentliche IP auf eure Webseite registriert oder vom Internetprovider als feste Zugangs-IP eingerichtet und seit wann versendet Ihr Emails? Wie hat das vorher funktioniert? Wären hilfreiche Informationen, um Einstellungsfehler festzustellen...

Bei der Firewall anzufangen ist der falsche Ansatz.

Eigentlich akzeptiert die Endian nur IPs aus dem definierten Bereich. Die öffentliche IP auch intern verwenden kenne ich so von der Konfiguration her nicht.

Problem ist hier jedoch weniger die Rechner IP.

Lt. RFC ergänzt ein Server die Emailheader mit der eigenen IP als Sender IP. SPF beim Empfänger prüft diese nach und fragt nach einem entsprechenden MX Eintrag im DNS.

Ich würde mit dem Ipswith Kontakt aufnehmen und fragen, wie man die IP im Header auf die öffentliche IP einstellen kann und die lokale Server IP ausblenden kann.

Dann noch prüfen, ob ein DNS-MX Eintag die nötigen Einstellungen für SPF hat.

Man müsste halt ersteinmal herausfinden, wie man den IP Eintrag im Emailheader auf die öffentliche IP definiert...

...mach ich immer, bevor ich eine Endian auf Hardware installieren. Hat bisher auch geklappt.

Kann man das nur am ESX ändern oder auch auf der Workstation?

Hat nicht wirklich was gebracht.

Der Fehler FORWARD:DROP kommt jetzt noch zusätzlich.

Firewall wurde neu gestartet, VMware wurde auf andere Hardware kopiert...

Kann man das Verhalten BADTCP:DROP generell versuchsweise abschalten?

Ergänzung:
In der Endian gibt es folgende Meldung im Log
BADTCP:DROP TCP (br0) - Meldung kommt von "Firewall"

und? Braucht man zum ändern der Option in der Enterprise Endian?

Man mus ja nicht alles sagen...

Also, lt. Router wird eine SSL Verbindung aufgebaut, wenn der POP3 Proxy abgeschaltet ist.

Wir der POP3 Proxy eingeschaltet, erfolgt eine ausgehende Anfrage mit SSL, dann gibt es aber zwei Fehler, die sich abwechseln:
(a) Keine Antwort vom externen Emailserver
(b) Die Antwort vom externen Emailserver wird nicht von der Endian weitergeleitet. Der Router gibt die an die Endian weiter und dort bleibt es hängen.
Logbuch in der Endian zeigt nur die ausgehende Verbindung an, dann nichts mehr.

Der Emailclient bei uns im Büro meldet einen Timeout. Kein Zertifikatsfehler, nichts. Nur ein Timeout.

Irgendeine Ahnung, was es sein könnte?

Mit TLS habe ich es auch ausprobiert, dann geht auch keine Verbindung aus der Endian raus.

Habe ich schon gesehen. Da geht es aber darum, dass das Zertifikat nicht akzeptiert wird.
Ich habe das Problem, dass lt. Logbuch zwar eine ausgehende Verbindung kommt, jedoch der Server auf der Gegenseite keine Antwort sendet. Mit einer anderen Internetverbindung ohne Endian funktioniert es. D.h. der Notebook kann dann eine Verbindung aufbauen.

Mal sehen, was im Logbuch vom Router eingetragen ist.

Da ich experimentierfreudig bin:

Snort mit Parameter "ac" und 1GB RAM auf der 2.5.1 für eine 16Mbit Leitung reicht schon vollständig aus.
Jetzt ist nur die CPU der Flaschenhals.

Bei dem POP3 und SMTP Proxy habe ich das Problem, dass eine SSL Verbindung nicht aufgebaut werden kann.

Bei SMTP kann man SSL nicht einstellen - zumindest habe ich da nichts gefunden und bei POP3 wird kein Verbindungsaufbau nach 1und1 vorgenommen.

Ist der SSL Proxy noch nicht funktionsfähig, oder muss da irgendwo noch was zusätzlich eingestellt werden?

Danke im voraus.

Ich habe auch den Effekt.
Aber nur, wenn die Firewall ohne Neustart mehr wie 80 Tage läuft.
Gilt für die 2.52 Enterprise, 2.51 und 2.52 Community. 3.0 noch im Testen, daher keine Erfahrung.

Grenzwert:
Alles von Hand installiert, die Regeln aus der 2.5.2 per copy & paste in die 3.0 übernommen.

Noch keine Updates von Signaturen, etc. Dass kommt erst am Montag. Mal sehen, ob dann die 3.0 noch funktioniert.

Hier im Forum steht ein Link, wie man SNORT / IDS schneller macht, indem man den Parameter "lowmem" in "ac" ändert. Das ist auch in der 3.0 so eingestellt worden.

Ich habe efw-upgrade auf beiden Channels versucht und auf keinem ist ein Upgrade auf 3.0 möglich.

Kann es sein, dass es noch nicht von Endian auf den Updateserver geladen wurde?

Das mit dem Proxy habe ich auch, jedoch auch eine wahrscheinliche Lösung und Methodik:

Endian starten und direkt auf die Webseite gehen (d.h. nachdem lt. Konsole die nötigen Dienste gestartet wurden) = Proxy ist immer auf AUS und lässt sich nicht wirklich konfigurieren.

Endian starten und ca. 15-30 Min. warten und dann erst die Webseite der Endian aufrufen = Proxy ist auf AN und kann konfiguriert werden.

Kann jemand dieses Verhalten bei sich mit transpartem Proxy nachprüfen?

Mit Snort - Wieviel weniger und gilt das auf für die 3er Version???

Bringt Snort überhaupt soviel oder ist das eher Vorteilsfrei???

@fischer: Welche Alternative zur Endian ist eigentlich im Moment empfehlenswert?

Danke.