s21it21

hallo, schau dir das mal an, dorts stehts ganz genau: http://www.cisco.com/warp/public/707/ipsecnat.html lg martin

hello, mache statt dem pat mal einen static. beim static ist der datenverkehr in beide richtungen offen. das funktioniert wunderbar (habs selbst schon oft mit dem checkpoint-secureclient so gemacht). lg martin

Hallo, Sorry für die späte Anwort. Damit von Aussen irgendwer/irgend eine Applikation auf einen Client bei Dir im internen LAN zugreifen will brauchst du so etwas: static damit die translation in beide richtungen funktioniert (übersetzung externe ip auf die interne ip) static (inside, outside) <externe ip> <interne ip> --> das heisst der zugriff vom outside interface aus dem internet auf die <externe ip> wird über das inside interface auf die <interne ip> umgesetzt. dann brauchst du noch eine eigentliche zugriffsregel (access-list): access-list 101 permit tcp any host <externe ip> eq port diese access-list musst du aufs externe interface binden, in diesem fall: access-group 101 in interface outside alles klar? Dabei ist es aber nur möglich, dass man vom internet auf GENAU EINEN Client von Aussen zugreifen darf. Anders geht das gar nicht. lg martin

hallo, eibe gute quelle für zahlreiche docs ist einfach http://www.cisco.com oder zb: http://www.secwiz.com/ lg martin

hallo, ok das heisst vom internet wird auf das interne lan zugegriffen. dafür brauchst du eine public ip-adresse für deinen internen client. mit dem static machst du die übersetzung von der exteren ip auf die interne ip. mit der access-list schaltest du diese externe ip auf dem outside interface für die ports frei. so wie deine statics aussehen gehs nicht. du brauchst das so: static (inside,outside), interne ip, externe ip etc. lg martin

Hallo! Erst mal musst die die Portnummern wissen (tcp/upd, port xxx). Dann würde ich auch gerne wissen, ob es darum geht, dass die internen Clients auf einen Dienst im Internet zugreifen wollen, oder ob Ihr diesen Dienst anbietet und User aus dem Internet zugreifen. Gehts um ersteres: ich habe gesehen, dass du eine access-list am outside interface gebunden hast. das ist falsch. bei der pix schaltest du die access-list auf dem interface frei, wo der traffic zu erst ankommt, also in diesem fall am internen interface. weiters ist es wichtig, dass du irgendein nat für das interne netz hast (static, pat, etc.). wenn du am internen interface keine access-list hast, sondern nur für das interne lan ein nat, dann kann der gesamte traffic raus. das ist eine eigenart der pix. vom inside interface in jedes andere, kann grundsätzlich (wenn es ein nat gibt) alles raus. bietet ihr diesen dienst an, dann brauchst du einen static-eintrag der die externe ip-adresse auf eine interne umleitet. dann braucht man noch eine access-list mit den ports auf die die user aus dem internet zugreifen wollen. lg martin

Hallo, Ich denke dass das nicht möglich sein wird. Du kannst nur auf Grund von Routing-Tables Daten über verschiedene Interfaces rausschicken. Aber basiernd auf Ports geht das auf der Pix nicht (so viel ich weiss). Wäre es aber nicht sinnvoller das auf einem Router zu machen. Häng die Pix hinter einen Router der dann die zwei Internetleitungen hat. Und Dort kannst Du dann mit QoS die Aufteilung machen.... lg Martin

hallo, ja habe ich schon zu genüge gemacht. eine gute quelle ist: http://www.secwiz.com/ (im Menü oben Firewall --> PIX wählen). Zu beachten bei der PIX ist, dass diese ein NAT-Device ist und mit Prioritäten handelt. Das heißt das interne LAN hat die höchste Priorität (inside-interface). Das Internet (outside-interface) hat die niedrigste Priorität. Dazwischen kann man weitere Interfaces definieren und nach Prioritäten abstufen. Entsprechend dieser arbeitet die Kiste auch. Für JEDE Freischaltung (access-list) muss man irgendeine Art NAT (static, pat, etc.) definieren, sonst tut sich nichts. Zu beachten ist auch noch, dass die Pix grundsätzlich JEDEN Traffic von einer höheren in die niedrigere Priorität zulässt (so fern es ein NAT gibt). --> Dieses Verhalten finde ich pers. nicht sicher und sollte deaktiviert werden (mit einer access-list deny). Tut man dies, muss man, wie bei jeder guten Firewall, den gewünschten Traffic freischalten. ACHTUNG: Macht man bei der Pix ein debug packet all inside (oder outside), dann kann die Kiste abstürzen. Dabei wird das Gerät einfach überlastet (weil der GESAMTE Traffic gedebuggt wird). So long Martin PS: Man kann alternativ auch noch den PDM (grafisches GUI) verwenden, finde ich pers. aber für Müll.

Hallo! Hier die Syntax für Routen auf der PIX: route Enter a static route for the specified interface. (Configuration mode.) route inside|outside dest_net_ip netmask gateway_ip metric Syntax Description inside|outside Specifies the interface. dest_net_ip The destination network IP address. Use 0.0.0.0 to specify a default route. netmask Specifies a network mask to apply to dest_net_ip. Use 0.0.0.0 to specify a default route. gateway_ip Specifies the IP address of the gateway router (the next hop address for this route). metric Specifies the number of hops to dest_net_ip. If you are not sure, enter 1. Your network administrator can supply this information or you can use a traceroute command to obtain the number of hops (such as the traceroute command provided with Cisco TCP/IP Suite 100 for Windows). Ich würde es so machen: Wenn Du Dich via ISDN einwählst, sollte Dein Client eine eigne IP-Adresse aus einem eigens dafür definierten Bereich bekommen. Diesen IP-Bereich kannst Du dann wie Du willst routen. So weit ich weiss, ist es aber auf der PIX ein Problem, wenn Traffic über ein internes interface daherkommt, dass über eine Route dieser Traffic dann auch wieder über DAS SELBE Interface drüber geht. Also, wenn dem so ist, hänge den ISDN-Router auf ein eigenen Interface auf der PIX und route das eben dort hinaus. ODER DU hängst zwischen Clients und PIX einen Router. Dieser ist das defGW für ALLE Clients. Der Router routet prinzipiell alles zur Firewall weiter. Der Unterschied ist aber, dass Du dann auf diesem Router den Traffic zum ISDN-Router umbiegen kannst. Andere aufwendige Arbeit ist, dass Du auf den Servern eine Route für das ISDN-Netz in Richtung ISDN-Router einträgst . Dies muss dann aber auf jedem Client/Server eingetragen werden. Das heißt die Dinger haben ein defGW und eben die eine Route für das ISDN-Netz. lg Martin

hello, prinzipiell würde ich mir auch die frage stellen, warum das vpn-gateway eine direkte verbindung ins lan hat. ich würde das auch über die firewall routen. somit gibt es absolut keine verbindung ins lan. ich würde auch zu einer checkpoint auf einer nokia-box empfehlen. günstiger wirds auf einer secureguard-plattform... lg martin

hallo, mit folgenden befehlen kannst du dir die snmp-konfig ansehen: show snmp-server weiter hier die infos für eine neue snmp-konfig: snmp-server contact|location text snmp-server host ip_address wenn du die logs haben willst, wäre aber ein syslog-server besser bzw. das generelle syslogging der pix. genaue infos hier: http://www.cisco.com/warp/public/110/pixsnmp.html und syslog: http://www.cisco.com/warp/public/110/pix_vpn_4094.html lg martin

hello, einfach auf den usernamen klicken... gerne, immer wieder. lg martin

hallo, achso ich habe das falsch verstanden. ich dachte ihr wollt die logdaten von der firewall und nicht von anderen systemen. :) :) :) sorry.... ich kenne nur syslsog-ng, da läuft auf einem server eben dieser dienst und man kann viele verschiedene systeme auf diesen server loggen lassen. der syslogng-server handelt das dann so, dass die systeme in eigene verzeichnisse loggen und man so eine bessere übersicht macht. jede nacht kann man dann ein logrotate einrichten, damit die einzelnen files nicht zu gross werden. so hat man zb. pro tag ein file, dort kann man dann leichter was finden.... für syslog muss man auf der firewall den port 514 freischalten (kann man aber am syslogserver ändern). weitere infos (aus dem internet): syslog-ng, as the name shows, is a syslogd replacement, but with new functionality for the new generation. The original syslogd allows messages only to be sorted based on priority/facility pairs; syslog-ng adds the possibility to filter based on message contents using regular expressions. The new configuration scheme is intuitive and powerful. Forwarding logs over TCP and remembering all forwarding hops makes it ideal for firewalled environments. weitere infos: http://www.selflinux.org/selflinux-devel/html/syslog-ng.html lg martin

hallo, wie gesagt, es kommt darauf an, was du mit den log-daten haben willst bzw. gibt es jemanden der zb. diverse scripts für auswertungen machen wird, etc. dienen die logs wirklich nur zum anschauen oder nur zum wegkopieren? wenn ihr vor einer entscheidung für ein firewallsystem seid, dann würde ich die logging möglichkeit aber nicht als oberste priorität sehen...aber das ist wahrscheinlich eine andere geschichte... bei syslog-dateien ist eben so, dass du alle logs, die das system schickt, in einem/mehrern files hast, ungefiltert, einfach komplett. alle auswertungen/anpassungen musst du dir selbst basteln (wenn es der syslogserver nicht anbietet)....ich habe bis jetzt eher die erfahrunge gemacht, dass man in solche syslog-files kaum reinschaut, weil es einfach zu viel ist.....bei der pix, zb. ist es so, dass man entweder zu wenig sieht, oder viel zu viel sieht (pers. meinung)...und die diversen abfragen muss man sich eben mit diversen grep/filter-befehlen selbst zusammenschnippseln.... lg martin

hello, guckst du dort: http://www.reintechnisch.de/Inhalt/computer/admin/syslog-ng.html http://www.campin.net/syslog-ng/faq.html interessant wäre noch was du mit den logdaten willst? in scripts für automatische auswertungen verwenden, oder nur zum nachschauen (bei bedarf)? bei checkpoint ist es eben so, dass die logs zentral abgelegt werden und mit einem gui kannst du dann schöne auswertungen/abfragen/visualisierungen machen, entweder in echtzeit oder rückwirkend... lg martin

hallo, syslog ist auf jeden fall eine lösung (besser ist syslog-ng, da hast du mehr möglichkeiten). es kommt eben drauf an welche firewall du einsetzen willst, bei linux-fws geht das sicher, bei checkpoint,soweit ich weiss, ncht wirklich (bzw. ist da der bedarf nicht so da, weil die logs sowieso zentral abgelegt werden). bei der cisco-pix gehts auch via syslog. lg martin

hallo, was willst du nun speichern? du willst alle log-daten zentral verwalten, richtig? lg martin

hallo, also wenn du eine checkpoint hast, dann werden sowieso alle log-einträge zentral auf einen management-server transportiert. du hast dort alle logeinträge zentralverwaltbar/auswertbar/einsehbar. wenn du checkpoint auf linux/unix laufen hast, dann geht auch syslog. ich weiss aber nicht genau welche meldungen die firewall via syslog rausschickt. snmp geht auch, aber da kleistert dich die checkpoint voll (würde ich darum nicht verwenden). in welchem format willst du denn die logs haben, oder gehts e nur um die reine zentrale verwaltung dieser? lg martin PS: bei checkpoint kannst mich gerne ausgiebig fragen!

hello, für einen "reinen" domain-controller brauchst du glaube ich das alles: dns-server file replicator service kerberos key dst center net logon nt lm service provider rpc locater windows time lg martin

hallo, stehen die zwei dcs im selben internen lan, oder werden da zwei standorte "verbunden", sind die zwei dcs durch eine firewall getrennt? für dns sollte auch upd-53 aber auch tcp-53 offen sein. für einen "reinen" domain-controller brauchst du glaube ich das alles: dns-server file replicator service kerberos key dst center net logon nt lm service provider rpc locater windows time lg martin

um welche firewall handelt es sich den? die syslogfunktion muss die firewall/betriebsystem schon untertützen. alternativ wäre theoretisch auch noch snmp möglich, wobei ich das auf einer firewall nicht aufdrehen würde. lg martin

hallo, ohne dir direkt helfen zu können, fällt mir als syslogserver für windows zb. nur der kiwi-syslogserver ein. vielleicht kannst du dann dabei auch was scripten. lg martin

hello, @evildave: was meinst du genau? wenn du eine vpn-verbindung aus dem internet auf die pix aufbaust, dann kommst du am outside-interface an, der tunnel wird aufgebaut und basierend auf den access-listen kannst du dann dich ins inside-interface (also ins interne lan) verbinden. dabei kannst du es so einrichten, dass der vpn-client zb. eine eigene ip-adresse von der pix bekommt (damit verhinderst du routing-probleme, falls das lan, aus dem der client kommt, den selben internen ip-range verwendet wie das zielnetz hinter der pix). wichtig ist eben, nachdem der tunnel steht (phase 1 und phase 2), dass du geeingente access-listen definiert hast (inkl. nonat-zeug). lg martin

Hallo! Ich habe neben dem Studium schon sehr viel gearbeitet (darum habe ich dieses auch abgebrochen :) ) und konnte darum viel Praxis sammeln. Genau diese Praxis hat mich "gerettet". Ich bin dan eben, klassisch, über die Microsoft-Schiene in die Branche weiter reingewachsen. ich hatte das glück, dass ich dan in einer grossen firma arbeiten konnte. dort habe ich sehr viele schulungen gemacht. danach wechselte ich in dieser firma in die security-abteilung und konnte ebenfalls viele schulungen/kurse besuchen (cisco pix, checkpoint, allgemeine security, linux). so war das bei mir... lg martin ps: mache den kurs, er ist sicher was wert und oft vergessen werden die neuen leute die man kennen lernt. so sind schon oft neue perspektiven entstanden (ich habe auf einem kur s schon mal zwei jobangebote bekommen)... VIEL GLÜCK!!!

wie gesagt, habs schon gelesen und meinen text entsprechend geändert. lg martin