S_ISUID 04000 set user ID on execution
sat på filen ? Er det rigtigt- og er der andet ?
PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at min
sshd normalt ikke er kørende, men jeg via en skjult side kan starte den
op. Jeg er bare træt af at halvdelen af min syslog er dårlige forsøg på
at komme ind.
Jørn
For at starte sshd skal man normalt være root. Dvs. du skal have
din webserver til at køre ting som root - hvor mange sekunder tror
du der går før nogen finder din "skjulte" side, og er inde som root?
Det er nok nemmere bare at fjerne root-passwordet, og sætte ssh til
at tillade at man logger ind uden password. Så ser du heller ikke alle
de forsøg, de stopper lige så snart folk opdager hvor nemt det er at
komme ind.
I stedet for at åbne jordens største sikkerhedshul i webserveren, ville
jeg nok overveje en af følgende løsninger:
1. Begræns adgangen til ssh til ip-numre du logger ind fra, enten via
hosts.deny og hosts.allow, eller iptables.
2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
fx tre forsøg i minuttet.
Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.
Ja, men ved at sætte en "set user ID on execution" på sshd kan jeg undgå
apache skal køre som root.
>
> Det er nok nemmere bare at fjerne root-passwordet, og sætte ssh til
> at tillade at man logger ind uden password. Så ser du heller ikke alle
> de forsøg, de stopper lige så snart folk opdager hvor nemt det er at
> komme ind.
Rolig nu.
>
> I stedet for at åbne jordens største sikkerhedshul i webserveren, ville
> jeg nok overveje en af følgende løsninger:
>
> 1. Begræns adgangen til ssh til ip-numre du logger ind fra, enten via
> hosts.deny og hosts.allow, eller iptables.
Det ændre stadig ikke på antallet af logs i syslog, og jeg har desuden
allerede fjernet muligheden for at logge ind som root via ssh.
>
> 2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
> ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
> fx tre forsøg i minuttet.
Jeg har ikke iptables kørende.
Jørn
Hvorfor skulle det ikke ændre antallet af logs at du begrænser hvem
der kan lave de forsøg der giver logs'ene?
> og jeg har desuden
> allerede fjernet muligheden for at logge ind som root via ssh.
>
>>
>> 2. Er det helt umuligt (fordi du ikke ved på forhånd hvornår du logger
>> ind fra kina), så sæt en LIMIT-regel op i iptables, og begræns den til
>> fx tre forsøg i minuttet.
>
> Jeg har ikke iptables kørende.
iptables er en kommando der sætter nogen regler op i kernen.
>
>
> iptables er en kommando der sætter nogen regler op i kernen.
>
Hvis du har kommandoen til at begrænse antal login forsøg til 3 per
minut vil jeg gerne starte med at prøve det først - det lyder som en nem
og sikker løsning.
Jørn
Det må være noget i retning af:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit ! --limit 3/minute -j DROP
Forklaring:
-A INPUT: Add (tilføj) en input regel.
-p tcp: protocol = TCP
--dport 22: destination port = ssh
-m state: Brug modul: statefull inspection
--state NEW: Kun nye forbindelser.
-m limit: Brug modul: limit
!: Not (undtagen)
--limit 3/minute: 3 pakker per minut.
-j DROP: Smid dem væk.
Altså, smid alt undtagen de første tre nye connections per minut væk.
Øhh, synes ikke lige det virker - nu er det slet ikke muligt at få ssh
adgang til maskinen. Hvordan "resetter" man en iptables kommando, og kan
der være en fejl i linien herover ?
Jørn
Skift -A (add) ud med -D (delete).
Alternativt kan man bruge -D 1, for at slette regel nummer 1, men hvis
man tager hele linien igen med -D, kan den selv finde den rigtige
regel.
Der kan i princippet godt være en fejl, men jeg kan ikke lige se hvad
det skulle være :-(
Nu er da igen hul igennem til ssh. Men jeg vil stadig være meget
interesseret i en fungerende linie til at begrænse antallet af login
forsøg per minut.
Jørn
Hmm, ! virker åbenbart ikke på limit, selvom den står nævnt i manualen.
Så må reglen jo deles i to:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/minute -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP
Altså: Accepter (modtag) de første tre connections per minut, og smid
resten væk.
Der er iøvrigt en detalje der hedder --limit-burst, der default står
til 5, så det første minut vil de få log til fem forsøg. Den kan du
evt. lege med også...
Det ser ud som det virker - selvom man i den anden ende får lov til at
prøve mange gang :-) I logfilen skriver den :
service(sshd) ignoring max retries; 4 > 3
antager det er reglen som komme i brug her. Og jo, jeg har forsøgt at
logge ind på maskinen fra en helt anden maskine, som ikke er på samme
sub-net overhovedet.
Jeg takker - og skal måske til at lege lidt med iptables - nu jeg ved
hvordan man "kommer tilbage". Men en reboot af maskinen vil vel også
nulstille alle regler ?
Jørn
Er det ikke bare de 5 i brust-limit? De kan også sættes ned.
> I logfilen skriver den :
>
> service(sshd) ignoring max retries; 4 > 3
Hmm, det ligner ikke en typisk iptables log-besked den der.
> antager det er reglen som komme i brug her. Og jo, jeg har forsøgt at
> logge ind på maskinen fra en helt anden maskine, som ikke er på samme
> sub-net overhovedet.
Der er ingen regel i ovenstående om sub-net. Selv localhost er
begrænset.
I nyere kerner (2.6.16+) er der en der hedder hashlimit, den skulle
(hvis jeg har forstået det rigtigt) begrænse det til tre i minuttet
per ip-nummer, så du ikke risikerer selv at blive lukket ude fordi
andre allerede har brugt de tre forsøg.
> Jeg takker - og skal måske til at lege lidt med iptables - nu jeg ved
> hvordan man "kommer tilbage". Men en reboot af maskinen vil vel også
> nulstille alle regler ?
Ja, for at have reglerne fast ved boot, skal de gemmes et eller andet
sted. Hvor det er bedst at gemme dem afhænger af hvilken distro du
bruger.
En helt anden mulighed er iøvrigt at sætte "LogLevel ERROR" i
sshd_config (eller FATAL eller QUIET), for at få den til ikke at
logge hver eneste forsøg. Jeg kan dog ikke finde en mulighed for
at logge successfulde logins, men ikke mislykkede forsøg.
> PS Ved godt at det sikkerhedsmæssigt ikke er godt, men tanken er at min
> sshd normalt ikke er kørende, men jeg via en skjult side kan starte den
> op. Jeg er bare træt af at halvdelen af min syslog er dårlige forsøg på
> at komme ind.
Hvad med at sætte procmail op, og så sende en mail til en bestemt bruger,
med et bestemt indhold i subj, måske også en bestemt afsender, og så starte
SSHD fra procmail?
Der går noget længer tid inden nogen finder udaf det, end finder en sikke
særligt skjult fide man bare skal tilgå.
Jeg har aldrig fået sat det op til noget der skal køre som root, men som
alm. bruger har jegl, og så en komando med sudo foran, og sudores sat op
til brugeren kan køre den komando uden passwd, så skulle det vist virke,
vil jeg mene,,,
Hvis du har en mobil tlf. med e-mail klient, så kan du også begranse til det
IP range som din mobil udbyder har, hvis ikke du også skal kunne få adgang
ude fra den store romaing verden.
--
Med venlig hilsen
Ivar Madsen
--------------------------------------------------------------------------------
Pas nu på Jørn, det ender med du ikke selv må logge på maskinen,
fordi angriberne trigger DROP reglen :)
Er det ikke nemmer at tillade den IP du normalt kommer fra, at
køre ssh eller slå password valideringen fra, og køre med DSA,
eller RSA?
Det er mere sådan at jeg gerne vil have muligheden for at kunne logge på
hos en kammerat uden på forhånd at have hans IP (det er måske 1 gang
hvert andet år - men principielt). Ved at kunne starte sshd ved at tilgå
en skjult side på serveren, kunne jeg logge ind. I de 5-6 år jeg har
haft serveren kørende 24-7 har jeg ikke haft gæster (å vidt vides), dels
ved at forhindre root-login og ved at vælge gode passwords, og holde
systemet opdateret. Det eneste jeg vil opnå ved at "slukke" for sshd og
kun starte den efter behov er at yderligere styrke sikkerheden, og
reducere antallet af events i syslog, da ca. halvdelen af min syslog er
mislykkede forsøg på at logge ind via ssh. Jeg har dog ikke fået det til
at virke - (vil egentligt gerne stadig vide hvordan man gør), men prøver
i stedet nogle iptables kommandoer fra Kent - hvilket dog ikke helt
opfylder mine ønsker.
Jørn
Det forbedrer bestemt ikke din sikkerhed, at have apache kørende. sshd
er langt mere modstandsdygtig end apache nogensinde bliver.
Hvorfor er disse beskeder så stort et problem, at du vil køre apache og
give den mulighed for at starte en suid root binary?
Kan du ikke blot lære din log analyser at se bort fra beskederne?
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk
Erhm. Så skal han køre en mailserver i stedet for apache? Jeg gad godt
kigge mig lidt omkring i jeres verdener hvor det er en større risiko at
køre den nyeste sshd end det er at køre en mailserver eller webserver.
Det lader til, at det oprindelige problem er syslog beskeder fra
forkerte ssh logins. Hvad med at løse dét problem, i stedet for at kaste
flere internet-facing programmer efter maskinen?
Public key auth hjælper ikke på log-filen.
Nu du er her og læser med i tråden - jeg kunne ikke finde en mulighed
for at sætte sshd op til kun at logge successfulde logins. Ved du
om man kan det?
Jeg mener at alle log requests i auth.c bliver sendt gennem den samme
funktion, der logger til LOG_AUTH med prioritet LOG_INFO, så nej.
Jeg anbefaler i stedet at man logger til f.eks. /var/log/sshd i stedet
for authlog (så resten af indholdet i authlog ikke drukner) og lader log
analyseren lave et udtræk af de data man skal bruge.
I den aktuelle situation er denne patch heller ikke helt dum:
http://jcs.org/patches/sshd-drop_brute_force.diff
Jeg har ændret min sshd til at køre på en anden port end standarden. Det
har fjernet langt de fleste login forsøg.
/Jan
>> Hvad med at sætte procmail op, og så sende en mail til en bestemt bruger,
>> med et bestemt indhold i subj, måske også en bestemt afsender, og så
>> starte SSHD fra procmail?
> Erhm. Så skal han køre en mailserver i stedet for apache? Jeg gad godt
> kigge mig lidt omkring i jeres verdener hvor det er en større risiko at
> køre den nyeste sshd end det er at køre en mailserver eller webserver.
Det er naturligvis en forudsætning af at han køre mailserver.
Dengang jeg havde sat det op på den måde, så var det fordi jeg fra tid til
anden havde behov for at kunne starte et program, hjemme på maskinerne,
uanset hvor i landet jeg var, og så det en let måde. Kunne jeg have kørt
SSH fra min mobiltlf.? Mig bekendt ikke,,,
> Det lader til, at det oprindelige problem er syslog beskeder fra
> forkerte ssh logins. Hvad med at løse dét problem, i stedet for at kaste
> flere internet-facing programmer efter maskinen?
Jeg er enig i at det er beder for Jørn, at løse hans problem, istædet for at
finde en vej udenom problemmet.
Jah - der findes flere forskellige typer programmer du kan
købe/installere alt efter hvilken telefon du har :)
http://www.idokorro.com/products/ssh-features.shtml
http://www.xk72.com/midpssh/
Som eksempler...
Mvh
Johan
Det er selvfølgelig forudsat han ikke oprindeligt havde brug for
en webserver.
En anden god metode er at sætte port knocking op til at kontrollere
adgangen til port 22. Korrekt opsat forhindrer det også login forsøg
fra folk der fandt din SSH port ved at scanne igennem dine porte.
Afhængig af hvilken type maskine man forbinder fra, så kan det dog være
en smule besværligt at få den rigtige sekvens sendt afsted for at lukke
op.
--
PeKaJe
Linux is not a desktop OS for people whose VCRs are still flashing "12:00".
-- Paul Tomblin
Nu kører jeg både mail og web hosting for mere end 10 domæner i
forvejen, så sikkerhedsrisikoen på den konto er uændret.
Jørn
Det skal prøves - det er vel bare at rette i sshd_config filen ?
Jørn
Installere sudo pakken.
Opret en bruger uden rettigheder, med navnet startssh
Tilføj følgende til /etc/sudoers
startssh ALL= NOPASSWD: /etc/init.d/sshd start
Nu kan startssh brugeren køre "sudo /etc/init.d/sshd start", og
få kørt "/etc/init.d/sshd start" som root.
Tilføj følgende til startssh's crontab, hvis checket skal køre hvert minut:
* * * * * tail -100 /var/log/httpd/access.log |
grep -q 'start ssh' && sudo /etc/init.d/sshd start
Det kan evt. målrettes bedre hvis man siger at apache's
tidslog er i følgende format "[06/Apr/2006:20:20:21 +0200]"
* * * * * tail -100 /var/log/httpd/access.log |
grep `date +%d/%b/%y:%H:%M` |
grep -q 'start ssh' && sudo /etc/init.d/sshd start
Her søger vi efter de sidste 100 linier i loggen der indeholde et
tidsstemple i formatet "06/Apr/2006:20:20".
Skru evt. "tail -100" op til fx "tail -1000", hvis du har meget
aktivitet på webserveren. Tallet angiver ca. antallet af hit pr. minut.
Når du kalder en url på din webserver med ordet "start ssh", vil din
ssh daemon starte inden for et minut.
Jo. På Fedora blive PAM slet ikke kaldt.
Ret /etc/ssh/sshd_config til
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
Giver følgende logfiler for en eksisterne bruger (user):
Apr 17 13:45:47 bigfoot sshd[3474]: Received disconnect from
10.11.87.208: 11: No supported authentication methods available
Og for en ikke eksisterne bruger (test):
Apr 17 15:45:57 bigfoot sshd[3476]: Invalid user test from 1.2.3.4
Apr 17 13:45:57 bigfoot sshd[3477]: input_userauth_request: invalid user
test
Apr 17 13:45:57 bigfoot sshd[3477]: Failed none for invalid user test
from 1.2.3.4 port 2462 ssh2
Apr 17 13:45:57 bigfoot sshd[3477]: Received disconnect from 1.2.3.4:
11: No supported authentication methods available
Men "PasswordAuthentication yes", giver følgende for en eksisterne bruger:
Apr 17 15:44:46 bigfoot sshd[3439]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=speedy user=user
Apr 17 15:44:48 bigfoot sshd[3439]: Failed password for user from
1.2.3.4 port 2456 ssh2
Apr 17 13:44:48 bigfoot sshd[3440]: Failed password for user from
1.2.3.4 port 2456 ssh2
Apr 17 13:44:49 bigfoot sshd[3440]: Connection closed by 1.2.3.4
Og for en ikke eksisterne bruger:
Apr 17 15:45:01 bigfoot sshd[3442]: Invalid user test from 1.2.3.4
Apr 17 13:45:01 bigfoot sshd[3443]: input_userauth_request: invalid user
test
Apr 17 13:45:01 bigfoot sshd[3443]: Failed none for invalid user test
from 1.2.3.4 port 2457 ssh2
Apr 17 15:45:04 bigfoot sshd[3442]: pam_unix(sshd:auth): check pass;
user unknown
Apr 17 15:45:04 bigfoot sshd[3442]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=speedy
Apr 17 15:45:04 bigfoot sshd[3442]: pam_succeed_if(sshd:auth): error
retrieving information about user test
Apr 17 15:45:06 bigfoot sshd[3442]: Failed password for invalid user
test from 1.2.3.4 port 2457 ssh2
Apr 17 13:45:06 bigfoot sshd[3443]: Failed password for invalid user
test from 1.2.3.4 port 2457 ssh2
Apr 17 13:45:06 bigfoot sshd[3443]: Failed none for invalid user test
from 1.2.3.4 port 2457 ssh2
Apr 17 13:45:07 bigfoot sshd[3443]: Connection closed by 1.2.3.4
Endvidere smider "PasswordAuthentication no" TCP sessionen i det øjeblik
den ser klienten køre med password validering.
Også når klienten i den anden ende ikke opfører sig pænt? (F.eks.
forsøger password auth, selvom serveren siger at den ikke tilbyder det?)
> Endvidere smider "PasswordAuthentication no" TCP sessionen i det øjeblik
> den ser klienten køre med password validering.
Det har jeg aldrig oplevet, og jeg kan heller ikke finde tegn på det i
sshds kode. Er det noget sshd-portable eller PAM gør?
Snedig løsning, den undgår problemerne med at lade enhver idiot
med en webbrowser få adgang til at køre scripts som root. Den burde
dermed være noget mere sikker.
Det var da noget af en stak. Jeg tog udgangspunkt i min egen
log-fil, som indeholder flg:
Mar 15 21:32:05 gandalf sshd[3182]: Invalid user lars from 82.41.172.182
Mar 15 21:32:06 gandalf sshd[3184]: Invalid user keny from 82.41.172.182
Mar 15 21:32:07 gandalf sshd[3186]: Invalid user klaus from 82.41.172.182
Mar 15 21:32:08 gandalf sshd[3188]: Invalid user karl from 82.41.172.182
Mar 15 21:32:08 gandalf sshd[3190]: Invalid user kane from 82.41.172.182
Mar 15 21:32:09 gandalf sshd[3192]: Invalid user kenneth from 82.41.172.182
Mar 15 21:32:10 gandalf sshd[3194]: Invalid user keith from 82.41.172.182
Mar 15 21:32:10 gandalf sshd[3196]: Invalid user kelvin from 82.41.172.182
Det fylder ret godt, når der kommer en tre-fire linier i sekundet, og
det kan ikke reduceres ved at slå password-auth fra.
Fedora core 5, i et test miljø. Min OpenBSD generere mindre, men
jeg ville ikke pille i en produktionsmaskine.
>> Erhm. Så skal han køre en mailserver i stedet for apache? Jeg gad godt
>> kigge mig lidt omkring i jeres verdener hvor det er en større risiko
>> at køre den nyeste sshd end det er at køre en mailserver eller webserver.
>
> Nu kører jeg både mail og web hosting for mere end 10 domæner i
> forvejen, så sikkerhedsrisikoen på den konto er uændret.
Så må du huske at implementere den samme, vigtige beskyttelse for både
din mailserver og webserver.
KF> Det fylder ret godt, når der kommer en tre-fire linier i sekundet,
KF> og det kan ikke reduceres ved at slå password-auth fra.
Hvis man tilfældigvis kører Linux med en temmeligt ny kernel, så kan
sådan noget som det her måske hjælpe:
iptables -A INPUT -m tcp -p tcp --dport 22 -m recent --name SSH --hitcount 8 --update --seconds 60 -j REJECT
iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set -j ACCEPT
Så tillader man kun 8 nye forbindelser på TCP port 22 indenfor et
minut fra hver IP-adresse. Og det bedste er at der skal være et minut
hvor der ikke kommer 8 forbindelser, før der lukkes op igen. Det
begrænser problemet væsentligt.
Til gengæld så rammer det også hvis man logger ind 8 gange med succes
-- det kan ikke nøjes med at kigge på mislykkede logins. Det kan være
et problem hvis man benytter f.eks. RSA-autentikering og scripts. Så
kan man skrue op til f.eks. 30 pr. minut.
/Benny
Nej. Klienten jeg testede med lukkede (FIN) selv TCP sessionen og ikke
serveren som jeg skrev.
>> Endvidere smider "PasswordAuthentication no" TCP sessionen i det øjeblik
>> den ser klienten køre med password validering.
> Det har jeg aldrig oplevet, og jeg kan heller ikke finde tegn på det i
> sshds kode. Er det noget sshd-portable eller PAM gør?
Nej, glem det.
Ja, du kan skrive/ændre:
Port XX
og genstarte sshd
/Jan