Hi Henning, der hier war echt Klasse....
[...]. Mir geht's ja eher um die Sicherheit in Bezug auf Zugriffe von aussen die man ja bei Verwendung des tcpd wenigstens mittels >spawn< loggen kann.
Wie kann man *spam* mittels tcp wrapper loggen!? Wie kann man es besser tun, als mit den sendmail internen Mechanismen!?
Ursprünglich wollte ich ja (x)inetd verwenden da man ja dort sogar die Services an ein bestimmtes Interface binden kann.
Wie ich schon sagte: Was mich ärgert sind Leute die nicht einen Deut lesen.
Du ärgerst dich über Leute die nicht einen Deut lesen?! Gilt das auch für Leute die nicht einen Deut richtig lesen? SCNR ;-)) Die Rede war von spawn und nicht von spam! Ich könnt dich jetzt natürlich erstmal lesen lassen aber was soll's! Eine Hand wäscht die Andere! Eine Zeile der Art: in.telnetd : ALL : spawn (Text in Verbindung mir %a >> /irgendwo/hin/...) in der Datei hosts.deny über die der tcpd ja die Zugriffskontrolle steuert, loggt z.b die IP des Client's der versucht diesen Dienst in Anspruch zu nehmen. Kannste in der hosts.allow auch benutzen. Woher ich das weiß? Ich hab's in einem der drei aufgeschlagenen Büchern gelesen! ;-)
Er hat meine Mail nicht bekommen. Sie ging ausschließlich an Dich.
Up's.., stimmt jetzt wo du es sagst! Ist mir garnicht aufgefallen! Wieso eigentlich? Warum schreibst du nicht an die Liste? Ist doch viel effektiver. Viele lesen, viele schreiben = viele Info's! Bleibt doch ne Menge mehr hängen,oder?
Aber unter Verwendung von (x)inetd wäre man doch auf die Unterstützung von tcp-wrapper garnicht angewiesen, oder hab ich das falsch verstanden?
Die Funktionalität ist *nicht* identisch. Auf jeden Fall macht es Sinn, den tcp wrapper zu verwenden, weil man mit dem xinetd wieder _zwei_ Mechnismen hat, Zugriffe zu kontrollieren.
Hm.., wart mal! Ahh hab's schon! -----Schnipp---- Zitat: (Bemerkung: alles, was der Wrapper leistet, kann auch mit xinetd realisiert werden. Entscheidet man sich dennoch dafür, steigt die Zahl der Konfigurationsdateien unnötig an, die Administration wird aufwendiger... kurz: es ist nicht zu empfehlen). -----Schnapp--- Das ganze ist zu lesen unter www.linuxfocus.org in dem Artikel (x)inetd! Und jetzt wo ich es ein zweites mal *gelesen* ;-) hab, und vor allem nach deinem Hinweis in Bezug auf "libwrap" ist mir jetzt natürlich auch aufgefallen das dies unter "configure --with-libwrap" steht. Auf jedenfall weiß ich jetzt bescheid mit "libwrap" und dessen Bedeutung. Der Kreis hat sich sozusagen geschlossen! :-)
Es geht nur und ausschließlich um Dienste, "die über's Netz angesprochen werden"!
Ja.., sicher schon klar! Wollte nur sicher gehen! Hätte ja sein können das du denkst das ich hier sitzte und überlege wie ich am besten den apmd in meine inetd.conf übernehme. :-)) Ganz so schlimm ist es nun doch nicht mit meinen Linux Kenntnissen. Geschenkt! Missverständis!
Wo liegt der Unterschied zwischen einem Aufruf eines Binary einschließlich Optionen von der Konsole, einem Runlevel Skript oder per tcpd innerhalb der inetd.conf?
Nunja. Runlevel-Scripte werden während des boot-Vorgangs gestartet, was sich aber vom Start in einer interaktiven Shell.......................
Ebenfall's geschenkt, und Missverständis! Grundsätzliche Funktionsweise der Skripte und des inetd sind mir ebenfall's bekannt. Ich versuch's nochmal mit einer anderen Formulierung! Ausgangspunkt meiner Überlegung war folgendes. Du schriebst.....
Nicht alle möglichen Dienste _lassen_ sich per super daemon (sei es nun xinetd, inetd oder ein anderer) starten und bei vielen ist es absolut _nicht sinnvoll_.
Mir geht's um die ersten 1,5 Zeilen deines Arguments! Ich versuch's mal hiermit: Es müßten sich doch theoretisch alle Dienste, die nach der Inititialisierung des Netzwerkes durch die entsprechenden Runlevel Skripte, sowie nach dem Start des inetd, auf mindestens drei verschiedenen Wegen starten lassen. 1. von der Konsole ( natürlich erst nach der kompletten Systeminitialisierung) 2. durch ein Runlevel Skript ( natürlich nur während des Eintritts in das entsprechende Runlevel) 3. inetd ( der ja seit dem Start, lauscht!) Begründung: In allen drei Fällen erfolgt lediglich ein Programmaufruf mit eventuellen Optionen! Ich dachte da also eher an eine Anwort in der Richtung: Ja, theoretisch schon.....! Oder: Nein, das geht nicht, weil.....!
Na,ja eigentlich habe ich nur einen Mechanismus gesucht der mich über unauthorisierte Zugriffe über's ippp0 informiert. Ich dachte mir einfach das ich auf diesen Weg mittels tcpd sowie hosts.allow / hosts.deny das am einfachsten realisieren könnte. Das war's eigentlich schon!
Zum einen ist der tcp wrapper - im Vergleich zu einer statefull firewall wie iptables - eine Krüppellösung, zum anderen habe ich Dir bereits geschrieben, dass inzwischen viele - auch permenent laufenden - Dienste den tcp wrapper unterstützen. Das hat nicht die Bohne mit dem binary "tcpd" zu tun.
Puh, jetzt heißt's erstmal tief durchatmen! Wie war das nochmal mit dem lesen! Von einem Packetfilter war nie die Rede. Ich hab zwar schon ein paar Regeln in einer File zusammen gepuzzelt, darum gehts hier aber nicht. Ich bin gerade bei hosts.allow und hosts.deny und dem tcpd der diese File's für die Zugriffskontrolle nutzt über die sich auch mittels *spawn* und nicht *spam* Zugriffe loggen lassen. Und genau darum ging es mir in erster Linie. Also..!!, So meine Überlegung....!!, wäre es doch am *einfachsten* die Services die im Moment noch über Skripte aus dem RL Verzeichniss aufgerufen werden über die inetd.conf an den inetd zu binden und den tcpd diese Logging Aufgabe zu überlassen. BTW ---Schnipp--- Das klassische inetd dient der Steuerung und Überwachung von Netzwerkverbindungen eines Rechners. Trifft eine Anfrage auf einem Port ein, der von xinetd verwaltet wird, wird diese an ein Programm namens tcpd weitergeleitet. Dieses entscheidet auf Basis der Regeln in den Dateien hosts.allow und hosts.deny, ob die Anfrage zulässig ist. Ist dies der Fall, so wird der entsprechende Serverprozess , zum Beispiel ftpd, gestartet und die Anfrage bearbeitet. Dieser Mechanismus ist auch als tcp_wrapper bekannt. ---Schnapp--- Soviel zur Bohne! ;-) Also erstmal Danke für dein Hilfe, trotz einiger Missverständinisse konntest du mir ja Linux wieder ein Stück näher bringen. Bin über Ostern offline! Können danach ja wieder ein Schwätzchen halten. Gruß Fido