Daueronline mit SuSE 7.1
Hallo Liste, ich hab ein zur Zeit noch kleines problem, was sich mit regelmäßiger Widerholung allerdings wohl zu einem großen Problem entwickeln wird. Zu den Fakten: Meine ISDN-BVerbindung wird laut isdncrtl und YAST nach einer Minute Leerlauf getrennt. Gestern Vormittag war ich knapp eine Minute online, hab dann den Client auch wieder ausgemacht. Als ich heuet dann mal ins Logfile geschaut hab um zu überprüfen, wieviel von meinem Surftime-Paket schon weg sind kam der Schock: Der Router lief gestern glatt 5:50 Stunden (!). Wie kann sowas sein? Mein erster Verdacht war ja Nimda & CodeRed; aber im Apache-Log steht garnix (wohl weil die Kiddies mit dem IIS in der Schule waren). inetd ist auch deaktiviert, DynDNS war nicht aktiv. Kann es sein, daß ich durch zufälliges pingen online gehalten wurde? Oder gibts noch andere Verdachtsmomente? Bringt es überhaupt was, pings per Firewall komplett zu sperren oder gilt das trotzdem als Traffic und die Verbindung bleibt? | I= 569.98 kB O= 341.11 kB läßt eventuell Rückschlüsse zu; wie gesagt waren das eigentlich nur ein paar (maximal 3) Minuten Internet... Ach ja: wie mache ich das denn mit der Firewall am effektivsten? Ihc muß halt irgendwie die nächsten 6 Monate bis (eventuell) DSL da ist irgendwi eüberbrücken; doch mit tägich 6 Stunden für nix wirds teuer :-( TIA, Thomas -- ____ _ _ _____ _ _ __ ___ ICQ-UIN: 50296694 (_ _)( )_( )( _ )( \/ ) /__\ / __) )( ) _ ( )(_)( ) ( /(__)\ \__ \ (__) (_) (_)(_____)(_/\/\_)(__)(__)(___/ http://www.tentakelvilla.de
Hi Thomas und Liste, das Problem kenn ich nur zu gut. Ist bei T-DSL wohl noch um Klassen schlimmer. Hatte dazu auch schon eine kleine Diskussion auf der Liste. On Wed, 07 Nov 2001, Thomas Hog wrote: [..]
Als ich heuet dann mal ins Logfile geschaut hab um zu überprüfen, wieviel von meinem Surftime-Paket schon weg sind kam der Schock: Der Router lief gestern glatt 5:50 Stunden (!).
Bei mir waren es schon über 8 Stunden... :-(
Wie kann sowas sein? Mein erster Verdacht war ja Nimda & CodeRed; aber im Apache-Log steht garnix (wohl weil die Kiddies mit dem IIS in der Schule waren). inetd ist auch deaktiviert, DynDNS war nicht aktiv.
Nö, Nimda und CodeRed verursachen so etwas nicht. Die checken nur kurz ob es ein IIS ist und dann ist Ruhe.
Kann es sein, daß ich durch zufälliges pingen online gehalten wurde? Oder gibts noch andere Verdachtsmomente?
In den seltensten Fällen sind es Pings. Bei mir sind es hauptsächlich Peer-to-peer Tauschdienste! Durch die dynamische IP Vergabe rutscht man da irgendwie rein. :-( Auch scheint es bei diesen Diensten keine vernünftigen Timeouts zu geben. Das ist der Obermurx!
Bringt es überhaupt was, pings per Firewall komplett zu sperren oder gilt das trotzdem als Traffic und die Verbindung bleibt?
Der Firewall bringt in diesem Fall leider überhaupt nix! :-( Da liegt daran wie die eingehenden Daten im Linux verarbeitet werden. Mal stark vereinfacht: PPP-device -> Firewall -> Linux-Dienst Solange Traffic über das PPP-device läuft hält es die Verbindung offen! Der Firewall hält nur ungewollten Traffic von den "Linux-Diensten" fern. Um das Problem zu lösen müßte die Auswertung so erfolgen: PPP-device -(sämtlicher Traffic)-> Firewall -(gefilterter Traffic)-> ^ | | verbindung offen halten | ______________________________________________________________ Aber so etwas gibt es im Moment wohl nur für FreeBSD. [..]
Ach ja: wie mache ich das denn mit der Firewall am effektivsten? Ihc muß halt irgendwie die nächsten 6 Monate bis (eventuell) DSL da ist irgendwi eüberbrücken; doch mit tägich 6 Stunden für nix wirds teuer :-(
Ich hoffe bei T-DSL hast du gleich die Flatrate mitgeordert. Das löst zwar nicht das eigentliche Problem aber es ist dir dann egal. ;-) ciao Peter -- Live long and prosper!
On Thu, Nov 08, 2001 at 10:19:22AM +0100, Peter Mack wrote:
Der Firewall bringt in diesem Fall leider überhaupt nix! :-( Da liegt daran wie die eingehenden Daten im Linux verarbeitet werden. Mal stark vereinfacht:
PPP-device -> Firewall -> Linux-Dienst
Solange Traffic über das PPP-device läuft hält es die Verbindung offen! Der Firewall hält nur ungewollten Traffic von den "Linux-Diensten" fern.
Richtig.
Um das Problem zu lösen müßte die Auswertung so erfolgen:
PPP-device -(sämtlicher Traffic)-> Firewall -(gefilterter Traffic)-> ^ | | verbindung offen halten | ______________________________________________________________
Aber so etwas gibt es im Moment wohl nur für FreeBSD.
Andersrum gehts einfacher: PPP-device -(sämtlicher Traffic)-> Firewall -(gefilterter Traffic)-> ^ | | netfilter statistik | module | verbindung abbauen | ______________________________________________________________ Das sollte sich durchaus mit dem vorhandenen Framwork loesen lassen, leider kenn ich mich mit den netfilter internas nicht aus - ausserdem hab ich eh kaum Zeit uebrig, waer aber bestimmt ein nuetzliches feature. Man koennte das Modul sogar soweit ausbauen, das nur bestimmte pakete/dienste im statistic module die counter steuern bzw. nicht steuern. -- Karsten Keil SuSE Labs ISDN development
Hi Karsten! On Thu, 08 Nov 2001, Karsten Keil wrote:
Andersrum gehts einfacher:
PPP-device -(sämtlicher Traffic)-> Firewall -(gefilterter Traffic)-> ^ | | netfilter statistik | module | verbindung abbauen | ______________________________________________________________
Das sollte sich durchaus mit dem vorhandenen Framwork loesen lassen, leider kenn ich mich mit den netfilter internas nicht aus - ausserdem hab ich eh kaum Zeit uebrig, waer aber bestimmt ein nuetzliches feature. Man koennte das Modul sogar soweit ausbauen, das nur bestimmte pakete/dienste im statistic module die counter steuern bzw. nicht steuern.
Hmm, klingt gut! Aber das netfilter module sagt mir im Moment leider nix. Hast Du gerade mal ein paar mehr Hinweise zur Hand (URL, RTFM, etc.). Dann brauche ich nicht lange suchen. Wenn nicht muß ich eben doch suchen. ;-) (Ja, ich bin faul und habe mindestens genausowenig Zeit wie Du!) Gruß Peter
Peter Mack am 8. November 2001:
Hmm, klingt gut! Aber das netfilter module sagt mir im Moment leider nix. Hast Du gerade mal ein paar mehr Hinweise zur Hand (URL, RTFM, etc.). Dann brauche ich nicht lange suchen. Wenn nicht muß ich eben doch suchen. ;-) (Ja, ich bin faul und habe mindestens genausowenig Zeit wie Du!)
Meine Lösung die ich seit knapp 5 Minuten praktiziere (nachdem ich heute grandiose 3 Minuten meine Win-Clients anhatte und der Router/Gateway 12:28 Stunden online war...): * ip-up.local: cp online tempfile * ip-down.local: cp offline tempfile cp offline zu_tun [online] isdnctrl hangup ippp0 [offline], [tempfile] [zu_tun] sind leer Per Cron wird dann alle 10 Minuten ein Skript aufgerufen, daß erst 'zu_tun' ausführt und dann 'tempfile' nach 'zu_tun' kopiert. Somit sollte ich nach meinen Kenntnsissen maximal 20 Minuten online sein. Es gibt garantiert elegantere Wege die vielleicht auch einfacher sind. Mit meinen Kenntnissen die immerhin zur Konfiguration mit YaST1 reichten (NIC, ISDN-Karte, Routing) ist das aber am logischsten gewesen => und es ist definitiv effektiv (wenns wirklich gehen sollte) *g* Gruß, Thomas PS: Kritik und Vorschläge zur Verbesserung nehm ich sehr gerne auf. -- "Wer sagt: Schulen ans Netz, der muss auch sagen: Schueler auf den Sportplatz oder in die Halle oder ins Schwimmbad. Das Klicken mit der Maustaste staerkt vielleicht die Muskulatur des rechten Zeigefingers, wird aber in absehbarar Zeit keine olympische Disziplin werden." [Bundespraesident J. Rau im kicker]
Hi, noch ein paar Bemerkungen. On Thu, Nov 08, 2001 at 10:19:22AM +0100, Peter Mack wrote:
Kann es sein, daß ich durch zufälliges pingen online gehalten wurde? Oder gibts noch andere Verdachtsmomente?
In den seltensten Fällen sind es Pings.
Bei mir sind es hauptsächlich Peer-to-peer Tauschdienste! Durch die dynamische IP Vergabe rutscht man da irgendwie rein. :-( Auch scheint es bei diesen Diensten keine vernünftigen Timeouts zu geben. Das ist der Obermurx!
Nein, das ist meistens richtig, das Problem sind die dynamischen IPs, das ist der Murks, laest sich aber nicht aendern. Meistens ist es eine falsch konfigurierte firewall, wenn man laenger mit solchen Diensten, die der "Vorbesitzer" der IP benutzt hat, bombardiert wird. Meistens wird hier einfach dichtgemacht mit DENY, dadurch bekommt die Gegenstelle nie mit, das hier ein Dienst ins Leere laeuft, wenn dieser Dienst ein reiner push ohne quittierung ist, timed er nunmal nicht aus. Deshalb sollten derartige Dienste mit REJECT zuruekgewiesen werden, dann hoert der Spuk ziemlich schnell auf. -- Karsten Keil SuSE Labs ISDN development
Hi Karsten! On Fri, 09 Nov 2001, Karsten Keil wrote: [..]
Meistens ist es eine falsch konfigurierte firewall, wenn man laenger mit solchen Diensten, die der "Vorbesitzer" der IP benutzt hat, bombardiert wird. Meistens wird hier einfach dichtgemacht mit DENY, dadurch bekommt die Gegenstelle nie mit, das hier ein Dienst ins Leere laeuft, wenn dieser
So hatte ich meine Firewall zu Anfang konfiguriert. Auf deinen Tip hin habe ich das vor ein paar Wochen geändert.
Dienst ein reiner push ohne quittierung ist, timed er nunmal nicht aus. Deshalb sollten derartige Dienste mit REJECT zuruekgewiesen werden, dann hoert der Spuk ziemlich schnell auf.
Leider muß ich hier widersprechen! Meine Firewall antwortet auf die meisten (Peer-to-Peer) Dienste mit einem REJECT. Doch das hilft leider nur wenig. Manchmal bleibt die Verbindung trotzdem Stundenlang offen. ciao Peter
On Fri, Nov 09, 2001 at 12:22:46PM +0100, Peter Mack wrote:
Hi Karsten!
On Fri, 09 Nov 2001, Karsten Keil wrote:
[..]
Meistens ist es eine falsch konfigurierte firewall, wenn man laenger mit solchen Diensten, die der "Vorbesitzer" der IP benutzt hat, bombardiert wird. Meistens wird hier einfach dichtgemacht mit DENY, dadurch bekommt die Gegenstelle nie mit, das hier ein Dienst ins Leere laeuft, wenn dieser
So hatte ich meine Firewall zu Anfang konfiguriert. Auf deinen Tip hin habe ich das vor ein paar Wochen geändert.
Dienst ein reiner push ohne quittierung ist, timed er nunmal nicht aus. Deshalb sollten derartige Dienste mit REJECT zuruekgewiesen werden, dann hoert der Spuk ziemlich schnell auf.
Leider muß ich hier widersprechen! Meine Firewall antwortet auf die meisten (Peer-to-Peer) Dienste mit einem REJECT. Doch das hilft leider nur wenig. Manchmal bleibt die Verbindung trotzdem Stundenlang offen.
Auf Grund von Paketen auf diesen Ports ? Hmm, das kann unter anderem daran liegen, das eine Firewall auf der anderen Seite falsch konfiguriert ist und ICMP blocked, dann bekommt der eigentlich Sender das REJECT nicht mit. Naja eventuell bekomme ich demnaechst TDSL+flat, dann werde ich mir das mal genauer anschauen. -- Karsten Keil SuSE Labs ISDN development
Karsten Keil wrote:
On Fri, Nov 09, 2001 at 12:22:46PM +0100, Peter Mack wrote:
Naja eventuell bekomme ich demnaechst TDSL+flat, dann werde ich mir das mal genauer anschauen.
Mein TDSL fluted mich mit Braoadcasts auf meinen Port 67. Da kommen so ca 10-20 Pakete pro Minute rein. Was spricht eigentlich gegen die Aktivierung des PPP_FILTER im pppd ? Dann könnte man mittels active-filter bzw pass-filter schon im pppd die nervigen Hits auf 67, 80, 1214, 6680 usw abblocken und der idle-Mechanismus des pppd könnte den Rechner wunschgemäß aus dem Netz nehmen, wenn er auf meiner Seite unbenutzt ist. Das wäre doch eine feine Sache. Offenbar kämpfen doch etliche Leutchen mit dem Problem. Nun sogar noch mehr, nachdem die ISDN-Flat flatgefallen ist. Ich habe schon versucht den pppd aufzubohren, bin aber gescheitert. Bei SuSEs pppd 2.4.1 spm kriege ich nicht alle Teile gebaut, die im SuSE binaty rpm drin sind und dadurch scheitert der Start des pppd. Bei den Quellen von Michal Ostrowskis pppd 2.4.1 wird zwar u.a. auch pppoe.so gebaut, aber SuSEs ppp Konfiguration weicht von der dort beschriebenen ab. SuSE benutzt zB ein Zusatzmodul, um die Benutzerdaten zu übergeben. In SuSEs default-Kernel 2.4.7 scheint der ppp-filter ja zumindest einkompiliert zu sein. Zumindest entnehme ich dies der /boot/vmlinuz.config. SuSE 7.2 Kernel 2.4.7 (Binary rpm von SuSE) pppd 2.4.1 (Binary rpm von SuSE 7.3) SuSEfirewall2 2.1 Gruß Andreas
On Wed, Dec 12, 2001 at 12:42:29AM +0100, Andreas Fiesser wrote:
Karsten Keil wrote:
On Fri, Nov 09, 2001 at 12:22:46PM +0100, Peter Mack wrote:
Naja eventuell bekomme ich demnaechst TDSL+flat, dann werde ich mir das mal genauer anschauen.
Mein TDSL fluted mich mit Braoadcasts auf meinen Port 67. Da kommen so ca 10-20 Pakete pro Minute rein.
Was spricht eigentlich gegen die Aktivierung des PPP_FILTER im pppd ? Dann könnte man mittels active-filter bzw pass-filter schon im pppd die nervigen Hits auf 67, 80, 1214, 6680 usw abblocken und der idle-Mechanismus des pppd könnte den Rechner wunschgemäß aus dem Netz nehmen, wenn er auf meiner Seite unbenutzt ist. Das wäre doch eine feine Sache. Offenbar kämpfen doch etliche Leutchen mit dem Problem. Nun sogar noch mehr, nachdem die ISDN-Flat flatgefallen ist.
Ich habe schon versucht den pppd aufzubohren, bin aber gescheitert. Bei SuSEs pppd 2.4.1 spm kriege ich nicht alle Teile gebaut, die im SuSE binaty rpm drin sind und dadurch scheitert der Start des pppd.
??? Das ist nicht moeglich, mit rpm -ba /usr/src/packages/SPECS/pppd.spec wird, wenn alle notwendigen (#needforbuild/#usedforbuild im spec) Pakete installiert sind, exakt das gleiche rpm gebaut (gleiche versionen vorausgesetzt). -- Karsten Keil SuSE Labs ISDN development
Andreas Fiesser schrieb:
Was spricht eigentlich gegen die Aktivierung des PPP_FILTER im pppd ?
"man pppd" (pppd 2.4.1) behauptet: This option is currently only available under NetBSD, and then only if both the kernel and pppd were compiled with PPP_FILTER defined.
Dann könnte man mittels active-filter bzw pass-filter schon im pppd die nervigen Hits auf 67, 80, 1214, 6680 usw abblocken und der idle-Mechanismus des pppd könnte den Rechner wunschgemäß aus dem Netz nehmen, wenn er auf meiner Seite unbenutzt ist. Das wäre doch eine feine Sache.
Wie wahr. FreeBSDs "ppp" (nicht "pppd") hat extra Filtereinstellungen für Pakete, die die Rauswahl (nicht) triggern sollen und für Pakete, die die Leitung (nicht) offen halten sollen.
In SuSEs default-Kernel 2.4.7 scheint der ppp-filter ja zumindest einkompiliert zu sein. Zumindest entnehme ich dies der /boot/vmlinuz.config.
Interessant - wie heisst die Option und kann man rausfinden, woher die Patches kommen? Viele Grüsse... Michael
Michael Mauch wrote:
Was spricht eigentlich gegen die Aktivierung des PPP_FILTER im pppd "man pppd" (pppd 2.4.1) behauptet:
This option is currently only available under NetBSD, and then only if both the kernel and pppd were compiled with PPP_FILTER defined.
Ja, hab ich gelesen. Der pppd kanns doch also offenbar. Demnach läge es am Linux-Kernel, wenn das nicht ginge. Wie wahrscheinlich ist es, das die man-page 100% aktuell ist ?
Wie wahr. FreeBSDs "ppp" (nicht "pppd") hat extra Filtereinstellungen für Pakete, die die Rauswahl (nicht) triggern sollen und für Pakete, die die Leitung (nicht) offen halten sollen.
Das sind die.
In SuSEs default-Kernel 2.4.7 scheint der ppp-filter ja zumindest einkompiliert zu sein. Zumindest entnehme ich dies der /boot/vmlinuz.config. Interessant - wie heisst die Option und kann man rausfinden
FEBRUAR:~ # grep PPP /boot/vmlinuz.config CONFIG_PPP=m [...] CONFIG_PPP_FILTER=y [...]
, woher die Patches kommen?
Frag mich nicht ... Gruß Andreas
On Fri, Dec 14, 2001 at 03:59:06PM +0100, Andreas Fiesser wrote:
Michael Mauch wrote:
Was spricht eigentlich gegen die Aktivierung des PPP_FILTER im pppd "man pppd" (pppd 2.4.1) behauptet:
This option is currently only available under NetBSD, and then only if both the kernel and pppd were compiled with PPP_FILTER defined.
Ja, hab ich gelesen. Der pppd kanns doch also offenbar. Demnach läge es am Linux-Kernel, wenn das nicht ginge.
Der 2.4 kernel kann es (seit wann weiss ich ohne Suche nicht).
Wie wahrscheinlich ist es, das die man-page 100% aktuell ist ?
Wie wahr. FreeBSDs "ppp" (nicht "pppd") hat extra Filtereinstellungen für Pakete, die die Rauswahl (nicht) triggern sollen und für Pakete, die die Leitung (nicht) offen halten sollen.
Das sind die.
In SuSEs default-Kernel 2.4.7 scheint der ppp-filter ja zumindest einkompiliert zu sein. Zumindest entnehme ich dies der /boot/vmlinuz.config. Interessant - wie heisst die Option und kann man rausfinden
FEBRUAR:~ # grep PPP /boot/vmlinuz.config CONFIG_PPP=m [...] CONFIG_PPP_FILTER=y [...]
, woher die Patches kommen?
Frag mich nicht ...
Keine Patches, sondern Bestandteil des 2.4.7 orginal. -- Karsten Keil SuSE Labs ISDN development
Karsten Keil wrote:
Der 2.4 kernel kann es (seit wann weiss ich ohne Suche nicht). [...] Keine Patches, sondern Bestandteil des 2.4.7 orginal.
Dann wäre es ja von Vorteil, wenn die SuSE Distri das auch nutzen würde. Evtl könntet Ihr da ja sogar noch ein Update veröffentlichen ? Gruß Andreas
At 11:56 09.11.01 +0100, Karsten Keil wrote:
Bei mir sind es hauptsächlich Peer-to-peer Tauschdienste! Durch die dynamische IP Vergabe rutscht man da irgendwie rein. :-( Auch scheint es bei diesen Diensten keine vernünftigen Timeouts zu geben. Das ist der Obermurx!
Nein, das ist meistens richtig, das Problem sind die dynamischen IPs, das ist der Murks, laest sich aber nicht aendern.
Ich habe das Problem schon vor einem 3/4 Jahr an T-Online weitergereicht. Mit dem Hinweis, daß die IP ert nach Ablauf von mind 15 Minuten wieder vergeben werden darf. Eine Kopie ging an die c`t. Leider gabs keine brauchbare Antwort. In den letzten Tagen hatte ich mit einem Mitarbeiter der Telekom gesprochen. Er sagt mir, daß die ISPs, die T-dsl nutzen, die IPs nerst nach Ablauf dieser Zeit wiederverwenden dürfen. Im Moment laufen bei mir hunderte von DENYs auf. Alle auf dem gleichen (incomming) Port 4665 aber von unterschiedlichen IPs und unterschiedlichen Ports. Hat da jemand eine Idee? Matthias Matthias Jänichen
participants (6)
-
Andreas Fiesser -
Karsten Keil -
Matthias Jaenichen -
Michael Mauch -
Peter Mack -
Thomas Hog