Knockd Installation
 

Dies ist ein kleines Tut wie ihr auf eurem Server Knockd installieren könnt.
Serverseitig verwende ich Linux Debian-etch
Clientseitig Windows XP

In erster Linie ist die sein Tut zum absichern von SSH

Das Tutorial ist akribisch in der Reihenfolge zu befolgen, andernfalls werdet ihr euch vom System aussperren! Ich übernehme keinerlei Gewährleistung und gehe davon aus dass dieses Tut nur von denjenigen angewendet wird die sich mit Servern schon eingehend befasst haben.

Bei anderen Betriebssystemen kann es Abweichungen geben.

Was tut knockd?
Knockd ist ein Programm, dass Security by Obscurity bietet, dh. ein eventueller Hacker mit Portscan kann nicht entdecken da die Portöffnung selbst durch eine Art Passwort geschützt ist, dh der Port Standardmässig ZU ist. Diese Art Passwort wird durch eine festgelegte Reihenfolge von Paketen definiert die knockd an bestimmten festgelegten Ports des Servers gemäss seiner Konfiguration erwartet damit er einen Befehl auf dem Server ausführt.
In unserem Fall beeinflussen wir damit die Linux Firewall, die iptables

Wozu also?
Gehn wir von einem nicht mit allen Wassern gewaschenen Hacker aus, der nen Portscan macht... ohne Knockd und installiertem SSH sieht der Hacker also ohne weiteres das der PORT offen ist.
Falls wir Knockd installiert haben und damit den SSH Port verschleiert haben (also solange geschlossen bis wir 'anklopfen') sieht dieser hacker diesen Port zu und kann auch nichts machen da er auch wirklich zu ist *lmao*
Da wir ja knockd installiert und konfiguriert haben, können wir aber auf den Server verbinden sobald wir vorher angeklopft haben... dies erkläre ich in diesem Tutorial.

Howto:
1. knockd Installieren:
2. knockd konfigurieren:
Datei: /etc/default/knockd


Datei /etc/knockd.conf

Sequenz anpassen, wie ihr sie haben wollt. Form *PORT*:protokoll
Protokoll ist tcp und udp möglich, ich empfehle zu mischen.


3. Client Runterladen:
zeroflux.org
(Windows Xp/Vista: Cygwin/Win32 Knock Client )
Den Ordner schiebt ihr dorthin wohin ihr ihn haben wollt, ist völlig egal.

4. Neue Batch Datei runterladen (Anhang)

5. Batch anpassen
Batches kann man mit nem ganz normalen Editor bearbeiten.
Die Batch baut sich so auf:
ist damit die Ausgabe unterdrückt wird
ist damit der Konsolenschirm gesäubert wird

Dann der Befehl:
So würde er zumindest aussehen, jedoch fiel mir auf, wie oben schon gesagt dass er die Pakete so verdammt schnell abschickt, dass sie beim server als
ankommen oder schlimmer durchgewürfelt, also in falscher reihenfolge.
Mein Workaround ist hier also eine Batch die zwischen jedem Paket eine minimale Pause einlegt.
Die Pause wird durch einen 1 Sekunden ping auf den eigenen Rechner erreicht (der Befehl war einfach als einzige Pausenfunktion auf allen Windows OS gleich.)

Die Batch baut die Sequenz also so auf:
1. Knock
Pause
2. Knock
Pause
3. Knock
Pause
4. Knock
Nach dem Letzten muss keine Pause, es sei denn es folgen weitere Knocks.
Diese Batch wurde aufgrund der Beispiel sequenz gemacht, dh ihr solltet eure Sequenz entsprechend ändern.

Beispiel:


Es können beliebig viele Knocks vereinbart werden. ich empfehle MINDESTENS 3 verschiedene. Gut finde ich 4 , aber für paranoide gehen unendlich mehr....

Batch speichern!

6. Testlauf!
Konsole eingeben:
knockd --debug --verbose

Es sollten einige Zeilen mit infos kommen an dessen Ende:
listening on eth0...
steht.

Dann klopft ihr mit euer gerade eben gemachten Batch an indem ihr ebendiese durch einen doppelklick ausführt.

in euer Konsole sollte dann eine Reaktion erfolgen die, bei erfolg die Steps angibt (jedes am richtigen Port angekommene paket ist ein Step) und dann nach den Steps diese Nachricht gibt:
Da haben die Entwickler wohl etwas Humor gehabt... nunja XD
Danach wird der befehl den wir vorher in start_command festgelegt haben ausgeführt.
nach cmd_timeout (in sekunden) wird der stop_command ausgeführt.
ersterer fügt der Firewall eine regel hinzu die UNSERER Ip den Zugang zum SSH Port gewährt. Letztere löscht ebendiese Regel nach der Zeit aus cmd_timeout. Wir haben hier 1 Stunde Konfiguriert. Solange kann man arbeiten am SSH bevor man erneut Knocken muss.

7. knockd aktivieren
befehl in der konsole:
/etc/init.d/knockd restart


8. SSH Port Sperren
Ist dies alles erfolgreich, sperren wir nun den SSH Port komplett.
Das ist wohl das gefährlichste, denn wenn in unserer ganzen vorherigen Konfiguration was falsch ist, heißt das SSH zugang ade. Helfen tut dann nur noch direkt an den Server per Schnittstelle ,Providerseitige Hilfe oder (falls vorhanden) Administrationsoberfläche (Webmin etc.).

Also falls schiss bekommen... lieber jetzt aufhören bevor man viel ärger wegen unfähigkeit hat :P

Befehl der konsole:
iptables -A INPUT -p tcp --dport 22 -j DROP

9. Das wars eigentlich... nun solltet ihr erstmal aus der konsole fliegen.
Wiederverbinden wäre dann per Knocken und dann Verbinden per SSH client für 1 Stunde. Falls ihr etwas an der Konfiguration von knockd ändern wollt könnt ihr das jederzeit tun, müsst änderungen der Sequenz auch wieder auf eure batch übertragen. knockd muss nach Änderungen wieder neugestartet werden.


Als Anhängsel:
Ich habe ca. 5 Knockd Dokus gewälzt und Die Funktion der IPtables lernen müssen bis ich dieses Tut machen konnte und auch dass es auf meinem Server funktionierte. Während ich dies an meinem Server gemacht habe habe ich mich 3 Mal ausgesperrt gehabt... habe aber nun rausgefunden woran es lag und so läuft es nun auch auf meinem Server einwandfrei.

Grüße von mir...
Euer Sol

nette anleitung ;)

ich verwende seit einiger zeit knock mit einer firewall die alle ports außer port 80 abdichtet

diese firewall wird dann über den knock abgeschaltet und nach dem timeout wieder angeschaltet

bisher ohne probleme und man fühlt sich besser *g*

hatte ich das nicht schon einmal irgendwo gepostet ?

jup im glossar ist noch ne anleitung :D aber doppelt hält besser :D

im glossar steht noch ne knockd anleitung... aber etwas abgespeckter... von DarkEvil...
von dir ist mir das jetzt nicht bekannt GH.

Zero... hast du das proble auch dass bei normalaufruf der client schneller sendet als der server empfangen kann und deshalb die reihenfolge der sequenz durchnanderkommt?
ich hab hier zwar nen workaround rein aber nett find ich das nich...

Irgendwo hatte ich das hier mal gepostet mit nem link und dark hat dann die anleitung nochmal ins Glossar gesetzt als der link nicht mehr ging so war das glaube ich

Solstice dieses Problem hab ich net... meine Batchdatei besteht nur ein einer Zeile :D nach klick hab ich sofort zugriff

müssen es bei der sequenz immer die selben zahlen sein:
oder kann ich hier warlos mischen?
z.b.

du kannst wahllos mischen... mit 0 sollten sie jedoch nicht beginnen... beachte auch dass der höchste port 65535 ist. alle darüber sind ungültig.

Ich hab nur ein beispiel gemacht... bzw zwei wenn du dir den beispielspoiler auch anschaust.

Edit:
@Zero
Hier so wie es bei mir mit einem Befehl läuft ohne Zeitverzögerung:
Auf Client:
http://www.info-panel.net/test/uploa...2909client.png

Auf dem Server kommt das aber so an:
http://www.info-panel.net/test/uploa...2842server.png

Also der erste ist dann noch richtig udn die anderen durcheinandergewürfelt...

Edit2:
Weils mir grad so spass macht hab ich noch n paar gemacht... hähä
Meine Sequences hab ich rausgelöscht XD

man leute die einzelnen packete haben einfach unterschiedlichelaufzeiten.
würde der knock client inteliegenter alles in einen frame werfen wäre das egal aber so ist jedes anklopfen ein packet und kann unterschiedlich schnell geroutet werden.
das ist standart bei tcp :D

Das weiß ich doch...
deswegen wunder ich mich ja warums bei Zero geht...

Naja du weist das :D
Aber nun wissen alle dies lesen und noch nicht wussten, das das KEIN bug ist, sondern eigentlich ganz normal :D

bei mir funzt es problemlos

eingabe in cmd prompt (testsequenz)
Anhang 3957

Meldung im putty fenster (knockd im Debugmodus)
Anhang 3958

wie man sieht problemlos :D

Eben das verwirrt mich bei dir scheint es immer zu gehen.. bei mir wenn ich das so mach nur sehr selten... eben wegen dem unterschiedlichen routing...
vll is mein pc im vergleich zum server zu schnell... zumindest wär das für mich das plausibelste...
mein pc: I7
Server: Celeron

Hmm...

ich denke das liegt daran dass du unterschiedliche protokolle mischts

mein rechner ist auch net grad lahm ( 2 mal Intel Xeon Quadcore Server CPUs )

Gutes Tutorial, aber die Software ist so überflüssig wie ein Kropf!

Aha? nunja... dann präzisier doch bitte WARUM das denn so ist deiner meinung nach.. evtl dass ANDERE dass auch evtl nachvollziehen können.

ohne eine Begründung ist das hier nämlich Spam und müsste gelöscht werden...

jo werde mir das mal draufhauen

Also ich hab jetz noch ne weile damit rumexperimentiert und hab rausgefunden dass sich das sperren aller ports ausser der benötigten nicht mit dem Flux verträgt.

bei dem kann man zwar eine Port-Range angeben, die aber offensichtlich nicht genutzt wird, da diese port Range auch in der FW freigeschalten ist und es trotzdem nicht funzt.
Irgendwie benutzt der flux bei mir scheinbar ALLE ports ausser die in der Port Range angegebenen !? Ich frag mich grad wo dann der Sinn dieser Port Range liegt...
:baffled:

Was ist wenn ich alles dicht mache außer den 80 Port

Die Mail Ports radio usw können die dann noch arbeiten.

funzt das radio dann noch?

ich geh mal davon aus das es dann nicht mehr geht bzw nicht mehr erreichbar ist

also muß man gut wählen was man dicht macht

das ist aber ein anderer fehler dann bei dir.
ich habe den flux local laufen gehabt ne ganze zeit, euf einem debian.
vpm router portforwart für 10 ports wielich nie mehr files zeitgleich haben wollte.
und es hat immer super gefunzt, er hat grundsätzlich nur die erlaubten ports vom ersten bis letzen genommen, alle weileren files waren dann firewalled wenn mal eines mehr da war.
Also ein allgemeiner fehler ist das nicht.

@Pullerman
ja du musst schoin genau wählen was du zu machst... ich hab das so gehandelt dass alles zu ist, und nur port 80 und IMMER offen ist...
und natürlich die Flux Ports, aber da das ja im moment niucht klappt musst ich das einstellen... der betrieb des fluxes ist erstmal wichtiger...

@Feudas
ich kann mir das auch nicht erklären... ich hab ne portrange von 49XXX - 50XXX aber nutzen tut er eigentlich hauptsächlich (also nicht ausschließlich, manchmal hängt er an EINEM Richtigen Port) Ports die NICHT in dieser Range sind.

dh. ich hab files an Port 23XXX hängen... die bei der Konf eigentlich zu wären.
Mir hat das den ganzen Flux lahmgelegt... logischerweise....

Mir kommt das so vor als ob der wahllos ports nimmt wie er gerade lustig ist.

hm
du hast doch im flux die ports stehen die er verwendet
25342-52341 oder so
dann lässte den bereich offen damit der flux arbeiten kann
wenn du iptables -A FORWARD -p tcp --dport 25342:52341 -j ACCEPT
und iptables -A FORWARD -p udp --dport 25342:52341 -j ACCEPT
müßte das doch gehen es sei denn knock blockt den port FORWARD

Klar hab ich das so gemacht... aber es geht nicht... die ports sind zwar frei, aber flux nimmt nicht die angegebene Port range... strange...

hab ich aber oben schon 2 mal erklärt wie das bei mir is....
davon abgesehen hat das eigentlich nicht wirklich mit knockd zu tun... ich glaub bissl off topic is das schon... wobei... vll wärs gut zu wissen für den der auch dieselbe idee hatte wie ich... alles sperren bis aufs nötige...

hm...
nunja. sehr seltsam find ick...

Knockd ist doch auch nicht dafür gedacht das du damit alle deine ports absichern sollst das ist doch nur ne art zusatz absicherung für ports die oft genutzt und somit auch angegriffen werden wie zb ssh port 22 oder ftp port 21 usw aber sicher nicht alle die kannst du ganz einfach dicht machen das langt vollkommen

Es war eigentlich auch nur geplant dass ich den ssh und den mail damit immer auf und zu machen kann...

flux unf http sollten immer offen sein... aber da hat der flux nicht mitgemacht...

Besser spät als nie.

Es ist meiner Meinung nach überflüssig weil:
- zusätzlicher Aufwand
- ein ordentlich abgesicherter sshd völlig reicht ( key-login, kein root, evtl. port verlegt)
- es ein zusätzlicher Dienst ist, welcher zusätzliche Sicherheitslücken haben könnte, und daher sollte die Anzahl laufender Dienste grundsätzlich auf ein minimum reduziert werden.

Klar sehe ich auch die positiven Dinge des Knockd wie:
- um überhaupt den sshd angreifen zu können muss man erstmal die Sequenz erraten.

Allerdings macht ein key-login das relativ überflüssig.
1024bit keys sind mit normalen mitteln erst mit mehreren hundert Jahren Zeitaufwand knackbar.
768bit rsa-Keys wurden jetzt wohl durch cryptoanalyse hinfällig. Bzw der erste 768bit key wurde geknackt wie ich lesen musste heute, allerdings sind 1024bit deutlich aufweniger. Und mit 4096 bit o.ä. wird ein knackbarkeit nahezu ausgeschlossen.


Allerdings möchte ich hiermit keinesfalls deine Anleitung schlecht mache Solstice. Nur finde ich sollte man sich immer über die Pros und Contras einer Software informieren.

SOWAS nenn ich doch mal ne Begründung zu ner Meinung...

Danke... mehr wollt ich eigentlich gar nicht... ich hasse nur sinnlose bemerkungen die dann niemandem helfen... weder in technischer noch in meinungsbildender hinsicht.

wobei ne aussage wie port verlegen auch nicht haltbar ist den port verlegen bringt gleich 0 einmal nen scanner laufen lassen und jeder weiß in 5 min welchen port du für was nutzt

Die aussage ist falsch auch falsch in den Medien verbreitet,
Es wurde eine zahl die 768bit verschlüsselt war durch gegen und kreuz und key berechnungen errechnet.
der aufwand dafür war aber ederart gross das man 768 rsa noch lang nicht als geknackt ansehen kann.
nicht mal 512er sind wirklich geknackt.
Klar wenn ich in eine bank einbrechen will dann ist der aufwand de rnötig ist vieleicht ok aber für normale webserver würde das niemand machen.
und zu allem sollte man bedenken da sman nur durch die änderung der länge eines verschlüsselten passwortes die berechenbarkeit in die milionen jahre zeiträume verschieben kann.

Mir bekannt. Hilft höchstens was gegen von bots gefloodete Logs.

Das nur eine 768-bit zahl in ihre Primzahlfaktoren zerlegt wurde hab ich mittlerweile auch gelesen.@feudas