Re: Richtiges Traffic Accounting

> Und nebenbei hast Du natürlich zwangsläufig nicht nur auf
> Port 80 Traffic. Ab und zu wird es auch mal DNS-Anfragen
> geben, vielleicht gleichst Du Deine Uhrzeit per NTP ab (was
> ja generell empfehlenswert ist), und das eine oder andere
> ICMP-Paket wird auch auch Deinen Port passieren.

die fragwürdigen ca 600 MB kommen sicher nicht von ICMP, auch wenn Ntop
hier noch 170 MB für ARP listet. Nachgeprüft mit tcpdump macht der
Router hier im Subnet ja mehrmals die Sekunde arplookups, ist das normal?

Ich versuche mit Ntop ja nachvollziehen zu können weshalb sich die
Rechnung bei meinem ISP durch entstandenen Traffic etwa verdreifacht
hat, ohne das mehr Hits auf der Website erzielt wurden (alles was der
Server so eigentlich macht). Die Filter im Ntop zeigen monatsmäßig für
Juli also bis jetzt ca. 300 MB für HTTP und 900 MB für IPSec.

Ntop arbeitet aber auch im promiscuous (gibts das Wort nich einfacher?)
mode und anscheinend loggt es da auch Traffic mit der zwischen anderen
Hosts passiert (auch wo mein Rechner doch kein Router ist). Egal wie
scheint es ja vom ISP ins Accounting zu gehen und mir in Rechnung
gestellt zu werden, was mir nicht wirklich Recht ist.

> Naja, ein Angriff (oder sei es nur ein Scan) erzeugt halt
> auch Traffic. Erstens natürlich die Scan-Pakete, die ja
> durchaus bei Dir ankommen und als Incoming-Traffic gezählt
> werden müssen -- das läßt sich nicht verhindern, es sei
> denn, das Zeug wird schon irgendwie von Deinem Provider
> weggefiltert. Und dann schickt Dein Rechner ja wiederum
> -- wie jeder korrekte TCP/IP-Stack -- Pakete mit TCP-Resets
> zurück (das erzeugt dann auf der Gegenseite ein »connection
> refused«), es sei denn, Du dropst das Zeug einfach in der
> Firewall (blackhole).

blackhole ist an, das Logging von so Portscans aber auch. In den Logs
nichts ungewöhnliches aber.

> 500 MB IPSec-Traffic ist schon 'ne Menge, wenn Dein Rechner
> gar kein IPSec macht. Über welchen Zeitraum ist das denn
> gemessen? Und bist Du sicher, daß ntop das richtig inter-
> pretiert? In Zweifelsfall würde ich einem mitgelieferten
> Tool (IPFW-counter, tcpdump) eher trauen als einem Third-
> party-Tool wie ntop, trafshow o.ä.
>
> > Gibt es noch andere Möglichkeiten ein- und ausgehenden Traffic zu
> > überwachen und diesen später zu prüfen?
>
> Zum Beispiel per IPFW. Jede Regel hat einen Counter einge-
> baut (sowohl für Pakete als auch für Bytes). Man kann auch
> explizite »count«-Regeln erzeugen, wenn man gar nicht fil-
> tern will, sondern nur zählen. Die Counter kann man mit
> »ipfw show« auflisten und mit »ipfw zero« auf Null zurück-
> setzen.

dann werd ich mal ipfw auswerten.

> > Ist der promiscuous mode
> > sinnvoll?
>
> Der wird z.B. von tcpdump automatisch eingeschaltet (kann
> man per Kommandozeilen-Option beeinflussen). Vielleicht
> tut das ntop auch bereits. Ob der sinnvoll ist oder nicht,
> kommt halt darauf an, was Du messen willst.
>
> Wenn er eingeschaltet ist, siehst Du allen Traffic, der
> physikalisch Dein Interface »berührt«, egal ob er für Dei-
> nen Rechner bestimmt ist oder nicht.

Hm, wo ich mich wieder frage was der ISP ins Accounting nimmt, eben
diese physikalischen Berührungen?

> Naja, und Broadcasts natürlich, und unter gewissen Umstän-
> den auch noch andere Sachen (Multicast, bei Switches mit
> Spanning-Tree wirst Du STP sehen, usw.). Davon abgesehen
> brauchen Switches auch eine gewissen Lernphase -- wenn sie
> den Status eines Ports nicht kennen oder sich etwas ändert,
> schicken sie erstmal zur Sicherheit alles dorthin, mal ganz
> abgesehen von Angriffen, mit denen das Switching beeinflußt
> werden kann (z.B. Stichwort ARP-cache-poisoning).
>
> Es gibt viel mehr, was da so kreucht und fleucht, als man
> gemeinhin vermuten mag. ;-)

jaja, da lob ich mir doch meinen NAT-Router zu Hause. Was "da draussen"
sich so an Gesindel rumtreibt :)

Philon

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 14 Jul 2004 - 13:12:12 CEST