[debian sarge] sshd dmv tcpwrapper draaien lukt niet

[Verwijderd]

Mijn probleem omdat ik het een beetje zat raak om elke dag 20 mailtjes te krijgen door scriptkiddies die door de voordeur proberen binnen te komen (brute force ssh inlog toestanden wie kent ze niet)
Heb ik besloten om het python script denyhosts te gaan draaien..

Dit leek me niet moeilijk maar ik heb een probleempje met het instellen van de tcpwrapper die ssh moet gaan draaien. Standaard doet het ssh pakketje wat ik dmv apt-get install ssh hebt geinstalleerd niet naar /etc/hosts.deny kijken. Na wat zoeken kwam ik erachter dat ik sshd moet opstarten met tcpd
al vermelden diverse bronnen dat ssh in debian al dmv een tcpwrapper draait misschien zit dit tegenwoordig toch anders in elkaar.

Nu heb ik de start entry van /etc/init.d/ssh aangepast naar dit:

start-stop-daemon --start --quiet --pidfile /var/run/sshd.pid --exec /usr/sbin/tcpd /usr/sbin/sshd -- $SSHD_OPTS

en ssh start wel op maar ik kan nu met geen mogelijkheid meer inloggen. blijft : ssh: connect to host 127.0.0.1 port 22: Connection refused
ook de start-stop-daemon verwijderen helt niet.

wie weet raad?

[Verwijderd]

Als eerste zou ik zelf nooit ssh draaien op poort 22 dit voorkomt al een hele hoop.
Waarom zou je een hostdeny gebruiken ipv direct in de firewall op te nemen.

[Verwijderd]

Nou mijn ssh server draait niet op de router / firewall. Ik zou iptables ook op de DMZ server kunnen draaien maar dit lijkt me onhandig. En ook wil ik niet dat ik zelf na een keer het verkeerde wachtwoord opgegeven te hebben zelf buiten gesloten worden.
En ik wil wel ssh services kunnen aanbieden vanaf mijn server naar meerdere ip's. Ook gebeurd het nog wel eens dat ik vanaf een 'nieuw' ip adress moet inloggen dus ik wil ssh wel open houden en niet alleen toestaan vanaf van te voren vast gestelde ip adressen.
Sshd niet op poort 22 draaien scheelt vast een hoop. Maar doet natuurlijk niet voorkomen dat ik nog steeds gebruut forced kan worden.

denyhosts is volgens mij de beste optie op dit moment

[ Voor 13% gewijzigd door Verwijderd op 16-08-2005 23:19 ]

[Verwijderd]

De sshd die je met apt-get installed kijkt standaard al naar /etc/hosts.allow en /etc/hosts.deny.

Vroeger moest je beide files gebruiken, tegenwoordig volstaat /etc/hosts.allow.

Zet je init script eens terug en zet bijvoorbeeld dit in /etc/hosts.allow:

code:

sshd : lief.ip.hier : allow
all : nog.een.lief.ip.hier : allow

exim : all : allow
snmpd : all : allow

all : LOCAL : allow
all : all : deny

Een restart van sshd is niet nodig.

[ Voor 3% gewijzigd door Verwijderd op 16-08-2005 23:21 ]

[UltraSub]

Verwijderd schreef op dinsdag 16 augustus 2005 @ 23:11:
Als eerste zou ik zelf nooit ssh draaien op poort 22 dit voorkomt al een hele hoop.
Waarom zou je een hostdeny gebruiken ipv direct in de firewall op te nemen.

Draai hier ook op een hoge poort. Bijna nooit meldingen in de log. Om niet te zeggen nooit.

[Verwijderd]

oeps zo te zien ligt m'n ssh server plat nu... nou morgen verder dan als ik weer op locatie ben

die hosts.allow heb ik niet geprobeerd. wat niet iig werkte was een all: 127.0.0.1 in host.deny te zetten. Kon nog vrolijk door blijven connecten naar localhost.

edit: bah cant bind to adress 0.0.0.0 port 22 zegt logcheck. kennelijk een sshd instantie blijven draaien.

[ Voor 21% gewijzigd door Verwijderd op 17-08-2005 00:46 ]

[Verwijderd]

Verwijderd schreef op dinsdag 16 augustus 2005 @ 23:19:
De sshd die je met apt-get installed kijkt standaard al naar /etc/hosts.allow en /etc/hosts.deny.

Vroeger moest je beide files gebruiken, tegenwoordig volstaat /etc/hosts.allow.

Zet je init script eens terug en zet bijvoorbeeld dit in /etc/hosts.allow:

code:

sshd : lief.ip.hier : allow
all : nog.een.lief.ip.hier : allow

exim : all : allow
snmpd : all : allow

all : LOCAL : allow
all : all : deny

Een restart van sshd is niet nodig.

Om een of andere reden werkt dit niet. Kan vrolijk overal vandaan blijven ssh-en..
Mijn sshd server is OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004

Weet iemand raad?

[deadinspace]

Verwijderd schreef op woensdag 17 augustus 2005 @ 21:46:
Om een of andere reden werkt dit niet. Kan vrolijk overal vandaan blijven ssh-en..

"ALL" is een wildcard die "alles" betekent, 'all' is niks. Daar had je zelf ook achter kunnen komen als je in de manpage had gekeken

In plaats van met tcpwrapper is dit trouwens ook te doen met de juiste firewall rules.

[Verwijderd]

ja ik had het natuurlijk niet letterlijk overgenomen he.. het principe werkt niet bedoel ik.
welke syntax ik probeer sshd negeerd mijn host.* filetjes.

En de handleiding van sshd heeft het er ook niet over. maar toch lees ik op diverse plekken dat de sshd van debian dit zou moeten doen.. dus vandaar.

edit: en ik wil deze adressen blijvend blokken op mijn dmz server m'n firewall draait op een andere bak. zoals hier boven al vermeld staat. waarom zou ik m'n server continu belasten als het via sshd zou kunnen?

[ Voor 28% gewijzigd door Verwijderd op 18-08-2005 01:51 ]

[Verwijderd]

deadinspace schreef op donderdag 18 augustus 2005 @ 00:48:
[...]

"ALL" is een wildcard die "alles" betekent, 'all' is niks. Daar had je zelf ook achter kunnen komen als je in de manpage had gekeken

In plaats van met tcpwrapper is dit trouwens ook te doen met de juiste firewall rules.

Idd, mijn fout, helemaal vergeten.
Ik heb het zo uit mijn hoofd getypt, niet bedenkende dat ALL iets anders dan all is.

[Verwijderd]

Nou heb ik de ballen verstand van Debian aangezien mijn distro of choice Slackware is vandaar ook dat ik vaak compileer vanaf source en me van het configure script van openSSH de optie --with-tcpwrappers herinneer.

code:

$ ./configure --help | more
...
--with-tcp-wrappers[=PATH] Enable tcpwrappers support (optionally in PATH)
...

Zou dit het kunnen zijn of doet Debian dit soort dingen "automatisch" in zijn binaries? Je zou kunnen proberen om zelf een openSSH installatie vanaf source te doen met de betreffende optie.

[ Voor 5% gewijzigd door Verwijderd op 18-08-2005 09:51 ]

[deadinspace]

Verwijderd schreef op donderdag 18 augustus 2005 @ 01:47:
ja ik had het natuurlijk niet letterlijk overgenomen he.. het principe werkt niet bedoel ik.
welke syntax ik probeer sshd negeerd mijn host.* filetjes.

Het is wel handiger als je het letterlijk overneemt, om zulk soort misverstanden te voorkomen

Als ik in mijn /etc/hosts.allow het volgende zet:

code:

sshd: 192.168.0.184: allow
ALL: ALL: deny

Dan kan alleen nog mijn laptop ssh-en naar die computer. Werkt prima op Sarge. Neem deze config eens letterlijk over (met een ander IP weliswaar)? Lukt het daarmee?

edit: en ik wil deze adressen blijvend blokken op mijn dmz server m'n firewall draait op een andere bak. zoals hier boven al vermeld staat. waarom zou ik m'n server continu belasten als het via sshd zou kunnen?

Omdat tcpwrappers net zo goed een belasting vormt. Alle tcpwrapper-enabled applicaties moeten namelijk bij elke connectie die configuratie-files parsen. Ik hou het niet voor onmogelijk dat een firewall met de juiste rules lichter is, maar waarschijnlijk is het qua performance lood om oud ijzer.

Verwijderd schreef op donderdag 18 augustus 2005 @ 09:44:
Nou heb ik de ballen verstand van Debian aangezien mijn distro of choice Slackware is vandaar ook dat ik vaak compileer vanaf source en me van het configure script van openSSH de optie --with-tcpwrappers herinneer.
...
Zou dit het kunnen zijn of doet Debian dit soort dingen "automatisch" in zijn binaries? Je zou kunnen proberen om zelf een openSSH installatie vanaf source te doen met de betreffende optie.

Debians sshd is gecompiled met --with-tcpwrappers, er is geen reden om hem van source te gaan lopen compilen

[Verwijderd]

deadinspace schreef op donderdag 18 augustus 2005 @ 12:59:
[...]

Het is wel handiger als je het letterlijk overneemt, om zulk soort misverstanden te voorkomen

Als ik in mijn /etc/hosts.allow het volgende zet:

code:

sshd: 192.168.0.184: allow
ALL: ALL: deny

Dan kan alleen nog mijn laptop ssh-en naar die computer. Werkt prima op Sarge. Neem deze config eens letterlijk over (met een ander IP weliswaar)? Lukt het daarmee?

Nee mijn ssh is nog steeds vanaf elk ip adres bereikbaar. Als ik dit in /etc/hosts.allow zet krijg ik wel de volgende foutmelding in m'n /var/log/auth.log:

Aug 18 17:40:24 fortfiles sshd[19678]: warning: /etc/hosts.allow, line 14: missing newline or line too long

Dus de file wordt niet volkomen genegeerd maar deze syntax zou toch moeten werken?
Het lijkt er op dat /etc/hosts.deny wel genegeerd wordt.. met die file krijg ik het zelfs niet voorelkaar om een fout melding te genereren.

edit: regel 14 is trouwens de ALL: ALL: deny regel
edit2: aha.. lijkt er op dat tie het niet leuk vond dat de file niet eindigde met een lege regel. Het werkt nu wel. (zoals de foutmelding ook meldt )

begrijp ik het goed dat /etc/hosts.deny niet gebruikt wordt door de tcpwrapper?

[ Voor 14% gewijzigd door Verwijderd op 18-08-2005 17:48 ]

[deadinspace]

Verwijderd schreef op donderdag 18 augustus 2005 @ 17:43:
edit2: aha.. lijkt er op dat tie het niet leuk vond dat de file niet eindigde met een lege regel. Het werkt nu wel. (zoals de foutmelding ook meldt )

Even mierenneuken: het is niet zo dat de file niet met een lege regel eindigde, maar de laatste regel was niet afgesloten met een newline character (ok, het is een kwestie van interpretatie, maar dit is de interpretatie die gangbaar is onder Unices)

In Unices is het de gewoonte elke regel af te sluiten met een newline character, dus ook de laatste regel in een file. De meeste editors doen dit automatisch, maar sommige editors doen foei (joe bijvoorbeeld). Als je zo'n editor gebruikt is het een goed idee om uit te zoeken hoe je dit gedrag alsnog kunt instellen, of om je anders aan te leren het zelf te doen. Anders voorspel ik dat je dergelijke verschijnselen vaker gaat krijgen (cron is hier bijvoorbeeld ook kieskeurig in).

begrijp ik het goed dat /etc/hosts.deny niet gebruikt wordt door de tcpwrapper?

Zoals ik de manpage begreep wordt die wel gebruikt. Lees de manpage zelf ook eens

[Verwijderd]

deadinspace schreef op vrijdag 19 augustus 2005 @ 00:42:
[...]

Even mierenneuken: het is niet zo dat de file niet met een lege regel eindigde, maar de laatste regel was niet afgesloten met een newline character (ok, het is een kwestie van interpretatie, maar dit is de interpretatie die gangbaar is onder Unices)

Nee sorry voor het misverstand. Moet heel erg nauwkeurug zijn idd anders loopt het in het honderd.

In Unices is het de gewoonte elke regel af te sluiten met een newline character, dus ook de laatste regel in een file. De meeste editors doen dit automatisch, maar sommige editors doen foei (joe bijvoorbeeld). Als je zo'n editor gebruikt is het een goed idee om uit te zoeken hoe je dit gedrag alsnog kunt instellen, of om je anders aan te leren het zelf te doen. Anders voorspel ik dat je dergelijke verschijnselen vaker gaat krijgen (cron is hier bijvoorbeeld ook kieskeurig in).

Meestal gebruik ik mcedit. en anders is het vi dus daarom had ik de regel niet afgesloten.

[...]

Zoals ik de manpage begreep wordt die wel gebruikt. Lees de manpage zelf ook eens

De man page van tcpwrapper die is wel duidelijk. Maar omdat het hier sshd betreft weet ik toch niet of die de /etc/hosts.allow file meeneent. Het lijkt er iig op dat die dit niet doet. En in de manpage van sshd kom ik het helemaal niet tegen vandaar dus.
Weer een foutje van mijn kant. Het is dus sshd en niet tcpwrapper. (al is het een combi natuurlijk)

[deadinspace]

De man page van tcpwrapper die is wel duidelijk. Maar omdat het hier sshd betreft weet ik toch niet of die de /etc/hosts.allow file meeneent. Het lijkt er iig op dat die dit niet doet. En in de manpage van sshd kom ik het helemaal niet tegen vandaar dus.
Weer een foutje van mijn kant. Het is dus sshd en niet tcpwrapper. (al is het een combi natuurlijk)

tcpwrapper is de library die /etc/hosts.allow en /etc/hosts.deny leest. sshd maakt gebruik van deze library. Dat houdt dus in dat sshd zowel /etc/hosts.allow als /etc/hosts.deny respecteert

Zet maar eens

code:

sshd: 192.168.0.8

of iets dergelijks in /etc/hosts.deny.