Veiligheidsdiscussie Debian(based) Server

[HTT-Thalan]

Ik ben in een leuke discussie terecht gekomen nadat ik wat kleine vragen had gesteld op het Debian forum, naar aanleiding van een server die ik heb geinstalleerd thuis.

In deze guide heb ik wat interessante kennis opgedaan over de do's en don't van serverbeveiliging, en ben nu een aantal van die zaken aan het implementeren op een testservertje thuis. Dit omdat ik eerder een LAMP server bouwde die binnen 2 weken zoveel ongewenst verkeer genereerde dat mijn internetverbinding (in het vorige huis gelukkig, ik heb nu een nieuw extern IP) eronder bezweek.

Ik ga dus alsnog een Linux server gebruiken, maar dit keer pas online beschikbaar maken als ik wat beter bekend ben met de juiste technieken om het de beginnende hacker/scriptkiddie onmogelijk te maken iets uit te spoken. Niet omdat de server zo belangrijk is (hij komt in een DMZ en gaat alleen maar webcam plaatjes uitspugen zodat ik onze parkeerplaatsen remote in de gaten kan houden) maar omdat ik op die manier mijn bestaande linux-kennis een beetje uitbreid.


Wat nu vooral een twijfelpunt is bij mij, is het al dan niet toestaan van root-toegang via SSH.
Alhoewel de server op mijn studiekamer staat, en ik er thuis gewoon bij kan, gebruik ik dat TFT scherm liever ergens anders voor en wil ik sowieso uit huis ook toegang hebben. Omdat ik geen GUI nodig heb verval ik dus automatisch in SSH.

De case voor root-toegang:

- men moet niet één, maar twéé wachtwoorden raden voor ze toegang hebben
- je gebruikt geen sudo maar gewoon SU wanneer nodig en verder niet, (ik heb nog niet helemaal begrepen waarom het één superieur is aan het ander) zoals het 'hoort'

(ik heb overigens gemerkt dat er best wel veel zaken SUDO vereisen, vanwege het verschil in PATH variabelen tussen admin en non-admin users)

De case tegen root-toegang:

- men hoeft alleen een root-wachtwoord te raden, in plaats van een username én een wachtwoord
- iemand die een rootkit of andere vorm van toegang weet te plaatsen heeft via SSH onbeperkte toegang, in plaats van beperkte rechten onder mijn useraccount (alhoewel, als hij mijn WW heeft komt hij met SUDO net zo ver)

Waarschijnlijk kunnen jullie de lijst met pro's en cons nog verder aanvullen.


Verder heb ik gelezen over de mogelijkheid om applicaties te 'jailen', maar dit is nog veel te gecompliceerd voor mij en streeft het doel té ver voorbij. Ik ga het voorlopig doen met:

- het zgn. 'hardening' van het OS en de gebruikte applicaties (bv Apache)
- overbodige services, users, groups en evt. open poorten handmatig verwijderen
- een software firewall gebruiken (hij komt immers buiten het normale netwerk en dus niet achter mijn IDS firewall te hangen)
- SSH over een willekeurige, niet standaard poort gebruiken
- wellicht RSA keys gebruiken of een andere manier van identificatie zodat alleen mijn laptop er extern bij moet kunnen

Ik twijfel nog over een rootkithunter (heeft dat zin?) en over de zin of onzin van zaken zoals automatische signalering naar mij bij activiteit en dergelijke. Nogmaals, de server en diens taken zijn compleet ondergeschikt, maar ik wil gaandeweg wel (laten) testen in hoeverre ik het systeem nu ontmoedigend genoeg heb gemaakt (waterdicht is natuurlijk een utopie, zeker met mijn beperkte kennis).

Ik zou zeggen, laat u horen!

[Jaap-Jan]

In ieder geval één reden om PermitRootLogin uit te zetten:

gandalf:/var/log# grep "Failed password for" auth.log | grep sshd
Jan 22 13:15:30 gandalf sshd[18176]: Failed password for root from 140.109.22.74 port 43901 ssh2
Jan 22 13:15:34 gandalf sshd[18179]: Failed password for root from 140.109.22.74 port 44244 ssh2
Jan 22 13:15:38 gandalf sshd[18183]: Failed password for root from 140.109.22.74 port 44560 ssh2
Jan 22 13:15:42 gandalf sshd[18185]: Failed password for root from 140.109.22.74 port 44921 ssh2
Jan 22 13:15:47 gandalf sshd[18187]: Failed password for root from 140.109.22.74 port 45251 ssh2
Jan 22 13:15:51 gandalf sshd[18189]: Failed password for root from 140.109.22.74 port 45571 ssh2
(..)
Jan 23 19:00:40 gandalf sshd[26628]: Failed password for root from 218.108.85.243 port 41322 ssh2
Jan 23 19:31:53 gandalf sshd[27046]: Failed password for root from 218.108.85.243 port 44300 ssh2
Jan 23 19:31:59 gandalf sshd[27049]: Failed password for root from 218.108.85.243 port 45710 ssh2
Jan 23 19:32:06 gandalf sshd[27051]: Failed password for root from 218.108.85.243 port 46624 ssh2
Jan 23 19:32:14 gandalf sshd[27054]: Failed password for root from 218.108.85.243 port 47880 ssh2
Jan 23 19:32:22 gandalf sshd[27057]: Failed password for root from 218.108.85.243 port 49057 ssh2
Jan 23 19:32:27 gandalf sshd[27060]: Failed password for root from 218.108.85.243 port 50398 ssh2
Jan 23 21:12:05 gandalf sshd[28464]: Failed password for root from 61.84.99.106 port 1872 ssh2
Jan 23 21:12:07 gandalf sshd[28464]: Failed password for root from 61.84.99.106 port 1872 ssh2
Jan 23 21:12:09 gandalf sshd[28464]: Failed password for root from 61.84.99.106 port 1872 ssh2
Jan 23 21:12:12 gandalf sshd[28464]: Failed password for root from 61.84.99.106 port 1872 ssh2
Jan 23 21:12:14 gandalf sshd[28464]: Failed password for root from 61.84.99.106 port 1872 ssh2
Jan 23 21:12:16 gandalf sshd[28464]: Failed password for root from 61.84.99.106 port 1872 ssh2
Jan 23 21:22:33 gandalf sshd[28616]: Failed password for root from 61.84.99.106 port 1514 ssh2
Jan 23 21:22:35 gandalf sshd[28616]: Failed password for root from 61.84.99.106 port 1514 ssh2
Jan 23 21:22:38 gandalf sshd[28616]: Failed password for root from 61.84.99.106 port 1514 ssh2
Jan 23 21:22:40 gandalf sshd[28616]: Failed password for root from 61.84.99.106 port 1514 ssh2
Jan 23 21:22:42 gandalf sshd[28616]: Failed password for root from 61.84.99.106 port 1514 ssh2
Jan 23 21:22:44 gandalf sshd[28616]: Failed password for root from 61.84.99.106 port 1514 ssh2
Jan 23 21:34:17 gandalf sshd[28777]: Failed password for root from 61.84.99.106 port 4626 ssh2
Jan 23 21:34:19 gandalf sshd[28777]: Failed password for root from 61.84.99.106 port 4626 ssh2
Jan 23 21:34:21 gandalf sshd[28777]: Failed password for root from 61.84.99.106 port 4626 ssh2
Jan 23 21:34:24 gandalf sshd[28777]: Failed password for root from 61.84.99.106 port 4626 ssh2
Jan 23 21:34:26 gandalf sshd[28777]: Failed password for root from 61.84.99.106 port 4626 ssh2
Jan 23 21:34:28 gandalf sshd[28777]: Failed password for root from 61.84.99.106 port 4626 ssh2
Jan 24 07:35:10 gandalf sshd[5457]: Failed password for root from 218.108.85.243 port 44771 ssh2
Jan 24 07:35:17 gandalf sshd[5460]: Failed password for root from 218.108.85.243 port 45455 ssh2
Jan 24 07:35:22 gandalf sshd[5463]: Failed password for root from 218.108.85.243 port 46298 ssh2
Jan 24 07:35:28 gandalf sshd[5465]: Failed password for root from 218.108.85.243 port 46891 ssh2
Jan 24 07:35:33 gandalf sshd[5469]: Failed password for root from 218.108.85.243 port 47530 ssh2
Jan 24 07:35:46 gandalf sshd[5472]: Failed password for root from 218.108.85.243 port 48226 ssh2
Jan 24 09:15:42 gandalf sshd[6836]: Failed password for invalid user ____ from 92.84.22.104 port 38621 ssh2
Jan 24 09:15:52 gandalf sshd[6838]: Failed password for root from 92.84.22.104 port 39258 ssh2
Jan 24 14:49:28 gandalf sshd[11303]: Failed password for root from 117.21.248.137 port 54825 ssh2
Jan 24 21:49:22 gandalf sshd[18430]: Failed password for root from 210.245.81.213 port 45091 ssh2
Jan 24 21:49:30 gandalf sshd[18432]: Failed password for root from 210.245.81.213 port 45304 ssh2
Jan 24 21:49:35 gandalf sshd[18435]: Failed password for bin from 210.245.81.213 port 45601 ssh2
Jan 24 21:49:39 gandalf sshd[18438]: Failed password for bin from 210.245.81.213 port 45784 ssh2
Jan 24 21:49:47 gandalf sshd[18440]: Failed password for bin from 210.245.81.213 port 45953 ssh2
Jan 24 21:49:55 gandalf sshd[18444]: Failed password for bin from 210.245.81.213 port 46251 ssh2
Jan 25 12:55:34 gandalf sshd[31348]: Failed password for root from 117.21.248.137 port 60387 ssh2
Jan 25 13:24:28 gandalf sshd[31731]: Failed password for root from 91.205.189.27 port 56369 ssh2
Jan 25 13:24:30 gandalf sshd[31733]: Failed password for root from 91.205.189.27 port 56817 ssh2
Jan 25 13:24:33 gandalf sshd[31737]: Failed password for nobody from 91.205.189.27 port 57250 ssh2
Jan 25 13:24:35 gandalf sshd[31740]: Failed password for nobody from 91.205.189.27 port 57624 ssh2
Jan 25 13:24:38 gandalf sshd[31742]: Failed password for nobody from 91.205.189.27 port 57988 ssh2
Jan 25 13:24:41 gandalf sshd[31744]: Failed password for invalid user adm from 91.205.189.27 port 58382 ssh2
Jan 25 23:14:56 gandalf sshd[7426]: Failed password for root from 61.184.101.46 port 52673 ssh2
Jan 25 23:15:01 gandalf sshd[7429]: Failed password for root from 61.184.101.46 port 52898 ssh2
Jan 25 23:15:06 gandalf sshd[7460]: Failed password for root from 61.184.101.46 port 53172 ssh2
Jan 25 23:15:11 gandalf sshd[7462]: Failed password for root from 61.184.101.46 port 53412 ssh2
Jan 25 23:15:15 gandalf sshd[7465]: Failed password for root from 61.184.101.46 port 53663 ssh2
Jan 25 23:15:20 gandalf sshd[7467]: Failed password for root from 61.184.101.46 port 53901 ssh2
Jan 27 03:53:35 gandalf sshd[31833]: Failed password for root from 115.68.55.224 port 34848 ssh2
Jan 27 03:53:40 gandalf sshd[31835]: Failed password for root from 115.68.55.224 port 35225 ssh2
Jan 27 03:53:45 gandalf sshd[31837]: Failed password for root from 115.68.55.224 port 35553 ssh2
Jan 27 03:53:50 gandalf sshd[31843]: Failed password for root from 115.68.55.224 port 35961 ssh2
Jan 27 03:53:54 gandalf sshd[31845]: Failed password for root from 115.68.55.224 port 36341 ssh2
Jan 27 03:53:59 gandalf sshd[31847]: Failed password for root from 115.68.55.224 port 36710 ssh2
Jan 27 05:14:21 gandalf sshd[454]: Failed password for root from 125.133.120.52 port 34929 ssh2
Jan 27 05:14:26 gandalf sshd[458]: Failed password for root from 125.133.120.52 port 38287 ssh2
Jan 27 05:14:30 gandalf sshd[460]: Failed password for root from 125.133.120.52 port 41157 ssh2
Jan 27 05:14:34 gandalf sshd[462]: Failed password for root from 125.133.120.52 port 44716 ssh2
Jan 27 05:14:39 gandalf sshd[464]: Failed password for root from 125.133.120.52 port 46778 ssh2
Jan 27 05:14:44 gandalf sshd[467]: Failed password for root from 125.133.120.52 port 50635 ssh2

Ik heb hier één entry uitgehaald, waarbij ik een foutief wachtwoord had getypt.

En dit zouden er nog meer kunnen zijn, want gelukkig doet fail2ban zijn werk goed.

[ Voor 56% gewijzigd door Jaap-Jan op 27-01-2012 10:47 ]

[Kanarie]

Je wilt remote root login in principe uitzetten. De combinatie van username en wachtwoord zorgt voor de veiligheid. Je moet de combinatie van beiden goed hebben om toegang te krijgen tot de server.
Maar met remote root aan is de eerste helft van deze beveiliging al weg. Als je per se van buitenaf met root in de server moet kun je sshd zo instellen dat remote root alleen mag met een certificate.

Het uitzetten of deinstalleren van services die je niet gebruikt is ook verstandig, draai van buitenaf bijvoorbeeld eens een nmap op je server om te zien of er iets tussenzit wat je niet gebruikt. Ook houd je natuurlijk alle packages netjes up to date met de laatste beveiligingsupdates.

Verder vind ik het handig om een daemon als fail2ban of denyhosts te installeren die je logfile in de gaten houdt voor falende logins. Bij teveel login failures wordt een IP adres geblokkeerd.

[webfreakz.nl]

1. SSHD op een andere port draaien dan 22
2. http://www.cyberciti.biz/ lezen

[ Voor 42% gewijzigd door webfreakz.nl op 27-01-2012 10:51 ]

[Thralas]

HTT-Thalan schreef op vrijdag 27 januari 2012 @ 10:28:
- men moet niet één, maar twéé wachtwoorden raden voor ze toegang hebben

Dan verdubbel je de complexiteit van je rootwachtwoord. Dat is theoretisch nog effectiever dan twee losse wachtwoorden.

- je gebruikt geen sudo maar gewoon SU wanneer nodig en verder niet, (ik heb nog niet helemaal begrepen waarom het één superieur is aan het ander) zoals het 'hoort'

Hangt helemaal van je use case af, maar je suggereert het zelf al; in veel gevallen heb je commandlinetoegang enkel nodig voor administratieve doeleinden, niet zozeer voor dagelijks gebruik. Dan is het inderdaad onhandig om telkens te moeten su(doen).

- men hoeft alleen een root-wachtwoord te raden, in plaats van een username én een wachtwoord

Een username is in principe geen geheim en in 95% van de gevallen makkelijk te raden adhv. nickname of echte naam. Ook hier geldt weer, de complexiteit van je wachtwoord verdubbelen is nuttiger.

- iemand die een rootkit of andere vorm van toegang weet te plaatsen heeft via SSH onbeperkte toegang, in plaats van beperkte rechten onder mijn useraccount (alhoewel, als hij mijn WW heeft komt hij met SUDO net zo ver)

Het schip is gezonken zodra iemand roottoegang heeft, je SSH config kan 'ie immers aanpassen (of gewoon een 'simpele' shellsessie over TCP leggen).

- een software firewall gebruiken (hij komt immers buiten het normale netwerk en dus niet achter mijn IDS firewall te hangen)

Tenzij het alsnog niet zou beschermen tegen een aanvaller vanaf 't LAN zou ik gewoon je bestaande firewall/IDS proberen in te zetten. Het is handiger te managen als alles centraal staat, lijkt me.

- SSH over een willekeurige, niet standaard poort gebruiken

Dat is enkel security through obscurity, tenzij de failed logins in je auth log echt zo bezwaarlijk zijn.

- wellicht RSA keys gebruiken of een andere manier van identificatie zodat alleen mijn laptop er extern bij moet kunnen

Haal dat wellicht maar weg. Doen! Disable vervolgens password authentication en je hoeft je geen enkele zorgen meer te maken over de hordes aan zombies die toch proberen in te loggen.

Indien mogelijk zou ik SSH wel firewallen, maar het ligt er maar net aan van welke locaties je wilt in kunnen loggen en of je client IPs static zijn.

Ik twijfel nog over een rootkithunter (heeft dat zin?) en over de zin of onzin van zaken zoals automatische signalering naar mij bij activiteit en dergelijke. Nogmaals, de server en diens taken zijn compleet ondergeschikt, maar ik wil gaandeweg wel (laten) testen in hoeverre ik het systeem nu ontmoedigend genoeg heb gemaakt (waterdicht is natuurlijk een utopie, zeker met mijn beperkte kennis).

In theorie is rootkithunter nutteloos zodra je compromised bent (de perfecte aanvaller kan rootkithunter immers ook om de tuin leiden), maar in de praktijk is er een redelijke kans dat 'ie iets vind.

[lordgandalf]

Voor ssh heeft mijn server een port knocking systeem.
Hiermee is de poort niet te vinden behalve in de tijd dat ik mijn port knock heb gedaan en dan alleen voor mijn bron ip.
Dus geen gezeik met scriptkiddies enz.
Moet alleen nog eens keys gaan installeren zodat ik dat wachtwoord kan laten vervallen dan is alleen de portknock pass (en dat is zelfs met pgp op te lossen

[Verwijderd]

Gewoon vertrouwen op de complexiteit van je wachtwoord. De rest is voornamelijk extra gedoe.

De enige reden om alternatieve poorten of port knocking te gebruiken is om je logs een beetje schoon te houden. Ik doe die moeite niet, dat kan ook met grep.

Toegang via RSA key is technisch niet veel anders dan een belachelijk moeilijk wachtwoord. Ik vind Kerberos fijner omdat de daadwerkelijke authenticatie niet per se plaatsvindt op dezelfde host/service.

[HTT-Thalan]

lordgandalf schreef op vrijdag 27 januari 2012 @ 19:20:
Voor ssh heeft mijn server een port knocking systeem.
Hiermee is de poort niet te vinden behalve in de tijd dat ik mijn port knock heb gedaan en dan alleen voor mijn bron ip.
Dus geen gezeik met scriptkiddies enz.
Moet alleen nog eens keys gaan installeren zodat ik dat wachtwoord kan laten vervallen dan is alleen de portknock pass (en dat is zelfs met pgp op te lossen

Maar dan heb je dus een fixed IP nodig op de externe locatie vanwaar je jouw server benadert?

[Rukapul]

Verwijderd schreef op vrijdag 27 januari 2012 @ 19:34:
Gewoon vertrouwen op de complexiteit van je wachtwoord. De rest is voornamelijk extra gedoe.

[...]

Toegang via RSA key is technisch niet veel anders dan een belachelijk moeilijk wachtwoord.

Precies.

Een potentiele reden om RSA te forceren door wachtwoorden te verbieden als beheerder is als er andere SSH-gebruikers op de machine zitten waar je potentieel twijfelt aan hun wachtwoordselectieskills.

Overigens schat ik de kans significant hoger in dat je nat gaat door een vulnerability in een van de services dan password guessing. Zelf bied ik vanuit huis drie services extern aan vanaf m'n Debian box: imap, http (voor webmail) en ssh. Die webserver draait in een afgegrendelde VM om die reden (kan alleen met IMAP op de fysieke server connecten). SSH wacht mogelijk binnenkort hetzelfde lot met een jumpbox. IMAP geloof ik eigenlijk wel en is me teveel werk voorlopig. Speel nog met het idee om de externe VMs een ander OS (BSD) te geven zodat ook OS vulnerabilities uit te sluiten, maar dat is redelijkerwijs overkill.

[HTT-Thalan]

Rukapul schreef op vrijdag 27 januari 2012 @ 20:07:
[...]

Precies.

Een potentiele reden om RSA te forceren door wachtwoorden te verbieden als beheerder is als er andere SSH-gebruikers op de machine zitten waar je potentieel twijfelt aan hun wachtwoordselectieskills.

Overigens schat ik de kans significant hoger in dat je nat gaat door een vulnerability in een van de services dan password guessing. Zelf bied ik vanuit huis drie services extern aan vanaf m'n Debian box: imap, http (voor webmail) en ssh. Die webserver draait in een afgegrendelde VM om die reden (kan alleen met IMAP op de fysieke server connecten). SSH wacht mogelijk binnenkort hetzelfde lot met een jumpbox. IMAP geloof ik eigenlijk wel en is me teveel werk voorlopig. Speel nog met het idee om de externe VMs een ander OS (BSD) te geven zodat ook OS vulnerabilities uit te sluiten, maar dat is redelijkerwijs overkill.

Hoe regelmatig worden er nog gaten gevonden in services zoals Apache en SSH?

[CyBeR]

Dat is voor SSH vrij zeldzaam inmiddels. Apache iets vaker maar ook niet noemenswaardig veel.

[Rukapul]

HTT-Thalan schreef op vrijdag 27 januari 2012 @ 21:10:
[...]


Hoe regelmatig worden er nog gaten gevonden in services zoals Apache en SSH?

Remote exploitable: vrijwel nooit in SSH. Probleem met Apache is niet zozeer Apache zelf, maar dat er nog een flinke berg andere software bij komt kijken zoals PHP, webapplicaties, etc.

[UltraSub]

- sshd op een hoge poort
- PermitRootLogin no
- geen sudo installeren

Klaar.

[ Voor 7% gewijzigd door UltraSub op 27-01-2012 21:29 ]

[CAPSLOCK2000]

Verwijderd schreef op vrijdag 27 januari 2012 @ 19:34:
Toegang via RSA key is technisch niet veel anders dan een belachelijk moeilijk wachtwoord.

Dat ben ik niet met je eens, er zijn een paar wezenlijke verschillen, waarvan het belangrijkste toch wel is dat als ik iemand mijn publieke key geef hij daar niks anders mee kan doen dan mij toegang geven tot zijn servers.

Veel mensen gebruiken overal hetzelfde wachtwoord. Dat is geen goed idee, maar het is nu eenmaal zo en je kan het bijna niet voorkomen. Als je zo dom bent om dat te doen dan betekent het dat iedere site jouw wachtwoord kent en daar in principe misbruik van kan maken. Met ssh-keys kan dat niet.

Wie mijn publiekesleutel onderschept of "steelt" kan daar niks mee. Mijn privesleutel verlaat mijn eigen computer nooit. Ik gebruik wel een wachtwoord om de privesleutel te unlocken, maar ook dat wachtwoord hoeft mijn computer nooit te verlaten.

Als je wel netjes overal een ander wachtwoord gebruikt krijg je het probleem dat je die wachtwoorden moet gaan onthouden. Dat lukt niet als je er veel hebt. Iedere keer opzoeken wordt ook snel vervelend als je iedere 10 minuten met een andere server verbindt.

Wanneer je met wachtwoorden werkt zal je altijd situaties hebben waarin je wachtwoorden moet communiceren. Op dat moment zijn ze makkelijk te onderscheppen. Verder moeten wachtwoorden worden opgeslagen op de server. Dat gebeurt tegenwoordig wel versleuteld maar er zitten flinke beperkingen aan die veiligheid. In veel gevallen kan het oorspronkelijke wachtwoord toch worden achterhaald.

Een wat geavanceerder voordeel is dat je doormiddel van keys en forced-commands programma's gedeeltelijke toegang kan geven tot andere systemen. Andere mogelijkheden bestaan wel maar zijn minder makkelijk of minder veilig.

[CyBeR]

CAPSLOCK2000 schreef op vrijdag 27 januari 2012 @ 22:08:
[...]


Dat ben ik niet met je eens, er zijn een paar wezenlijke verschillen, waarvan het belangrijkste toch wel is dat als ik iemand mijn publieke key geef hij daar niks anders mee kan doen dan mij toegang geven tot zijn servers.

Datzelfde geldt voor een serieuze salted password hash.

Wie mijn publiekesleutel onderschept of "steelt" kan daar niks mee. Mijn privesleutel verlaat mijn eigen computer nooit. Ik gebruik wel een wachtwoord om de privesleutel te unlocken, maar ook dat wachtwoord hoeft mijn computer nooit te verlaten.

En hier is waar wat Cheatah zegt om de hoek komt kijken: jouw wachtwoord en een private key zijn hetzelfde ding. Alleen jouw wachtwoord is kort en een private key belachelijk lang.

[Rukapul]

CAPSLOCK2000 schreef op vrijdag 27 januari 2012 @ 22:08:

Je meeste argumenten zijn niet in tegenspraak met het beweerde. Feitelijk stip je wat onuitgesproken maar wel geimpliceerde randvoorwaarden aan.

Als je je wachtwoordbeheertool gewoon een random 128/256bit key laat genereren per systeem dan is dat niet onveiliger dan een private key in vrijwel alle scenarios.

Private keys moeten ook net zo goed beheerd worden als shared secret keys.

Zolang je het identiteitsdeel van PKI niet gebruikt is er weinig magisch of onderscheidends aan public/private key methoden

[ Voor 19% gewijzigd door Rukapul op 27-01-2012 22:30 ]

[Verwijderd]

CAPSLOCK2000 schreef op vrijdag 27 januari 2012 @ 22:08:

Dat ben ik niet met je eens, er zijn een paar wezenlijke verschillen, waarvan het belangrijkste toch wel is dat als ik iemand mijn publieke key geef hij daar niks anders mee kan doen dan mij toegang geven tot zijn servers.

De public key is dan ook niet hetgeen je toegang geeft. Het is vergelijkbaar met een gehashte waarde van een wachtwoord in een database. Je gebruikt het ter referentie.

De private key is vergelijkbaar met een wachtwoord, als in: random setje bits.

Veel mensen gebruiken overal hetzelfde wachtwoord. Dat is geen goed idee, maar het is nu eenmaal zo en je kan het bijna niet voorkomen. Als je zo dom bent om dat te doen dan betekent het dat iedere site jouw wachtwoord kent en daar in principe misbruik van kan maken. Met ssh-keys kan dat niet.

Niet per se waar. De authenticatiemethode maakt ook uit, en als de server alleen de hash kent, en je gebruikt maakt van challenge-response is dat niet per se onveilig. Het principe is nog steeds dat jij iets "weet" wat een ander niet "weet", en dat je een methode hebt om dat te laten zien.

PKI authenticatie werkt op dezelfde manier, daarbij wordt ook verzocht iets te "signen" waarna het resultaat vergeleken kan worden met de public key.

Wie mijn publiekesleutel onderschept of "steelt" kan daar niks mee. Mijn privesleutel verlaat mijn eigen computer nooit. Ik gebruik wel een wachtwoord om de privesleutel te unlocken,

Daar heeft de server niets mee te maken. Dat zou net zo goed een random wachtwoord kunnen zijn uit een password manager waarvan je de wachtwoorden moet decrypten met een master password.

maar ook dat wachtwoord hoeft mijn computer nooit te verlaten.

Het master password van mijn browser / key chain / whatever ook niet

Als je wel netjes overal een ander wachtwoord gebruikt krijg je het probleem dat je die wachtwoorden moet gaan onthouden. Dat lukt niet als je er veel hebt. Iedere keer opzoeken wordt ook snel vervelend als je iedere 10 minuten met een andere server verbindt.

Dat is een aanname, er is niets dat je ervan weerhoudt met een client te verbinden die per host een wachtwoord onthoudt in een keyring die je moet decrypten met een master password.

Wanneer je met wachtwoorden werkt zal je altijd situaties hebben waarin je wachtwoorden moet communiceren. Op dat moment zijn ze makkelijk te onderscheppen.

Dat geldt voor private keys ook. De oplossing: encrypten, passphrase erover. Het principe is toepasbaar op wachtwoord en RSA key omdat het in principe allebei maar setjes random bits zijn.

Verder moeten wachtwoorden worden opgeslagen op de server. Dat gebeurt tegenwoordig wel versleuteld maar er zitten flinke beperkingen aan die veiligheid. In veel gevallen kan het oorspronkelijke wachtwoord toch worden achterhaald.

Dat is weer een aanname. Houd er rekening mee dat er ook authenticatiemechanismen zijn waarbij het originele wachtwoord nooit bekend is bij de server.

Een wat geavanceerder voordeel is dat je doormiddel van keys en forced-commands programma's gedeeltelijke toegang kan geven tot andere systemen. Andere mogelijkheden bestaan wel maar zijn minder makkelijk of minder veilig.

Dat voordeel is gemak, maar heeft an sich niets met veiligheid te maken. Je kunt een systeem zo configureren dat je sowieso niet meer kan dan iemand wil dat je kunt, los van authenticatiemethode. Het principe is net zo goed toepasbaar via bijvoorbeeld PAM en het gebruikte wachtwoord.

Ik vind dat je teveel denkt over de huidige implementatie(s), en te weinig over de achterliggende principes.
Wachtwoorden, RSA keys, het zijn slechts random bits.

[CAPSLOCK2000]

Ik had een lang antwoord op je post getikt, maar je laatste zin geeft het verschil tussen onze visies denk ik het beste weer:

Verwijderd schreef op vrijdag 27 januari 2012 @ 23:36:
Ik vind dat je teveel denkt over de huidige implementatie(s), en te weinig over de achterliggende principes.
Wachtwoorden, RSA keys, het zijn slechts random bits.

Waarop ik dan weer vind dat jij te veel nadenkt over de theoretische mogelijkheden en te weinig over de dagelijkse praktijk.

Hoewel ik vind dat keys op bepaalde punten echt fundamenteel veiliger zijn, ben ik het met je eens dat een goed geconfigureerd wachtwoord-systeem ook heel veilig kan zijn.

Ik zie echter te vaak dat dat het niet goed gaat. Hoeveel mensen gebruiken nu echt overal unieke wachtwoorden? Hoe vaak wordt er nog md5 gebruikt als hash? Hoeveel software is er nog die wachtwoorden clear-text opslaat?

Op m'n eigen systemen kan ik het nog een beetje in de gaten houden, maar ik moet ook verbinden met systemen die ik niet zelf beheer. Daarbij ben ik ook maar een inperfect mens dat lui is en fouten maakt. De kans op vervelende fouten is kleiner als je keys gebruikt.

[HTT-Thalan]

Jullie maken het mij wel erg lastig ik probeer adhv jullie argumenten de simpelste doch voldoende effectieve manier te bepalen om mijn server dicht te timmeren, maar ik word er nu alleen maar paranoia van .

[Rukapul]

Staat er toch wel voor de zaken relaterend aan SSH: ben je zelf de enige gebruiker en heb je wat vertrouwen in jezelf dan kun je zowel root login als wachtwoordlogin (met goede wachtwoorden) toestaan. Heb je ook nog andere gebruikers dan kun je met public/private keys veiligheid forceren. Daarnaast kunnen er praktische overwegingen zijn om public/private key toe te passen en/of extra maatregelen te nemen zoals fail2ban etc.

[Verwijderd]

CAPSLOCK2000 schreef op zaterdag 28 januari 2012 @ 01:49:
Ik had een lang antwoord op je post getikt, maar je laatste zin geeft het verschil tussen onze visies denk ik het beste weer:

[...]

Waarop ik dan weer vind dat jij te veel nadenkt over de theoretische mogelijkheden en te weinig over de dagelijkse praktijk.

Die theoretische mogelijkheden moet je in je achterhoofd houden om in te zien waar je veiligheid creëert en waar het slechts schijnveiligheid betreft. Ik zie in dit soort topics altijd teveel oplossingen voor niet-bestaande problemen. En sommige oplossingen verhogen de veiligheid niet gegarandeerd.

Als voorbeeld noem ik port knocking, dat niet gegarandeerd veiligheid toevoegt. De TCP packets kunnen namelijk worden afgevangen en daaruit kan de sequence worden afgeleid.

Hoewel ik vind dat keys op bepaalde punten echt fundamenteel veiliger zijn, ben ik het met je eens dat een goed geconfigureerd wachtwoord-systeem ook heel veilig kan zijn.

Ik zie echter te vaak dat dat het niet goed gaat. Hoeveel mensen gebruiken nu echt overal unieke wachtwoorden? Hoe vaak wordt er nog md5 gebruikt als hash? Hoeveel software is er nog die wachtwoorden clear-text opslaat?

Er wordt nog steeds veel gebruik gemaakt van md5 omdat het in veel gevallen prima is om md5 te gebruiken. Zo is bij Red Hat 5 en afgeleiden de standaard om md5 te gebruiken voor /etc/passwd. En dat wordt nog tot 2014 ondersteund en is niet zo onveilig op de manier waarop het gebruikt wordt.

Op m'n eigen systemen kan ik het nog een beetje in de gaten houden, maar ik moet ook verbinden met systemen die ik niet zelf beheer. Daarbij ben ik ook maar een inperfect mens dat lui is en fouten maakt. De kans op vervelende fouten is kleiner als je keys gebruikt.

Dat klopt nu, en dat heeft te maken met de huidige implementaties, daarin moet ik je gelijk geven.
Die implementaties zijn zo dat een wachtwoord uiteindelijk toch aan de server wordt doorgegeven en dat challenge-response niet de standaard is, en bij die keys is dat wel de standaard.

Overigens maak ik zelf gebruik van Kerberos, waardoor ik als ik thuis inlog op mijn Windows of Linux systemen, ik automatisch een ticket krijg om me mee te authenticeren bij andere systemen en/of services. Ik heb het werkend voor SSH, SMTP, IMAP, HTTP en CIFS, en het wordt ondersteund door Windows 7, PuTTY, WinSCP, Thunderbird en Firefox. In combinatie met SSL en/of VPN is het behoorlijk veilig. Het grootste gevaar zit hem in keylogging of het afkijken van mijn wachtwoord.

[Herko_ter_Horst]

"A little paranoia goes a long way."

Verder is de mate van (zinvolle) beveiliging gerelateerd aan de waarde van het beveiligde (en daarmee aan de waarschijnlijkheid dat men jou serieus probeert te hacken) en de kosten na een potentiële succesvolle hack.

Voor bescherming van een webcam-servertje waar jij alleen zelf een account hebt tegen scriptkiddies en gelegenheidshackers zijn de genoemde maatregelen (op een andere poort draaien tegen logvervuiling, root access uitzetten en/of een fatsoenlijk wachtwoord gebruiken voor alle accounts) ruim voldoende.

[HTT-Thalan]

Rukapul schreef op zaterdag 28 januari 2012 @ 12:08:
Staat er toch wel voor de zaken relaterend aan SSH: ben je zelf de enige gebruiker en heb je wat vertrouwen in jezelf dan kun je zowel root login als wachtwoordlogin (met goede wachtwoorden) toestaan. Heb je ook nog andere gebruikers dan kun je met public/private keys veiligheid forceren. Daarnaast kunnen er praktische overwegingen zijn om public/private key toe te passen en/of extra maatregelen te nemen zoals fail2ban etc.

Wel, ik ben de enige user, maar hierboven heb ik een leuke screenshot gezien van een hacker/scriptkiddie die gewoon continue rootwachtwoorden aan het bruteforcen is. Op basis daarvan twijfel ik toch over het uitschakelen van root, maar dan heb ik SUDO wél nodig, terwijl iemand anders hier ook weer adviseert om SUDO in zijn geheel te verwijderen .

Dat Fail2Ban houd ik in mijn achterhoofd, maar RSA keys en dergelijke lijken nu nog even niet nodig op basis van mijn behoeftes.

[Herko_ter_Horst]

sudo is voor zover ik weet met name bedacht om te voorkomen dat mensen langere tijd als root ingelogd blijven. Je kunt het meeste werk gewoon doen met een gebruiker met beperkte rechten (zoals het hoort) en alleen waar het echt moet gebruik je sudo.

Omdat sudo beveiligt is met het wachtwoord van de gebruiker i.p.v. het root-wachtwoord en dat wachtwoord bovendien een tijdje onthouden wordt, is het een stuk vriendelijker (en veiliger) dan inloggen als root via su en dan of vergeten uit te loggen, of elke keer opnieuw het root-wachtwoord in te moeten tikken. Overigens: met su - krijg je de context van de gebruiker naar wie je su't, zonder - houdt je inderdaad je eigen context.

[HTT-Thalan]

Herko_ter_Horst schreef op zaterdag 28 januari 2012 @ 12:29:
sudo is voor zover ik weet met name bedacht om te voorkomen dat mensen langere tijd als root ingelogd blijven. Je kunt het meeste werk gewoon doen met een gebruiker met beperkte rechten (zoals het hoort) en alleen waar het echt moet gebruik je sudo.

Omdat sudo beveiligt is met het wachtwoord van de gebruiker i.p.v. het root-wachtwoord en dat wachtwoord bovendien een tijdje onthouden wordt, is het een stuk vriendelijker (en veiliger) dan inloggen als root via su en dan of vergeten uit te loggen, of elke keer opnieuw het root-wachtwoord in te moeten tikken. Overigens: met su - krijg je de context van de gebruiker naar wie je su't, zonder - houdt je inderdaad je eigen context.

Kun je me dat laatste nader uitleggen, wat bedoel je met context?

[Herko_ter_Horst]

Je had het er over dat je door het verschil in PATH variabelen tussen admin en non-admin users sudo moest gebruiken i.p.v. su. Dat komt omdat je su zonder - gebruikt en daarmee niet de environment van de andere gebruiker (root in dit geval) krijgt. Met su - krijg je een login shell voor de gebruiker naar wie je su't, waarin zaken als PATH wel "goed" staan.

[ Voor 8% gewijzigd door Herko_ter_Horst op 28-01-2012 12:40 ]

[nuance]

Interessant topic!
Ik heb volgens mij Two-factor authentication nog niet voorbij zien komen als mogelijke oplossing. Google-authenticator heeft een PAM-module voor linux die ik zelf ook gebruik i.c.m. SSH. Je gebruikt de app op je smartphone om een one time password te genereren die je naast je username en password moet invoeren. Mooie bescherming tegen keyloggers vanaf onveilige locaties.

[HTT-Thalan]

Herko_ter_Horst schreef op zaterdag 28 januari 2012 @ 12:39:
Je had het er over dat je door het verschil in PATH variabelen tussen admin en non-admin users sudo moest gebruiken i.p.v. su. Dat komt omdat je su zonder - gebruikt en daarmee niet de environment van de andere gebruiker (root in dit geval) krijgt. Met su - krijg je een login shell voor de gebruiker naar wie je su't, waarin zaken als PATH wel "goed" staan.

Ah, ik begrijp je. Nee, het is puur dat bijvoorbeeld IFCONFIG niet in mijn userpath staat, maar wel in het rootpath, maw, ik moet sudo gebruiken om IFCONFIG te kunnen starten, óf het complete path gebruiken op de command line: /sbin/ifconfig dus.

M.a.w., ik moet mijn path gaan uitbreiden zodat ik de zaken die ik standaard wil kunnen zonder SUDO kan uitvoeren.

[Herko_ter_Horst]

Ok, maar dat heeft niets te maken met wel of niet sudo gebruiken. Ook sudo zet niet magisch zaken op het path die daar normaal niet op staan. sudo gebruikt dan wel het path van root, waar /sbin inderdaad op staat, maar dat is een slechte reden om sudo te gebruiken.

[Verwijderd]

Even voor de duidelijkheid: er zijn tig redenen en manieren om sudo te gebruiken. Als je sudo gebruikt om elk mogelijk commando als root uit te kunnen voeren, dan is het maar zeer de vraag wat het aan veiligheid toevoegt.

De truc van sudo is de setuid bit, waardoor een commando als gebruiker "root" kan worden uitgevoerd. Er kunnen beperkingen worden opgelegd vanuit de sudoers configuratie. Ik vind persoonlijk dat zoveel mogelijk beperkt moet worden. Ik zie sudo het liefst in een rol waarin slechts enkele scripts mogen worden aangeroepen, om bijvoorbeeld mensen met minder permissies toch bepaalde beperkte taken te laten uitvoeren.

Op mijn eigen machines heb ik geen sudo. Mijn eigen user mag logs lezen omdat hij lid is van de groep adm, en mag lokaal wat dingen installeren omdat hij ook lid is van de groep staff.

Ik gebruik expres geen sudo omdat ik mezelf wil authenticeren als root, op het moment dat ik dat account nodig heb. Ik wil me niet kunnen authenticeren als mezelf, dan had ik inderdaad wel sudo of .k5users moeten gebruiken. Het is een bewuste keuze dat niet te doen.

nuance schreef op zaterdag 28 januari 2012 @ 12:41:
Interessant topic!
Ik heb volgens mij Two-factor authentication nog niet voorbij zien komen als mogelijke oplossing. Google-authenticator heeft een PAM-module voor linux die ik zelf ook gebruik i.c.m. SSH. Je gebruikt de app op je smartphone om een one time password te genereren die je naast je username en password moet invoeren. Mooie bescherming tegen keyloggers vanaf onveilige locaties.

Dat staat voor mij ook nog op het programma, maar ik wil dus wel dat dat met Kerberos werkt

[ Voor 21% gewijzigd door Verwijderd op 28-01-2012 13:06 ]

[peak]

Ik ben het met Cheatah eens.

Overigens, ik ben gaan rond zoeken wat de rechten van de groepen zoals adm, staff, operators zijn maar ik kan het niet vinden.

Aangezien jij weet dat de staff groep applicaties mag installeren, neem ik aan dat je een overzicht hebt van de default unix/linux groepen wat voor rechten ze hebben?

thanks

[HTT-Thalan]

Herko_ter_Horst schreef op zaterdag 28 januari 2012 @ 12:52:
Ok, maar dat heeft niets te maken met wel of niet sudo gebruiken. Ook sudo zet niet magisch zaken op het path die daar normaal niet op staan. sudo gebruikt dan wel het path van root, waar /sbin inderdaad op staat, maar dat is een slechte reden om sudo te gebruiken.

Dat klopt, dat had ik dus zelf ook al ondervonden, vandaar dat ik dus eerst een beetje in mijn path moet gaan knutselen, anders kan ik net zo goed permanent root zijn.

[Verwijderd]

peak schreef op zaterdag 28 januari 2012 @ 14:29:
Overigens, ik ben gaan rond zoeken wat de rechten van de groepen zoals adm, staff, operators zijn maar ik kan het niet vinden.

Aangezien jij weet dat de staff groep applicaties mag installeren, neem ik aan dat je een overzicht hebt van de default unix/linux groepen wat voor rechten ze hebben?

Hier is een redelijke beschrijving:
http://wiki.gacq.com/inde...system_groups_description

[ Voor 3% gewijzigd door Verwijderd op 28-01-2012 17:27 ]

[HTT-Thalan]

Nou, de nieuwe server draait . Oude Dell Optiplex desktop gepakt met minder geheugen (512mb) en een langzamere processor (2ghz) die heel erg stil was, dus dat heb ik nog stiller en zuiniger gemaakt door cdrom/hdd/fdd los te koppelen en een 8Gb Elitepro CF card in een convertor te gebruiken als primaire schijf.

Bare install gedaan, SSH geinstalleerd en daarna ook SUDO, maar alhoewel ik rootlogin heb uitgeschakeld (ik kan dus niet direct als root inloggen) heb ik gemerkt dat ik, eenmaal onder mijn eigen account ingelogd, wél naar root kan switchen met het SU commando.

Ik kan dus eigenlijk SUDO alsnog wel trashen?

[Verwijderd]

Inderdaad ja.

[CyBeR]

Waarom? Sudo is op zich niet nuttiger dan su als je er alleen een shell mee uitvoert, maar als je dat niet doet én je leert jezelf niet aan om overal sudo voor te zetten () is 't mijns insziens een beter idee dan su'en. En als je een machine hebt waarop ook anderen bepaalde commando's als root moeten uit kunnen voeren, zonder meteen die commando's setuid te maken (wat in zichzelf een slecht idee is qua security) kun je met sudo instellen wie, wat kan doen. Plus, voor sudo heb je geen root wachtwoord nodig maar alleen je eigen, wat in multi-user situaties een wachtwoordmanagementprobleem oplost.

Oh, ander voordeel: 'sudo command' maakt dat er een logmelding gemaakt wordt dat command met sudo is uitgevoerd als een bepaalde user, door een bepaalde user.

[ Voor 24% gewijzigd door CyBeR op 28-01-2012 18:54 ]

[HTT-Thalan]

CyBeR schreef op zaterdag 28 januari 2012 @ 18:35:
Waarom? Sudo is op zich niet nuttiger dan su als je er alleen een shell mee uitvoert, maar als je dat niet doet én je leert jezelf niet aan om overal sudo voor te zetten () is 't mijns insziens een beter idee dan su'en. En als je een machine hebt waarop ook anderen bepaalde commando's als root moeten uit kunnen voeren, zonder meteen die commando's setuid te maken (wat in zichzelf een slecht idee is qua security) kun je met sudo instellen wie, wat kan doen. Plus, voor sudo heb je geen root wachtwoord nodig maar alleen je eigen, wat in multi-user situaties een wachtwoordmanagementprobleem oplost.

Ik ben de enige user (en zal dat voorlopig ook blijven) en heb met wat hulp van deze tip het PATH algemeen gemaakt zodat ik als normale user toch de tools zoals IFCONFIG kan gebruiken zonder gelijk SU te hoeven worden.

[CyBeR]

HTT-Thalan schreef op zaterdag 28 januari 2012 @ 18:50:
[...]


Ik ben de enige user (en zal dat voorlopig ook blijven)

Nja, voor een single-user doos is sudo/su en al dat soort dingen ook compleet oninteressant. Het wordt interessant zodra je multi-user bezig bent.

[Verwijderd]

CyBeR schreef op zaterdag 28 januari 2012 @ 18:35:
Waarom? Sudo is op zich niet nuttiger dan su als je er alleen een shell mee uitvoert, maar als je dat niet doet én je leert jezelf niet aan om overal sudo voor te zetten () is 't mijns insziens een beter idee dan su'en. En als je een machine hebt waarop ook anderen bepaalde commando's als root moeten uit kunnen voeren, zonder meteen die commando's setuid te maken (wat in zichzelf een slecht idee is qua security) kun je met sudo instellen wie, wat kan doen. Plus, voor sudo heb je geen root wachtwoord nodig maar alleen je eigen, wat in multi-user situaties een wachtwoordmanagementprobleem oplost.

Een systeem met sudo is potentieel onveiliger dan een systeem zonder sudo. Maar dat is inderdaad afhankelijk van de system administrator(s). Zoals ik al zei vind ik het verschrikkelijk als mensen sudo gebruiken om vervolgens elk willekeurige commando te kunnen uitvoeren. Switch dan gewoon naar root.

Maar eigenlijk is er geen zinnig woord over te zeggen omdat elke situatie weer een andere oplossing vereist.

CyBeR schreef op zaterdag 28 januari 2012 @ 18:55:

Nja, voor een single-user doos is sudo/su en al dat soort dingen ook compleet oninteressant. Het wordt interessant zodra je multi-user bezig bent.

Dit was ook de reden dat ik dat zei, want sudo is absoluut een handige tool. Maar het moet worden gezien als een zwitsers zakmes, geschikt voor sommige zaken, maar je moet er geen bomen mee willen omhakken of hout mee gaan zagen. En je moet het ook niet gebruiken om een wond mee te hechten.

[HTT-Thalan]

CyBeR schreef op zaterdag 28 januari 2012 @ 18:55:
[...]


Nja, voor een single-user doos is sudo/su en al dat soort dingen ook compleet oninteressant. Het wordt interessant zodra je multi-user bezig bent.

Het ding word een printserver voor thuis, de hele server is per definitie oninteressant, het is vooral bedoeld als leerproject . Ik wil de installatie so 'lean and mean' houden als mogelijk, en de werkwijze op de juiste manier aanleren.

[VisionMaster]

HTT-Thalan schreef op zaterdag 28 januari 2012 @ 12:24:
[...]


Wel, ik ben de enige user, maar hierboven heb ik een leuke screenshot gezien van een hacker/scriptkiddie die gewoon continue rootwachtwoorden aan het bruteforcen is. Op basis daarvan twijfel ik toch over het uitschakelen van root, maar dan heb ik SUDO wél nodig, terwijl iemand anders hier ook weer adviseert om SUDO in zijn geheel te verwijderen .

Dat Fail2Ban houd ik in mijn achterhoofd, maar RSA keys en dergelijke lijken nu nog even niet nodig op basis van mijn behoeftes.

Mag ik vragen waar je "sudo" voor nodig hebt dat je niet met een shell van root kan doen of met "su root -c /sbin/shutdown -h now" of "su - -c shutdown -h now"

HTT-Thalan schreef op zaterdag 28 januari 2012 @ 18:58:[...]
Het ding word een printserver voor thuis, de hele server is per definitie oninteressant, het is vooral bedoeld als leerproject . Ik wil de installatie so 'lean and mean' houden als mogelijk, en de werkwijze op de juiste manier aanleren.

Waar begin je me als 'lean and mean' basis? Een Linux distro vanaf minimal install?

[ Voor 22% gewijzigd door VisionMaster op 28-01-2012 19:14 ]

[HTT-Thalan]

VisionMaster schreef op zaterdag 28 januari 2012 @ 19:04:
[...]

Mag ik vragen waar je "sudo" voor nodig hebt dat je niet met een shell van root kan doen of met "su root -c /sbin/shutdown -h now" of "su - -c shutdown -h now"

Vandaar dus ook mijn eerste opmerking of ik SUDO eigenlijk niet gewoon helemaal kan trashen .

[...]

Waar begin je me als 'lean and mean' basis? Een Linux distro vanaf minimal install?

Debian Squeeze Net-Install iso gebruikt met alleen 'standard system utilities' aangevinkt tijdens de installatie. Ext3 file system, aparte /home directory, that's it.

[HTT-Thalan]

Even naar CUPS zoeken:

code:

sven@Skybian:~$ sudo apt-cache search cups
[sudo] password for sven:
apcupsd-cgi - APC UPS Power Management (web interface)
apcupsd-doc - APC UPS Power Management (documentation/examples)
apcupsd - APC UPS Power Management (daemon)
bluez-cups - Bluetooth printer driver for CUPS
collectd-core - statistics collection and monitoring daemon (core system)
cups-pdf - PDF printer for CUPS
cups-pk-helper - PolicyKit helper to configure cups with fine-grained privileges
cups-bsd - Common UNIX Printing System(tm) - BSD commands
cups-client - Common UNIX Printing System(tm) - client programs (SysV)
cups-common - Common UNIX Printing System(tm) - common files
cups-dbg - Common UNIX Printing System(tm) - debugging symbols
cups-ppdc - Common UNIX Printing System(tm) - PPD manipulation utilities
cups - Common UNIX Printing System(tm) - server
cupsddk - Common UNIX Printing System (transitional package)
libcups2-dev - Common UNIX Printing System(tm) - Development files CUPS library
libcups2 - Common UNIX Printing System(tm) - Core library
libcupscgi1-dev - Common UNIX Printing System(tm) - Development files for CGI library
libcupscgi1 - Common UNIX Printing System(tm) - CGI library
libcupsdriver1-dev - Common UNIX Printing System(tm) - Development files driver library
libcupsdriver1 - Common UNIX Printing System(tm) - Driver library
libcupsimage2-dev - Common UNIX Printing System(tm) - Development files CUPS image library
libcupsimage2 - Common UNIX Printing System(tm) - Raster image library
libcupsmime1-dev - Common UNIX Printing System(tm) - Development files MIME library
libcupsmime1 - Common UNIX Printing System(tm) - MIME library
libcupsppdc1-dev - Common UNIX Printing System(tm) - Development files PPD library
libcupsppdc1 - Common UNIX Printing System(tm) - PPD manipulation library
etw-data - graphics and audio data for etw
etw - arcade-style soccer game
foomatic-db-engine - OpenPrinting printer support - programs
foomatic-db - OpenPrinting printer support - database
foomatic-filters - OpenPrinting printer support - filters
gapcmon - APC UPS Power Management (GUI)
ghostscript-cups - The GPL Ghostscript PostScript/PDF interpreter - CUPS filters
gtklp - printing tool for CUPS on the GNOME Desktop
cups-driver-gutenprint - printer drivers for CUPS
escputil - maintenance utility for Epson Stylus printers
foomatic-db-gutenprint - OpenPrinting printer support - database for Gutenprint printer drivers
gimp-gutenprint - print plugin for the GIMP
gutenprint-doc - users' guide for Gutenprint and CUPS
gutenprint-locales - locale data files for Gutenprint
ijsgutenprint - inkjet server - Ghostscript driver for Gutenprint
libgutenprint-dev - development files for the Gutenprint printer driver library
libgutenprint-doc - documentation for the Gutenprint printer driver library
libgutenprint2 - runtime for the Gutenprint printer driver library
libgutenprintui2-1 - runtime for the Gutenprint printer driver user interface library
libgutenprintui2-dev - development files for the Gutenprint printer driver user interface library
hpijs - HP Linux Printing and Imaging - gs IJS driver (hpijs)
hplip-cups - HP Linux Printing and Imaging - CUPS Raster driver (hpcups)
hplip - HP Linux Printing and Imaging System (HPLIP)
ksystemlog - system log viewer
latencytop - A tool for developers to visualize system latencies
libgnomecups1.0-1 - GNOME library for CUPS interaction
libgnomecups1.0-dev - GNOME library for CUPS interaction (headers)
libgtk2-ex-printdialog-perl - pure-perl alternative to the Gnome2::Print libraries
libnet-cups-perl - Perl module for printing through CUPS
min12xxw - Printer driver for KonicaMinolta PagePro 1[234]xxW
openoffice.org - office productivity suite
python-cups - Python bindings for CUPS
ssvnc - Enhanced TightVNC viewer with SSL/SSH tunnel helper
python-cupshelpers - Python utility modules around the CUPS printing system
system-config-printer-udev - Utilities to detect and configure printers automatically
system-config-printer - graphical interface to configure the printing system
libwine-print - Windows API implementation - printing module
xpp - X Printing Panel
sven@Skybian:~$ sudo apt-cache search cups | more
apcupsd-cgi - APC UPS Power Management (web interface)
apcupsd-doc - APC UPS Power Management (documentation/examples)
apcupsd - APC UPS Power Management (daemon)
bluez-cups - Bluetooth printer driver for CUPS
collectd-core - statistics collection and monitoring daemon (core system)
cups-pdf - PDF printer for CUPS
cups-pk-helper - PolicyKit helper to configure cups with fine-grained privileges
cups-bsd - Common UNIX Printing System(tm) - BSD commands
cups-client - Common UNIX Printing System(tm) - client programs (SysV)
cups-common - Common UNIX Printing System(tm) - common files
cups-dbg - Common UNIX Printing System(tm) - debugging symbols
cups-ppdc - Common UNIX Printing System(tm) - PPD manipulation utilities
cups - Common UNIX Printing System(tm) - server
cupsddk - Common UNIX Printing System (transitional package)
libcups2-dev - Common UNIX Printing System(tm) - Development files CUPS library
libcups2 - Common UNIX Printing System(tm) - Core library
libcupscgi1-dev - Common UNIX Printing System(tm) - Development files for CGI li
brary
libcupscgi1 - Common UNIX Printing System(tm) - CGI library
libcupsdriver1-dev - Common UNIX Printing System(tm) - Development files driver
library
libcupsdriver1 - Common UNIX Printing System(tm) - Driver library
libcupsimage2-dev - Common UNIX Printing System(tm) - Development files CUPS ima
ge library
libcupsimage2 - Common UNIX Printing System(tm) - Raster image library
libcupsmime1-dev - Common UNIX Printing System(tm) - Development files MIME libr
ary
libcupsmime1 - Common UNIX Printing System(tm) - MIME library
libcupsppdc1-dev - Common UNIX Printing System(tm) - Development files PPD libra
ry
libcupsppdc1 - Common UNIX Printing System(tm) - PPD manipulation library
etw-data - graphics and audio data for etw
etw - arcade-style soccer game
foomatic-db-engine - OpenPrinting printer support - programs
foomatic-db - OpenPrinting printer support - database
foomatic-filters - OpenPrinting printer support - filters
gapcmon - APC UPS Power Management (GUI)
ghostscript-cups - The GPL Ghostscript PostScript/PDF interpreter - CUPS filters
gtklp - printing tool for CUPS on the GNOME Desktop
cups-driver-gutenprint - printer drivers for CUPS
escputil - maintenance utility for Epson Stylus printers
foomatic-db-gutenprint - OpenPrinting printer support - database for Gutenprint
printer drivers
gimp-gutenprint - print plugin for the GIMP
gutenprint-doc - users' guide for Gutenprint and CUPS
gutenprint-locales - locale data files for Gutenprint
ijsgutenprint - inkjet server - Ghostscript driver for Gutenprint
libgutenprint-dev - development files for the Gutenprint printer driver library
libgutenprint-doc - documentation for the Gutenprint printer driver library
libgutenprint2 - runtime for the Gutenprint printer driver library
libgutenprintui2-1 - runtime for the Gutenprint printer driver user interface li
brary
libgutenprintui2-dev - development files for the Gutenprint printer driver user
interface library
hpijs - HP Linux Printing and Imaging - gs IJS driver (hpijs)
hplip-cups - HP Linux Printing and Imaging - CUPS Raster driver (hpcups)
hplip - HP Linux Printing and Imaging System (HPLIP)
ksystemlog - system log viewer
latencytop - A tool for developers to visualize system latencies
libgnomecups1.0-1 - GNOME library for CUPS interaction
libgnomecups1.0-dev - GNOME library for CUPS interaction (headers)
libgtk2-ex-printdialog-perl - pure-perl alternative to the Gnome2::Print librari
es
libnet-cups-perl - Perl module for printing through CUPS
min12xxw - Printer driver for KonicaMinolta PagePro 1[234]xxW
openoffice.org - office productivity suite
python-cups - Python bindings for CUPS
ssvnc - Enhanced TightVNC viewer with SSL/SSH tunnel helper
python-cupshelpers - Python utility modules around the CUPS printing system
system-config-printer-udev - Utilities to detect and configure printers automati
cally
system-config-printer - graphical interface to configure the printing system
libwine-print - Windows API implementation - printing module
xpp - X Printing Panel

Juist . Ik dénk dat ik alleen de Server files nodig heb, dependancies regelt hij zelf, maar moet ik verder niks installeren om vanaf een windows-client de settings te kunnen regelen?

Printer is aanwezig in ieder geval, moet nog wel drivers installeren.

code:

sven@Skybian:~$ lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX
Bus 002 Device 002: ID 046d:c312 Logitech, Inc. DeLuxe 250 Keyboard
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 04a9:10d2 Canon, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
sven@Skybian:~$

[ Voor 3% gewijzigd door HTT-Thalan op 28-01-2012 19:51 ]

[eamelink]

CAPSLOCK2000 schreef op vrijdag 27 januari 2012 @ 22:08:
Mijn privesleutel verlaat mijn eigen computer nooit.

Dus je gebruikt geen ForwardAgent?

[CAPSLOCK2000]

Die gebruik ik niet by-default, maar zelfs met een ForwardAgent verlaat mijn prive-key mijn computer niet, nooit. Dat is het mooie van SSH. Indien nodig wordt een verzoek tot authenticatie doorgegeven (via een ForwardAgent) naar mij eigen computer. Lees dit maar eens na: http://unixwiz.net/techtips/ssh-agent-forwarding.html#fwd

Dit is ook weer een prima voorbeeld waarom SSH-keys zo veel veiliger zijn dan wachtwoorden. Als je via een server die gekraakt is (en dat weet je nooit zeker) verbinding wil maken met een andere server. Als je wachtwoorden gebruikt dan is er geen andere oplossing dan je wachtwoord via de gekraakte server te sturen. De kraker kan dan je wachtwoord onderscheppen. Met ssh-keys kan dat niet, want je key verlaat je eigen computer niet. De geopende verbinding kan nog steeds misbruikt worden, maar als jij de verbinding afsluit is het voorbij en kan de aanvaller niks meer.

[Verwijderd]

En toch is Kerberos nóg mooier

[Hero of Time]

HTT-Thalan schreef op zaterdag 28 januari 2012 @ 19:46:
Even naar CUPS zoeken:

[snip]

Juist . Ik dénk dat ik alleen de Server files nodig heb, dependancies regelt hij zelf, maar moet ik verder niks installeren om vanaf een windows-client de settings te kunnen regelen?

Printer is aanwezig in ieder geval, moet nog wel drivers installeren.

code:

sven@Skybian:~$ lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX
Bus 002 Device 002: ID 046d:c312 Logitech, Inc. DeLuxe 250 Keyboard
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 04a9:10d2 Canon, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
sven@Skybian:~$

Damn, maak je output eens beter leesbaar. In die lap tekst is niet te zien waar je het volgende commando uitvoert. En was je punt hier niet het bespreken van de beveiliging van je server, ipv het installeren van een printserver (daarbij kan je beter aptitude openen en cups selecteren, eventueel de recommended packages ivm drivers, of pluk die van de Canon website).

Zelf ga ik op het werk een aantal servers opnieuw installeren. Ze hebben nu OpenSuSE erop staan en ga over naar Debian. Dit is wel een leuke discussie voor mij, zo weet ik wat ik eventueel het beste kan doen. Dit omdat mijn collega's wel erg makkelijk met root aanmelden en zelfs onze externe partij maakt zich er schuldig aan. Die laatste wisselt dan wel via su naar de gebruiker die ze moeten hebben, maar het is beter als zo min mogelijk mensen het root wachtwoord weten of direct aan kunnen melden als root. Dit ga ik morgen maar eens bespreken.
Wij hebben eigenlijk maar 1 server die geen gewone gebruiker heeft (of ik ben 'm vergeten ) en dat is onze interne mail relay, backup en monitoring server. Als je hier op aanmeld, dan doe je in feite maar 1 ding, en dat is iets wat root rechten nodig heeft (configuratie backup aanpassen, mail daemon herstarten, updates installeren, etc.)

Dat fail2ban is wel aardig, maar niet echt nuttig in onze situatie omdat we geen extern bereikbare server hebben, alles is intern of pas bereikbaar via VPN. Andere zaken als directe root login uitschakelen bij SSH is wel weer iets. Voor beheerders zoals ik is het ook wel handig om molly-guard te installeren. Die vraagt om je hostname als je de server wilt herstarten of uitschakelen. Erg handig in geval je bij de verkeerde server bent .

[HTT-Thalan]

Ik liet me meeslepen idd, maar ondertussen werken de webcam én printserver als een droom en kan ik verder gaan voorbereiden op externe toegang. Rootaccess via SSH blijft uit en SUDO ook, zodra hij online gaat.

[CyBeR]

HTT-Thalan schreef op zaterdag 28 januari 2012 @ 19:46:
Even naar CUPS zoeken:

code:

sven@Skybian:~$ sudo apt-cache search cups
[sudo] password for sven:

Uitstekend voorbeeld van iemand die uit gewenning sudo overal voorzet

[HTT-Thalan]

CyBeR schreef op zondag 29 januari 2012 @ 16:07:
[...]


Uitstekend voorbeeld van iemand die uit gewenning sudo overal voorzet

Daarom gaat die er ook uit .

Op dit moment heb ik:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 654/portmap
tcp 0 0 0.0.0.0:58354 0.0.0.0:* LISTEN 677/rpc.statd
tcp 0 0 0.0.0.0:10101 0.0.0.0:* LISTEN 1289/sshd
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 1096/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1198/exim4
tcp6 0 0 :::10101 :::* LISTEN 1289/sshd
tcp6 0 0 :::631 :::* LISTEN 1096/cupsd
tcp6 0 0 ::1:25 :::* LISTEN 1198/exim4

3 poorten openstaan volgens netstat. De 631 is vanwege de printserver, maar die laat alleen verkeer vanaf interne IP adressen toe, en de 10101 is voor SSH. De 25 ga ik misschien later gebruiken om mijzelf automatisch mailtjes te laten sturen bij bepaalde events.

Hoe kan ik zeker weten dat er niks onnodig open staat?

[ Voor 73% gewijzigd door HTT-Thalan op 29-01-2012 16:14 ]

[CyBeR]

Waarna je uit gewenning eerst su't naar root? Dat is een menselijk probleem, niet een technisch probleem.

[HTT-Thalan]

CyBeR schreef op zondag 29 januari 2012 @ 16:11:
Waarna je uit gewenning eerst su't naar root? Dat is een menselijk probleem, niet een technisch probleem.

Naja, ik moet inderdaad aanleren eerst alle commando's gewoon normaal in te voeren, tenzij ik dan de melding krijg dat ik dan root moet zijn via SUDO of SU, maar ik weet nog lang niet van te voren in te schatten wanneer dat het geval is, en dan krijg je dus die SUDO-gewoonte.

Ik heb /etc/passwd eens bekeken, en daar zitten volgens mij toch wel een aantal useraccounts tussen die compleet onnodig zijn zoals 'NEWS' en 'IRC'. Hoe kan ik veilig bepalen welke ik kan disablen en hoe doe ik dat?

[Borromini]

Sudo is handig in die zin dat je het root-paswoord niet hoeft te geven aan mensen die bepaalde administratieve taken mogen uitvoeren. Ik heb mijn broer bv. mijn AppleTV gegeven maar heb liever niet dat ie m'n root-paswoord weet (dat gebruik ik namelijk op al mijn systemen ). Met sudo kan hij netjes doen wat hij moet doen als het nodig is (door de complexe netwerksetup heb ik van buitenaf geen toegang).

Een niet-standaard poort voor SSH is ook een goed idee, net zoals het uitschakelen van roottoegang. Dat zou zelfs standaard mogen uit staan als je 't vraagt.

Voor een SSH-poort waar de hele wereld aankan zou ik persoonlijk ook keys verplicht maken, maar dat beperkt wel de locaties van waaruit je kan inloggen - je dient namelijk altijd je key bij te hebben.

Een filter op het aantal maximum mislukte pogingen is evenmin slecht. Fail2ban is al gepasseerd, ik geloof dat ik het ooit met de recent module van iptables geïmplementeerd heb. Dat scheelt je weer iets extra .

Ik draai zelf Lighttpd, maar ik heb het (nog) niet gechroot.

[Boudewijn]

Ik gebruik altijd denyhosts ipv fail2ban.

Ennuh TS, wat betreft het scnannen van wat er onnodig open staat: probeer nmap eens. Dat gebruikt de gemiddelde intruder vermoedelijk ook wel om eens lekker rond te scannen.

[HTT-Thalan]

Boudewijn schreef op zondag 29 januari 2012 @ 17:03:
Ik gebruik altijd denyhosts ipv fail2ban.

Ennuh TS, wat betreft het scnannen van wat er onnodig open staat: probeer nmap eens. Dat gebruikt de gemiddelde intruder vermoedelijk ook wel om eens lekker rond te scannen.

Doe ik direct na mijn full backup, leek me ook wel handig om die te hebben.

- edit -

Starting Nmap 5.00 ( http://nmap.org ) at 2012-01-29 17:38 CET
Interesting ports on localhost (127.0.0.1):
Not shown: 997 closed ports
PORT STATE SERVICE
25/tcp open smtp
111/tcp open rpcbind
631/tcp open ipp

Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

Zo vind ik dus ook niks, óf mijn server zit al potdicht, dat kan ook .

[ Voor 31% gewijzigd door HTT-Thalan op 29-01-2012 17:39 ]

[Hero of Time]

Standaard staan alle poorten in Linux dicht. Pas als er een applicatie/daemon is die er gebruik van maakt, staat deze open. Je hebt alleen wel op het verkeerde IP gescant, want Cups draait alleen op 127.0.0.1, niet op je externe IP (bijvoorbeeld 192.168.1.102). Dan zie je dat alleen poort 25 er nog staat. En die hoeft in principe er ook niet te staan, want je server mailt zelf, het hoeft geen mails van andere systemen door te sturen. Poort 111 staat bij mij niet open, maar dat is wellicht omdat jij Samba hebt geïnstalleerd om je printer te delen.

[HTT-Thalan]

Hero Of Time schreef op zondag 29 januari 2012 @ 20:50:
Standaard staan alle poorten in Linux dicht. Pas als er een applicatie/daemon is die er gebruik van maakt, staat deze open. Je hebt alleen wel op het verkeerde IP gescant, want Cups draait alleen op 127.0.0.1, niet op je externe IP (bijvoorbeeld 192.168.1.102). Dan zie je dat alleen poort 25 er nog staat. En die hoeft in principe er ook niet te staan, want je server mailt zelf, het hoeft geen mails van andere systemen door te sturen. Poort 111 staat bij mij niet open, maar dat is wellicht omdat jij Samba hebt geïnstalleerd om je printer te delen.

Als ik NMAP naar mijn thuisnetwerkadres wijs in plaats van localhost heb ik alleen nog maar 111 en 631 open staan.

Als ik NMAP naar het adres van mijn Windows laptop wijs, kan ik wachten tot ik een ons weeg, het scherm blijft leeg tot ik ctrl-c geef. Wtf?

Poort 111:

12.1.14.3 Why do I have port 111 open?

Port 111 is sunrpc's portmapper, and it is installed by default as part of Debian's base installation since there is no need to know when a user's program might need RPC to work correctly. In any case, it is used mostly for NFS. If you do not need it, remove it as explained in Securing RPC services, Section 5.13.

uit: http://www.debian.org/doc...debian-howto/ch12.en.html

[ Voor 28% gewijzigd door HTT-Thalan op 29-01-2012 20:56 ]

[CyBeR]

HTT-Thalan schreef op zondag 29 januari 2012 @ 17:15:
[...]


Doe ik direct na mijn full backup, leek me ook wel handig om die te hebben.

- edit -

Starting Nmap 5.00 ( http://nmap.org ) at 2012-01-29 17:38 CET
Interesting ports on localhost (127.0.0.1):
Not shown: 997 closed ports
PORT STATE SERVICE
25/tcp open smtp
111/tcp open rpcbind
631/tcp open ipp

Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds

Zo vind ik dus ook niks, óf mijn server zit al potdicht, dat kan ook .

Nooit localhost scannen, tenzij je dat specifiek wilt weten. Altijd je gewone IP-adres gebruiken, en liefst vanaf een andere host ook nog.

[HTT-Thalan]

CyBeR schreef op zondag 29 januari 2012 @ 20:58:
[...]


Nooit localhost scannen, tenzij je dat specifiek wilt weten. Altijd je gewone IP-adres gebruiken, en liefst vanaf een andere host ook nog.

Nou, ik heb NMAP voor windows geinstalleerd maar die beweert dat mijn server-ip 'host down' is. Als ik mijn eigen laptop-ip ermee scan werkt het wel gewoon.

[webfreakz.nl]

HTT-Thalan schreef op zondag 29 januari 2012 @ 21:10:
[...]


Nou, ik heb NMAP voor windows geinstalleerd maar die beweert dat mijn server-ip 'host down' is. Als ik mijn eigen laptop-ip ermee scan werkt het wel gewoon.

nmap -PN

[HTT-Thalan]

webfreakz.nl schreef op zondag 29 januari 2012 @ 21:11:
[...]


nmap -PN

dat gaf het programma zelf ook al als tip, werkt ook niet. Heb het er weer af gegooid .

[VisionMaster]

HTT-Thalan schreef op zondag 29 januari 2012 @ 21:22:
[...]


dat gaf het programma zelf ook al als tip, werkt ook niet. Heb het er weer af gegooid .

Kan een firewall probleempje zijn, privilege probleempje aan je desktop kant... kan van alles zijn. nmap is handig voor de details die je nodig kan hebben.

Een uber-basale manier om TCP gebaseerde connecties te testen is met telnet:
telnet <host/ip> <portnummer>

En deze kan je niet zo eenvoudig deinstalleren

[Verwijderd]

VisionMaster schreef op zondag 29 januari 2012 @ 22:05:

En deze kan je niet zo eenvoudig deinstalleren

Waarom zou dat niet kunnen? Standaard kun je prima zonder telnet en netcat.

[Gomez12]

HTT-Thalan schreef op zondag 29 januari 2012 @ 21:10:
[...]


Nou, ik heb NMAP voor windows geinstalleerd maar die beweert dat mijn server-ip 'host down' is. Als ik mijn eigen laptop-ip ermee scan werkt het wel gewoon.

Niet toevallig aan de windows-kant een application firewall oid die nmap de toegang ontzegd?

[HTT-Thalan]

Gomez12 schreef op zondag 29 januari 2012 @ 22:10:
[...]

Niet toevallig aan de windows-kant een application firewall oid die nmap de toegang ontzegd?

Bitdefender 2012. Zou kunnen .

[Boudewijn]

En zenmap is imo de fijnste nmap-gui, ook omdat hij je resultaten opslaat en sorteert enzo.
Fijn dingetje.

[lordgandalf]

HTT-Thalan schreef op vrijdag 27 januari 2012 @ 19:52:
[...]


Maar dan heb je dus een fixed IP nodig op de externe locatie vanwaar je jouw server benadert?

Nee de tool fwknop teminste is slim genoeg te configureren dat deze iedereen met het juiste wachtwoord en juiste poort toegang geeft tot de beschermde poorten

[VisionMaster]

Verwijderd schreef op zondag 29 januari 2012 @ 22:07:
[...]

Waarom zou dat niet kunnen? Standaard kun je prima zonder telnet en netcat.

Wijsneus Er staat toch "eenvoudig" tussen, als woord. Natuurlijk kan je die ook uit Windows deinstalleren. Maar het zit wat meer verborgen dan het nogal opzichtige "Nmap Uninstall" in je Start menu.

Verder zou het zonde zijn om prima analytische tools te deinstalleren, maar dat is mijn mening dan.

[ Voor 4% gewijzigd door VisionMaster op 31-01-2012 10:08 ]

[Boudewijn]

Afaik moet je eerst telnet op windows installeren via de windows-delen-toevoegen wizzard. Is ook niet helemaal voor de hand liggend.