Firewalls sind sinnlos aber...

[MSfree]

Ob mir meine Firewall oder mein Linux Kernel die passenden Pakete dropt ist völlig egal.

Nein, ist es nicht. Es ist schon ein deutlicher Unterschied, ob der Netfilter-Code das Paket verwirft, bevor es in den Netzwerkstack geht als wenn der Netzwerkstack die Anfrage auch noch mit "unreachable" beantwortet.

Ganz im gegenteil schafft du dir einen weiteren Angriffspunkt: Die Firewall.

Sorry, das ist im Zusammenhang mit iptables Schwachsinn.

Einzig wenn du expliziet ein Programm installierst, dass auf eingehende Verbindungen hört ändert sich was. Wenn du das machst, willst du ja aber vielleicht, das es tut… Wenn nicht – Deinstalliere es und bau keine Firewall davor.

Ganz toller Rat.

Und wenn du das Programm dann doch mal brauchst, installierst und konfiguriest du es wieder?

Ne, ne, so geht das nicht.

Firewall davor und gut ist.

[schorsch_76]

Ich habe im Leben noch nie gesehen, dass irgend welche andere Clients in einem WLAN was unlegitimes gamacht haben. Hier und da mal ein Torrent client, der fragt, ob das File, dass er da gerade zieht schon jemand anders im LAN hat und jede menge Windows systeme die im allgemeinen sowieso verbal inkontinet sind.
Das sind eher DNS-Server, vom Anbieter, die verfälschte (werbeversächte) ergebnise liefern oder Proxys wie dei von uname, die versuchen die Videoqualität bei youtube runterzusetzen.

Lass mich das mal damit beantworten.
http://dilbert.com/strip/2015-06-21

[mclien]

Ich hatte tatsächlich nicht vor ssh jedesmal zu de/installieren, wenn das Notebook in meinem und dann wieder in einem fremden Netz ist.

Da scheinen mir die 2 links in /etc/rc?.d/ einfacher zu warten.
Desshalb wäre es total net wenn mir noch jemand die Frage beantworten könnte ob rc2.d (S...) und rc0.d (K..) ausreichend sind oder ob ich wieder einen runlevel übersehen habe, der auch einen link abbekommen sollte.

Oh Mist rcS.d natürlich auch, oder?

[MSfree]

Ich hatte tatsächlich nicht vor ssh jedesmal zu de/installieren, wenn das Notebook in meinem und dann wieder in einem fremden Netz ist.

Der ssh-CLient ist diesbezüglich sowieso unproblematisch, der ssh-Server müßte hat jedes Mal aus- und angeschaltet werden.

Da scheinen mir die 2 links in /etc/rc?.d/ einfacher zu warten.

Auch das halte ich für viel zu fehleranfällig, zumal seit Debian 8 mit systemd das Initsystem "etwas" anders funktioniert.

Ich weiß ja nicht, was auf dem Notebook alles laufen muß. Auf meinen 6 Notebooks habe ich keine einheitliche Softwarelandschaft. Aber Apache, SSH-Server, SMB-Server, NFS-Server und X-Server laufen eigentlich auf jedem, weil das für Datenaustausch in heterogenen Netzen notwendig ist. Auf einigen habe ich noch ein paar andere Serverdienste. Ich hätte keine Lust, mir jedesmal eine Kopf darüber zu machen, was ich im Ausseneinsatz alles abschalten müßte. Mit einem Skript, das per iptabels alles, was reinkommt, sperrt, ist die Sache genz einfach zu handhaben.

[thoerb]

Ich weiß ja nicht, was auf dem Notebook alles laufen muß. Auf meinen 6 Notebooks habe ich keine einheitliche Softwarelandschaft. Aber Apache, SSH-Server, SMB-Server, NFS-Server und X-Server laufen eigentlich auf jedem, weil das für Datenaustausch in heterogenen Netzen notwendig ist.

Server-Software läuft bei mir nur auf dem Home-Server, auf allen anderen Geräten habe ich bis auf ganz wenige Ausnahmen nur Clients installiert, damit komme ich bestens aus.

[guennid]

Das artet wieder aus in eine Diskussion, in der Könner andern Könnern ein Schnippchen schlagen wollen. mclien, das wird deine Tochter weder können, noch wollen, noch können wollen. Also pass auf, was du tust, bevor du ihr den Schleppi lahmlegst!

***duck und weg***

[MSfree]

Server-Software läuft bei mir nur auf dem Home-Server, auf allen anderen Geräten habe ich bis auf ganz wenige Ausnahmen nur Clients installiert, damit komme ich bestens aus.

Wenn man mit einem Notebook nicht nur surfen und Filme schauen will, sondern auch mal ausser Haus arbeiten muß, ist eine gewisse Zahl von Werkzeugen und Servern eben unabdingbar. Das schöne ist ja, daß jeder für sich entscheiden darf, was er braucht. Deshalb kann man auch keine pauschale Antwort darauf geben, ob eine Firewall sinnlos ist oder nicht.

[mclien]

...
EDIT:
liegt hier: http://nopaste.debianforum.de/39463
sieht aber verdächtig danach aus, als ob das irgendein basic script ist, dass ich auch hier aus dem Forum hatte

Das ist ein Shell/init Script das wohl in den Systemstart eingebunden werden soll. Es macht alle Ports von Außen zu und erlaubt alle ausgebende Kommunikation. Da kann nicht viel schief gehen

Anscheinend wohl doch...
Selbst wenn ich das script von Hand starte ist port 22 für ssh noch auf
EDIT:
bin schon wieder blöd! Auf ist der port ja schon, aber eben gefiltert. Allerdings bin ich schon wieder depromiert, dass mir mal wieder Kenntnisse fehlen. In diesem Fall: Wie sehe ich denn nun, ob die iptables Regeln greifen? (ausser mit oginversuchen?)

[Radfahrer]

Das artet wieder aus in eine Diskussion, in der Könner andern Könnern ein Schnippchen schlagen wollen.

Ich würde auch dringend dazu raten, im Bett einen Helm zu tragen, denn es könnte ja sein, dass einem Flugzeug unterwegs der Sprit ausgeht, es abstürzt, ganz in der Nähe des eigenen Schlafzimmers aufschlägt, dadurch ein kleines Erdbeben verursacht, das Haus, in dem man wohnt, ein kleines bisschen zum Wackeln bringt und dadurch löst sich dann im Schlafzimmer genau über dem Kopfkissen ein Stück Putz von der Decke.....

...und schon haben wir den Salat!

Also lieber vorsichtig sein! Helm auf!

[mclien]

Ja alles ehr putzig.

Allerdings habe ich folgendes Verständnidproblem:

Ich starte die firewall, bekomme aber mit meiner "standard" Methode nach laufenden Prozessen zu suchen (ps -ef |grep iptables) nix angezeigt.
Der Portscan von Heise zeigt mir an, dass port 22 ssh offen ist (nunja das ist ja richtig, aber haben die nicht auch mal diagnostiziert, ob an dem offen port gefiltert wird? (Hinweise sehr willkommen)

Jedenfalls komme ich über port 22 intern nicht mehr rein...

[MSfree]

Ich starte die firewall, bekomme aber mit meiner "standard" Methode nach laufenden Prozessen zu suchen (ps -ef |grep iptables) nix angezeigt.

iptables ist ein Befehl, der nur sehr kurz läuft und die Filterregel im Kernel einträgt. Daher siehst du mit ps auch nichts. Wenn du die erstellten Regeln sehen möchtest, geht das relativ einfach mit dem Befehl iptables-save, der eigentlich dazu gedacht ist, eine Regelliste zu erstellen, die mit iptables-restore wieder einlesbar ist.

Der Portscan von Heise zeigt mir an, dass port 22 ssh offen ist

Der Portscan wird wohl deinen Router scannen und der hat wohl ein Portforward auf irgendeinen deiner internen Rechner eingerichtet.

[mclien]

Der Portscan von Heise zeigt mir an, dass port 22 ssh offen ist

Der Portscan wird wohl deinen Router scannen und der hat wohl ein Portforward auf irgendeinen deiner internen Rechner eingerichtet.

Das nicht, da ich über freifunk im Netz war. Aber korrekt, die werden ggf. den port zu Wartungszwecken erreichbar haben.