Jump to content

s21it21

Members
  • Gesamte Inhalte

    166
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von s21it21

  1. Hallo! Das Problem ist ganz einfach zu lösen: Drehe das fixup-Protokoll für Port 25 ab (no fixup protocol 25). Das Problem ist, dass der MS-Exchangeserver nicht so anwortet, wie es das fixup-Protokoll gerne hätte. lg Martin
  2. Hallo! Die Erklärung ist klar, das war ja auch nicht so wirklich die Frage. :) Es kommt trotzdem vor, dass nicht überall man das fixup deaktivieren muss... lg Martin
  3. hello, das sollte schon funktionierten. auf die mtu musst du aufpassen, damit sich das dann nicht hakt (beim checkpoint-vpn client habe ich das schon öfters gemacht)... lg martin
  4. Hello! Das FIXUP verstehst Du schon richtig. Es kommt auf die Exchange-Version an (nehme ich mal an). Auch ich hatte schon Fälle da gab es keine Probleme, dann wieder ging gar nix... So lange es funktioniert, denke nicht darüber nach... lg Martin
  5. hello, so viel ich weiss, ist es nicht optimal wenn du zb. 200 access-listen hast und überall das logging aktivierst...da hat die fw/router schon mehr zu tun... ich denke aber, dass bei sinnvoller nutzung dies zu vergessen ist... lg martin
  6. hallo, also wenn du bereit bist den preis für eine 501er zu zahlen, dann kauf dir diese und du wirst eine ruhe haben. die funktionen der firewall sind die selben wie in einer grossen 535er pix (die zb. grosse isp-provider einsetzen). darum liegst du mit einer 501er im sicheren bereich. beachten muss du, dass die pix über eine kommandozeile bedient wird. das gui ist zwar brauchbar, aber nicht optimal. wichtig ist auch noch, dass die pix501 den letzt aktuellen software stand (6.3(4)) aufweist. pix ios 7 (neuerste version) funktioniert auf dem ding nicht. willst du ein webgui haben und brauchst nicht alle funktionen einer pix, dann kauf dir irgendeinen router von netgear, etc. (die reichen für den privatgebrauch meist). wichtig dabei ist die NAT-Funktion (die clients werde vor dem internet versteckt) und ankommende nicht erlaubter traffic wird geblockt...ich hatte lange einen netgear wlanrouter 515er irgendwas)..das ding hat auch sehr gut funktioniert. aber wenn du dir eine pix501er kaufen willst, dann tu das. die hat sicher mit abstand die meisten funktionen und möglichkeiten.... lg martin
  7. hallo, was meinst du damit genau?? die 501er kann vpns aufbauen und parallel natürlich dazu traffic bearbeiten. wenn du eine klassische dmz aufziehen willst, dann brauchst du ein drittes interfaces, und das fehlt bei der 501er pix. aber wenn du einen server via https im internet verfügbar machen willst, dann funktioniert das natürlich.. bücher zur pix gibts bei amazon..kauf dir aber ein englisches, die deutschen sind alle schrott....also die bücher :) lg martin
  8. Hallo! Vielleicht haben wir aneinander vorbei gesprochen. Auf der PIX gibt es ja auch den Befehl "outbound" (hat man zusammen mit conduits verwendet). Aber ehrlich gesagt, verwirrt mich Dein Ansatz komplett. Du hast ja in Deinem ersten Post gesagt, dass man auf der PIX nicht alles mit ACLs regelt. Dem habe ich widersprochen, denn man regelt definitiv alles mit ACLs. Die Befehle "outbound" (und danach wurde ja gefragt) wird einfach nicht mehr verwendet (so wie auch die conduits). Wie willst Du denn auf der PIX sonst noch den Traffic kontrollieren?? Da gibt es NUR zwei Ansätze, die ACLs oder outbound/conduits (nicht mehr empfohlen!!!!), fertig. Mir Ist klar, dass beim FeatureSet man mit Inbound/Outbound immer am Interface sitzt. Der Ansatz geht bei der PIX nicht wirklich. An und für sich, spricht man aber bei der PIX schon von der Richtung des Traffics. Bei FeatureSet ist das sowieso alles komisch, da kann man ja auch mit der Quelle-Ziel-Angabe beim permit den Flow festlegen. Ich habe schon Access-listen gesehen, die als IN am Interface definiert waren, aber trotzdem wurde via permit source dest der Flow umgedreht...Und das hat alles funktioniert.... Ich wollte Dir nicht auf die Füsse treten...Aber wie gesagt, mit ACLs regelt man definitiv alles auf der PIX..Und das war die Kernaussage.... lg Martin PS: Viel Erfolg für Deine Prüfung...ich kenne die Prüfung...sie ist etwas eigenartig....
  9. Hallo Robert! Der Ansatz der PIX ist da etwas "anders": Man gibt auf jedes Interface EINE Access-Liste. Diese wird für das dahinterliegende Netz genutzt. Wenn also jetzt Traffic von Inside ins Internet will, dann greift NUR die Access-Liste am Inside-Interface. Wenn man nun Traffic aus dem Internet regeln will, macht man das mit einer Access-Liste die am Outside-Interface sitzt. Diese regelt den Traffic aus dem Internet (egal wo hin). In Summe sind das aber zwei Accesslisten, die eben den Traffic regeln. Alles klar? :) LG Martin
  10. Hallo! Also auf einer PIX machst Du die Zugriffskontrolle komplett mit ACLS!!!!! Dass ACLs nur den Inbound-Traffic regeln ist einfach FALSCH!!!!!!!! Man regelt natürlich den Traffic in beide Richtungen, man muss es nur konfigurieren. Outbound und conduits waren mal aktuell, werden aber heute kaum bis gar nicht mehr genutzt. Eine ACLS liegt immer am jeweiligen Interface an und regelt den Verkehr. Bei der PIX ist noch wichtig, dass man immer den Verkehr in irgendeiner Weise natten muss bzw. der PIX sagen muss, dass der Traffic nicht genattet werden muss. Dies macht man mit diversen Befehlen wie static, global, etc. lg Martin
  11. Hallo! Ja natürlich wird eine zweite IP an das Interface gebunden. Aber der Ansatz vom Befehl/Denkweise ist ein anderer. Ich wollte damit sagen, dass man, wie auch auf der Checkpoint das mit NATs, das eben auf der PIX mit statics löst/lösen sollte und nicht anders. LG Martin
  12. Hallo, Die CLI ist zwar mühselig, aber es bringt es wirklich. Das Problem am PDM ist auch noch, dass nicht alle Befehle der PIX unterstützt werden. Darum kommt man um die CLI nicht herum. lg Martin
  13. Hallo! Dein Problem ist ganz einfach gelöst. Es geht nicht darum, dass Du dem Interface mehrere IPs gibst, das ist nicht nötig bzw. unsinnig (selbst auf der Checkpoint. Nur weil das funktioniert, heisst das noch lange nicht, dass das der richtige Ansatz ist). Bei der Checkpoint löst man das mit static-NATs und proxy-arps. Auf der PIX macht man das eben mit statics. Wenn Du von Deinem Provider 10 IPs bekommen hast, dann geht das ganz einfach und genau so: Eine IP bekommt Deine PIX (also das Interface selbst das im Internet hängt). Die restlichen IPs wird Dein Provider sicher direkt zu Dir routen. So, nun musst Du die PIX dazu bewegen, dass sie auf weitere pupIPs reagiert (damit Du das dann intern auf die Webserver weiterleiten kannst). Und genau das macht eben der static Befehl. Der static-Befehl bewirkt, dass sich die PIX für die angegebenen pupIPs "meldet" (also arp-requests beantwortet) und dann den Datenverkehr weiterleitet (wenn es auch einen Access-list gibt). Wenn Du jetzt drei Interfaces hast (Internet-outside, DMZ, locallan) und Deine Webserver stehen in der DMZ, dann geht das so: static (dmz,outside) pupIP dmzIP Schau Dir die Syntax vom Static-Befehl an, dann ist Dir das klar. Mit der Access-liste am Outside-Interface schaltest Du dann den Traffic wirklich frei. Mit dem static-Befehl könntest DU dann auch noch Portumleitungen realisieren (also wenn DU nur eine pupIP hast aber trotzdem mehrer Server). Wie gesagt, alle anderen Lösungen mögen zwar funktionieren sind aber aus Security-Sicht unsauber und nicht üblich. lg Martin
  14. Hallo! Mmm, es kommt eben immer darauf an was durch den Tunnel geht. Es kann reichen, oder auch nicht.... Vielleicht kannst Du es austesten, in dem Du testweise ein paar Tunnel mal deaktivierst. LG Martin
  15. Hallo! Um welche PIX handelt es sich denn genau (501, 515, etc)? VPNs sind ja recht CPUlastig, wenn es eine kleine PIX ist, kann es schon zu Problemen kommen (weil einfach die Power fehlt). LG Martin
  16. Hallo, ALso wenn Du einen Server, der in Deinem LAN steht im Internet erreichbar machen willst, dann ist Dein Ansatz völlig falsch!!!! Dies realisierst Du mit einem Static-EIntrag und einer Access-List. Der Static macht die Verbindung pupIP und privater IP vom Webserver, die Access-liste, die am externen Interface anliegt, macht dann die pupIP des Webservers erreichbar. static (dmz,outside) pupIP privIP netmask 255.255.255.255 oder eben static (inside,outside) pupIP, privIP netmask 255.255.255.255 dann eine access-liste am outside interface machen, und fertig.... lg martin
  17. Hallo! Ob Du eine PIX 501 oder eine 535er PIX nimmst ist völlig egal, die Software an und für sich ist die selbe. Die PIX kommt mit VoIP (fixup) klar... lg martin
  18. hallo, du kannst beim static statt der ip-adresse das interface auch angeben. dann macht die pix den static eben mit dieser ip-adresse. ja, der pdm ist ein schrott.. nutze die cli und es wird alles funktionieren... lg martin
  19. Hallo! Ja natürlich gibt es einen Ansatz, wenn Du die Ziel-Ports/Ziel-IPs dafür kennst. So wie viele solche Programme ändern diese Dienste die IPs recht oft. Auf der PIX musst Du dann eben diese IPs nachziehen. Die PIX "versteht" den Traffic leider nicht, darum kannst Du das mit diesem Ansatz nicht sperren. Denkbar wäre, dass Du eben die Zieports generell sperrst (**** wird es wenn Du das auch auf Port 80,443, etc.) tunneln kannst (so wie icq zb.). Eine andere Lösung wäre, dass die Clients NUR mit einem Proxy ins Internet kommen, der Rest wird komplett gesperrt (das sollte generell so sein). So kannst Du verhindern, dass Clients "****es Zeug ausprobieren". LG Martin
  20. Hallo! Also ich würde eine PIX nicht als schlechte Firewall bezeichnen und jedem Firewall-Feastureset eines Routers vorziehen. Die PIX ist eine echte stateful Firewall die extrem viele gute Funktionen hat. Aus sicherheitstechnischer Sicht würde ich die Funktionen eines Routers und einer Firewall NIE mischen bzw. zusammenlegen! Und dass die PIX ppoe kann ist ja nichts schlechtes bzw., dass man mit dem Router firewalltechnisch mehr machen kann, halte ich für ein Gerücht!!! LG Martin
  21. hallo, modifiziere mal die mtu am client direkt, da dürfte sich damit was haken. lg martin
  22. genau, das image muss das firewall-feature-set beinhalten... lg martin
  23. s21it21

    Logging

    hallo, wenn du das zeug via syslog auf einen server schickst, kannst du dann einfach mit einem eigenen script das syslog-file auswerten und dann entsprechend reagieren..so mache ich es und das funktioniert sehr gut. lg martin
  24. hello, wenn du das zeug entpackst siehst du, dass man da ein script ausführen kann. schon mal auf die idee gekommen es einfach zu starten?? es ist so wie bei den meisten commandozeilen tools, ruft man diese ohne parameter auf, wird eine hilfe angezeigt...so ist es auch bei diesem tool. :) lg martin
  25. hallo, was willst du? willst du erreichen, dass user nur mehr über den proxy ins internet kommen? oder meinst du, dass man mit dem proxy auf die pix mit dem pdm kommt? ad 1) da machst du eine einfache access-liste die du am entsprechenden interface bindest. ad 2) du kannst genau festlegen welche ips via pdm auf die pix zugreifen dürfen. lg martin
×
×
  • Neu erstellen...