✔ Suche Hilfe zu "bash-commands"

[Dennis Wronka]

So, auf die schnelle erstmal einen Link zu meinem kleinen IPTables Tutorial.

Wenn ich meine Pizza auf hab gibt's hier dann auch noch eine kurze Erklaerung zu den von Dir geposteten Zeilen.

So, los gehts:

Erstmal allgemeines zum Format.
Die Zeilen die mit : beginnen beziehen sich auf die Ketten die IPTables bietet, hier INPUT, FORWARD und OUTPUT, welche die Standard-Ketten fuer den Paketfilter sind.

Andere Ketten findest Du z.B. ueber die Tabellen NAT und Mangle, dort gibt es dann auch noch z.B. PREROUTING und POSTROUTING.

Details dazu findest Du auch im bereits zuvor verlinkten Tutorial.

In diesen Zeilen wird die Default-Policy (hier ACCEPT) und der Paketzaehler ([0:0]) gesetzt.

Der Name der Ketten steht fuer die Richtung der Pakete. INPUT behandelt Pakete die reinkommen, OUTPUT Pakete die rausgehen. Pakete die durch den Rechner hindurchgeroutet werden laufen durch FORWARD.

Zu den abgebildeten Regeln. Das Format entspricht dem Aufruf von IPTables.
Auf der Kommandozeile aufgerufen wuerde die erste Zeile also so aussehen:

iptables -A INPUT -d 127.0.0.1 -j ACCEPT

-A INPUT -d 127.0.0.1 -j ACCEPT

Hier werden alle Pakete akzeptiert die als Zieladdresse 127.0.0.1 haben.
Meiner Meinung nach ist es aber besser mit dem Loopback-Device zu arbeiten da eine IP ja auch gefaelscht werden kann.
Ich faende hier also -A INPUT -i lo -j ACCEPT besser.

-A INPUT -p tcp -m tcp --dport 5190 -j ACCEPT

Diese Regel erlaubt eingehende Pakete auf TCP-Port 5190. Laut /etc/services ist dies AOL. Meine Erinnerung sagt mir dass ICQ ueber diesen Port laeuft.
Die Frage ist nun ob auf dem Rechner irgendein Dienst auf diesem Port lauscht oder ob dieser Port freigegeben ist damit Du ICQ nutzen kannst. Falls letzteres der Fall sein sollte ist diese Regel unnoetig.

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Dies ist die Regel die Du suchst, denn hier wird Zugriff auf TCP-Port 22, den SSH-Server, erlaubt.

-A INPUT -p tcp -m tcp --dport 5900 -j ACCEPT

Hier wird Zugriff auf TCP-Port 5900 erlaubt. Ich wuesste jetzt spontan nicht was dort laeuft. /etc/services ist hier auch keine Hilfe. Im Zweifelsfall gilt was ich beim ICQ-Port gesagt hab, falls der Port offen ist damit Du irgendein Chat-Programm oder aehnliches nutzen kannst koennte die Regel ueberfluessig sein.

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Diese Regel erlaubt Zugriff auf TCP-Port 80, den Web-Server.

-A INPUT -p tcp -m tcp --dport 3000 -j ACCEPT

Dies erlaubt eingehende Verbindungen auf TCP-Port 3000, laut /etc/services als HBCI ausgezeichnet, was meiner Meinung nach was mit Home-Banking zu tun hat.

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Diese Regel erlaubt es alle Pakete reinzulassen die zu einer bestehenden Verbindung gehoeren oder einen Bezug zu einer bestehenden Verbindung haben.
Letzteres ist z.B. bei FTP der Fall, dort werden 2 Verbindungen genutzt.
Meiner Meinung nach sollte diese Regel weiter oben genutzt werden, wichtig ist dies aber nicht.
Der grosse Nutzen dieser Regel ist dass alles was Du haben willst auch rein darf.
Ohne diese Regel muesstest Du im Grunde Traffic auf allen Ports > 1024 erlauben, da dies die Ports sind die zur Kommunikation nach draussen genutzt werden.
Wenn beides nicht der Fall ist dann kannst Du nichtmal surfen da die Antwort-Pakete auf Deinen Anfragen nicht reingelassen werden.

-A INPUT -j DROP

Diese Regel verwirft alle Pakete die von keiner vorigen behandelt, also akzeptiert, wurden.
Besser waere es hier meiner Meinung nach RFC-konform zu arbeiten und z.B. TCP-Pakete mit einem TCP-Reset zu beantworten, etc. Dazu gibt es, wenn ich mich recht erinnere, mehr in meinem Tutorial.

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Diese Regel ist zum einen doppelt, zum anderen hier vollkommen sinnfrei da in der vorigen Regel alles was bislang nicht behandelt wurde behandelt wird indem es zur Hoelle gejagt wird.

 

[Paspirgilis]

ok toll das du dir zeit nimmst einem sowas zu erklären obwohl du ihn gar nicht kennst.

jetzt sieht meine iptables.rules so aus:

# Generated by iptables-save v1.3.8 on Tue Sep 30 22:15:08 2008
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j DROP  
COMMIT
# Completed on Tue Sep 30 22:15:08 2008

 

[Navy]

Besser waere es hier meiner Meinung nach RFC-konform zu arbeiten und z.B. TCP-Pakete mit einem TCP-Reset zu beantworten, etc. Dazu gibt es, wenn ich mich recht erinnere, mehr in meinem Tutorial.

Und mit "TCP-Reset" meint Dennis natürlich "TCP-Reject".

 

[Paspirgilis]

Der Unterschied ist doch nur das bei dem einen ne Nachricht kommt (auch selbst einstellbar) und beim anderen nicht.
Bei beiden wird ssh abgeblockt oder?

gibs ne möglichkeit den mit mit extra pw abzusichern statt abzublocken?
also man brächte dann das ssh pw und danach ncoh das pw um sich als root oder als ein anderer user einzuloggen.


Ist das möglich?

 

[Navy]

Bei TCP-Drops werden Nachrichten vom Empfänger einfach verworfen anstatt ordnungsgemäß eine Antwort zu schicken. Viele ganz toll "sichere" Desktopfirewall -- deren einziger Nutzen im Schaffen eines unberechtigten Sicherheitsgefühls besteht -- nutzen diese Möglichkeit in ihrem sogenannten "stealth"-Modus um einem Angreifer vorzugaukeln, dass ein Host nicht existiert. Aber gerade ein drop bestätigt ja die Existenz eines Systems, da bei Nichterreichbarkeit dessen eine ebensolche Nichterreichbarkeitsmeldung aus dem Netz kommen würde.

ssh an sich ist nicht mit einem eigenen Passwort absicherbar, Du kannst aber eine ganz einfach Sicherheit schaffen, indem Du "root" ssh verbietest und allein *einem* einschränken und über chroot gekapselten Account Zugriff darauf erlaubst. Das bedeutet, dass User sich erst über den Minimalaccount und danach auf ihren User einloggen müssen. Außerdem kann man noch die Quellnetze, Einlogversuche und Zugriffszeiten einschränken.

 

[Paspirgilis]

zeitdruck*

bis 19:30 muss ich das hinkriegen.
Mein linux ubuntu muss vor der boot-cd methode geschützt werden.

bitt um schnelle hilfe

MFG

 

[Dennis Wronka]

Und mit "TCP-Reset" meint Dennis natürlich "TCP-Reject".

Nein, ich meine wirklich einen TCP-Reset.

iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset

Siehe auch RFC 793.

zeitdruck*

bis 19:30 muss ich das hinkriegen.
Mein linux ubuntu muss vor der boot-cd methode geschützt werden.

bitt um schnelle hilfe

MFG

Verschluessle das gesamte Dateisystem mittles cryptsetup. Duerfte aber mit der Zeit etwas eng werden, wenn ich bedenke dass bei Euch mittlerweile 6 Uhr Abends sein duerfte.

Alternativ koenntest Du, duerfte aber nicht viel weniger zeitaufwaendig sein, das Dateisystem in einem LVM verstecken.
Diese recht einfache Loesung, welche ansich eigentlich keine Sicherheit bietet, duerfte schon schwer genug fuer die meisten User zu umgehen sein, darunter wahrscheinlich auch so einige die bereits eine ganze Weile mit Linux arbeiten.

Problem ist jedoch dass Du fuer beide Methoden das gesamte FS mindestens einmal komplett kopieren musst. Zudem musst Du Dir natuerlich auch noch "mal eben" das Wissen aneignen wie Du ein verschluesseltes FS oder LVM anlegst, und dann auch noch davon booten kannst.

 

[Navy]

Nein, ich meine wirklich einen TCP-Reset.

Seit dem ich wieder als Entwickler arbeite passiert mir das ständig. Das Flag heißt natürlich Reset (RST), wodurch ein Reject erreicht wird. Mea Culpa

 

[Dennis Wronka]

Ist ja kein Problem. Irren ist menschlich, wie man so schoen sagt.

 

[Paspirgilis]

Ich möchte mich hiermit bei allen die mir so gut geholfen haben bedanken.
Es ist toll was ich alles in den paar tagen gelernt hab.
Ich schließe hiermit diesen thread ab weil mein ziel erreicht ist.
Ich wusste vorher gar nichts über linux und hatte nur wine genutzt um windows ähnlicher arbeiten zu können.
Jetzt öffne ich ein terminal verschiebe dateien mit mv, lösche daten mit rm und editiere daten mit nano "filename" oder nutze halte den sudo befehl und etc dateien zu editieren. programme installiere ich mit apt-cache search und apt-get install.
Freut mich das ich von windows erfolgreich abgekommen bin.

MFG
Mark Paspirgilis