Benutzer:Lars/Blog:2014 November 25 01:39:29 CET - Versionsgeschichte

Lars: Einstieg

2014-11-25T00:54:08Z

Einstieg

← Nächstältere Version		Version vom 25. November 2014, 00:54 Uhr
Zeile 1:		Zeile 1:
	=== Montagstreffen (24.11.2014) ===		=== Montagstreffen (24.11.2014) ===
			Unser Raum war heute wieder in entspannter Stimmung gut überfüllt.

	=== Presse-Besuch ===		=== Presse-Besuch ===
	Eine Dame von der OZ hat uns besucht und ihren Notizblock gefüllt. Morgen vormittag werden Philipp und Lothar einem Foto der Frieda-Installation beiwohnen.		Eine Dame von der OZ hat uns besucht und ihren Notizblock gefüllt. Morgen vormittag werden Philipp und Lothar einem Foto der Frieda-Installation beiwohnen.


	=== Umgang mit abuse-Meldungen ===		=== Umgang mit abuse-Meldungen ===

Lars: Titel, Presse, Details

2014-11-25T00:51:29Z

Titel, Presse, Details

← Nächstältere Version		Version vom 25. November 2014, 00:51 Uhr
Zeile 1:		Zeile 1:
			=== Montagstreffen (24.11.2014) ===

			=== Presse-Besuch ===
			Eine Dame von der OZ hat uns besucht und ihren Notizblock gefüllt. Morgen vormittag werden Philipp und Lothar einem Foto der Frieda-Installation beiwohnen.


	=== Umgang mit abuse-Meldungen ===		=== Umgang mit abuse-Meldungen ===
			Wir hatten kürzlich auf einem unserer UGW-Server ([[Server/erina]])) mehrere abuse-Meldungen bezüglich eines ehemaligen Schadsoftware-Servers, der aus unserem Netz heraus angesprochen wird. Hier müssen wir im Spannungsfeld von Netzhygiene und Privatsphäre unserer Nutzenden einen Umgang finden.

	==== Ziele ====		==== Ziele ====
	Unsere Ziele (~~die~~ Anwesenden im Raum):		Unsere Ziele (der Anwesenden im Raum):
	* keine schadhaften Dinge innerhalb unseres Netzes		* keine schadhaften Dinge innerhalb unseres Netzes
	* positives Verhältnis zum Provider		* positives Verhältnis zum Provider
Zeile 31:		Zeile 38:

	==== Ergebnis ====		==== Ergebnis ====
	Wir einigen uns vorerst darauf, Zugriff auf uns gemeldete Zielserver (inkl. Port) zu sperren.		Wir einigen uns vorerst darauf, Zugriff auf uns gemeldete Zielserver (inkl. Port) zu sperren (ohne sie zu loggen).

	Falls die Zugriffe nicht so leicht eingrenzbar sind, dann müssen wir uns etwas neues überlegen.		Falls die Zugriffe nicht so leicht eingrenzbar sind, dann müssen wir uns etwas neues überlegen.

	Nach sechs Monaten wollen wir neu bewerten, ob die Sperrung weiterhin sinnvoll ist.		Nach jeweils sechs Monaten wollen wir neu bewerten, ob die Sperrung weiterhin sinnvoll ist.

	Technisch: vielleicht via munin plotten, um die Relevanz der Sperrung im Nachhinein einschätzen zu können.		Technisch: vielleicht via munin plotten, um die Relevanz der Sperrung im Nachhinein einschätzen zu können.

Lars: init

2014-11-25T00:47:06Z

init

Neue Seite

=== Umgang mit abuse-Meldungen ===

==== Ziele ====
Unsere Ziele (die Anwesenden im Raum):
* keine schadhaften Dinge innerhalb unseres Netzes
* positives Verhältnis zum Provider
* keine schadhaften Dinge von unserem Netz in das Netz da draußen
* betroffenen Nutzern im Opennet helfen
* Schutz der Privatsphäre der Nutzenden

Wir haben eine Gewichtung der obigen Punkte vorgenommen:
* höchste Relevanz:
** Providerverhältnis
** Privatsphäre
* mittlere Relevanz:
** kein Schaden im Opennet
* niedrige Relevanz:
** kein Schaden im Intern
** Opennet-Nutzenden helfen

==== Technische Möglichkeiten ====
Wir haben Gedanken gesammelt, welche Maßnahmen wir ergreifen könnten.

* A) nach einer abuse-Meldung loggen wir zeitlich begrenzt Zugriffe aus dem Opennet für diesen Ziel-Host/-Port loggen
* B) ausgehende Ports mit internen IPs zusammen kurzfristig speichern
* C) nach einer abuse-Meldung sperren wir zeitlich begrenzt Zugriffe auf das Ziel (keine Speicherung)
* D) Speicherung auf eine Art, die es nur den Nutzenden ermöglicht, ihre Protokolldaten zu erlangen (z.B. Verschlüsselung mit ihrem Router-Zertifikat)
* E) Unabhängig von Providern werden (dann müssen wir uns um abuse-Meldungen keine Gedanken machen)
* F) Schwedentunnel
* G) Nutzende können wählen, ob ihre Zugriffe auf abuse-bekannte Zielserver

==== Ergebnis ====
Wir einigen uns vorerst darauf, Zugriff auf uns gemeldete Zielserver (inkl. Port) zu sperren.

Falls die Zugriffe nicht so leicht eingrenzbar sind, dann müssen wir uns etwas neues überlegen.

Nach sechs Monaten wollen wir neu bewerten, ob die Sperrung weiterhin sinnvoll ist.

Technisch: vielleicht via munin plotten, um die Relevanz der Sperrung im Nachhinein einschätzen zu können.

=== Netzstruktur ===
Von Menschen beim Treffen wurde geäußert, dass die Netzqualität in ihrem Umfeld wieder gut nutzbar ist.

Da also die [[Rostock-Netzausbau-2014|Maßnahmen 2 und 3]]] vom letzten Treffen Wirkung gezeigt haben, könnten wir eventuell im Licht der geänderten
Umstände, prüfen ob wir den angedachten DSL-Anschluss an der Uni weiterhin kurzfristig mieten wollen.

Bitte an alle: gebt uns Feedback zur aktuellen Netzqualität in Rostock.

Ein grober Überblick zu den kursierenden Gedanken:
* den DSL-Anschluss an der Uni abbestellen?
* in zwei Monaten anhand von Netzgraphen und Nutzermeldungen prüfen, ob wir langfristig einen DSL-Anschluss in der Stadt betreiben wollen?
* eventuell von [[Server/erina]] aufgrund teilweise schlechter Routen in manche Netze trennen oder die Anbindung verbessern?

==== Sonstiges Vorgehen ====
* Mail an die Nutzenden schreiben:
** wir haben die wichtigsten Probleme gelöst (soweit unsere Meinung)
** falls ihr weiterhin Probleme wahrnehmt, dann meldet euch