[SSH] vreemde log entrys

[RielN]

Ik kijk zo eens naar mijn verbindingen op mijn sheevaplug, en zie daar deze in het rijtje staan:

code:

tcp        0      0 192.168.1.201:22        124.42.91.117:49217     TIME_WAIT
tcp        0    784 192.168.1.201:22        124.42.91.117:50229     ESTABLISHED
tcp        0      0 192.168.1.201:22        124.42.91.117:49007     TIME_WAIT
tcp        0      0 192.168.1.201:22        124.42.91.117:48843     TIME_WAIT

alleen al surfen naar http://124.42.91.117/ is eigenaardig ... wie of wat is daar ESTABLISHED??

topic even afgesplitst

[ Voor 3% gewijzigd door Pim. op 04-11-2009 07:25 ]

[Sallin]

RielN schreef op dinsdag 03 november 2009 @ 00:57:
Ik kijk zo eens naar mijn verbindingen op mijn sheevaplug, en zie daar deze in het rijtje staan:

code:

tcp        0      0 192.168.1.201:22        124.42.91.117:49217     TIME_WAIT
tcp        0    784 192.168.1.201:22        124.42.91.117:50229     ESTABLISHED
tcp        0      0 192.168.1.201:22        124.42.91.117:49007     TIME_WAIT
tcp        0      0 192.168.1.201:22        124.42.91.117:48843     TIME_WAIT

alleen al surfen naar http://124.42.91.117/ is eigenaardig ... wie of wat is daar ESTABLISHED??

22 is je SSH poort, er is dus een verbinding tussen dat ip en jouw ssh. Als je geen idee hebt wat er aan de hand is, dan zou ik me wat zorgen maken.

[ Voor 5% gewijzigd door Sallin op 03-11-2009 07:53 ]

[RielN]

nee, duidelijk een japanse? pagina.

hmm... van de gebruikers met root-access (root en ik) is het passwd echt niet te raden... maar een andere gebruiker was niet ingelogd. Maak me wel wat zorgen ja. Enige tips om e.e.a. te checken?

[Sallin]

RielN schreef op dinsdag 03 november 2009 @ 08:37:
nee, duidelijk een japanse? pagina.

hmm... van de gebruikers met root-access (root en ik) is het passwd echt niet te raden... maar een andere gebruiker was niet ingelogd. Maak me wel wat zorgen ja. Enige tips om e.e.a. te checken?

Je kan eens in je logbestanden gaan neuzen /var/log/ of het vaker voor komt (en eventueel sinds wanneer). Daarbij kan je kijken of je uitgebreidere logs kan krijgen. Ook kan je dat specifieke ipadres/range uitsluiten voor toegang.

[user109731]

RielN schreef op dinsdag 03 november 2009 @ 08:37:
Enige tips om e.e.a. te checken?

Staat er iets in /var/log/auth.log ?

[DeKaerften]

RielN schreef op dinsdag 03 november 2009 @ 08:37:
nee, duidelijk een japanse? pagina.

...

Het is Chinees (voor het grootste gedeelte dezelfde karakters, maar er wordt geen hiragana gebruikt voor de grammatica)

[RielN]

Dat scheelt

Maar er was geen user online tijdens de ESTABLISHED connectie .. ?

[Verwijderd]

RielN schreef op dinsdag 03 november 2009 @ 00:57:
Ik kijk zo eens naar mijn verbindingen op mijn sheevaplug, en zie daar deze in het rijtje staan:

code:

tcp        0      0 192.168.1.201:22        124.42.91.117:49217     TIME_WAIT
tcp        0    784 192.168.1.201:22        124.42.91.117:50229     ESTABLISHED
tcp        0      0 192.168.1.201:22        124.42.91.117:49007     TIME_WAIT
tcp        0      0 192.168.1.201:22        124.42.91.117:48843     TIME_WAIT

alleen al surfen naar http://124.42.91.117/ is eigenaardig ... wie of wat is daar ESTABLISHED??

Dit zijn van die ssh botjes die proberen in te loggen op je sheevaplug. Keys gebruiken en ze komen er niet in.

[RielN]

Eigenaardig.
Ik heb een vrij sterk password. Maar gezien het grote getal bij de data lijkt hij wel iets gedaan te hebben.

Met een key kan ik toch niet met elk apparaat inloggen?

[Verwijderd]

Hoelang is je wachtwoord? Daar hangt het meeste vanaf.

[Verwijderd]

RielN schreef op dinsdag 03 november 2009 @ 13:45:
Eigenaardig.
Ik heb een vrij sterk password. Maar gezien het grote getal bij de data lijkt hij wel iets gedaan te hebben.

Met een key kan ik toch niet met elk apparaat inloggen?

Waarom niet?

[RielN]

Verwijderd schreef op dinsdag 03 november 2009 @ 15:45:
Hoelang is je wachtwoord? Daar hangt het meeste vanaf.

8 tekens, letters cijfers leestekens?

[RielN]

JanDM schreef op dinsdag 03 november 2009 @ 09:46:
[...]

Staat er iets in /var/log/auth.log ?

code:

Nov  3 17:08:18 vsrielity sshd[1076]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:08:20 vsrielity sshd[1076]: Failed password for root from 121.14.38.200 port 50079 ssh2
Nov  3 17:08:27 vsrielity sshd[1079]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:08:29 vsrielity sshd[1079]: Failed password for root from 121.14.38.200 port 50525 ssh2
Nov  3 17:08:36 vsrielity sshd[1081]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:08:38 vsrielity sshd[1081]: Failed password for root from 121.14.38.200 port 51037 ssh2
Nov  3 17:08:46 vsrielity sshd[1084]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:08:47 vsrielity sshd[1084]: Failed password for root from 121.14.38.200 port 51463 ssh2
Nov  3 17:08:54 vsrielity sshd[1086]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:08:56 vsrielity sshd[1086]: Failed password for root from 121.14.38.200 port 51830 ssh2
Nov  3 17:09:01 vsrielity CRON[1091]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov  3 17:09:01 vsrielity CRON[1091]: pam_unix(cron:session): session closed for user root
Nov  3 17:09:04 vsrielity sshd[1089]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:09:06 vsrielity sshd[1089]: Failed password for root from 121.14.38.200 port 52298 ssh2
Nov  3 17:09:13 vsrielity sshd[1101]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:09:15 vsrielity sshd[1101]: Failed password for root from 121.14.38.200 port 52808 ssh2
Nov  3 17:09:22 vsrielity sshd[1103]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:09:25 vsrielity sshd[1103]: Failed password for root from 121.14.38.200 port 53311 ssh2
Nov  3 17:09:32 vsrielity sshd[1106]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:09:33 vsrielity sshd[1106]: Failed password for root from 121.14.38.200 port 53794 ssh2
Nov  3 17:09:41 vsrielity sshd[1108]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:09:42 vsrielity sshd[1108]: Failed password for root from 121.14.38.200 port 54245 ssh2
Nov  3 17:09:50 vsrielity sshd[1111]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:09:51 vsrielity sshd[1111]: Failed password for root from 121.14.38.200 port 54723 ssh2
Nov  3 17:09:58 vsrielity sshd[1113]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:10:00 vsrielity sshd[1113]: Failed password for root from 121.14.38.200 port 55122 ssh2
Nov  3 17:10:07 vsrielity sshd[1116]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:10:09 vsrielity sshd[1116]: Failed password for root from 121.14.38.200 port 55513 ssh2
Nov  3 17:10:16 vsrielity sshd[1118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:10:19 vsrielity sshd[1118]: Failed password for root from 121.14.38.200 port 55954 ssh2
Nov  3 17:10:27 vsrielity sshd[1121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.14.38.200  user=root
Nov  3 17:10:29 vsrielity sshd[1121]: Failed password for root from 121.14.38.200 port 56416 ssh2
Nov  3 17:17:01 vsrielity CRON[1151]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov  3 17:17:01 vsrielity CRON[1151]: pam_unix(cron:session): session closed for user root
Nov  3 17:24:10 vsrielity sshd[1179]: Accepted password for riel from 212.182.170.186 port 1177 ssh2
Nov  3 17:24:10 vsrielity sshd[1182]: pam_unix(sshd:session): session opened for user riel by (uid=0)

Zat ...

Wat kan ik hier nu aan doen? Moeilijk wachten tot t m lukt?

[ Voor 10% gewijzigd door RielN op 03-11-2009 17:26 ]

[Sosabowski]

http://www.fail2ban.org/wiki/index.php/Main_Page

Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.

[Sallin]

Om scriptkiddiesstandaardscans (scrabblewoord) te voorkomen kan je er voor kiezen je ssh op een andere poort te draaien (bv 2222). Ja het is geen echte beveiliging (security through obscurity), en ja het werkt wel . Sowieso, ik neem aan dat je geen rootloginmogelijkheden aan je ssh hebt gegeven, maar dat je users laat inloggen en die eventueel sudo rechten geeft.

[ Voor 27% gewijzigd door Sallin op 03-11-2009 17:54 ]

[Boudewijn]

Ik gebruik daar denyhosts voor, werkt prima. Je werkt dan op tcp-wrapper niveau, en je kunt mensen meteen voor verschillende daemons blokken.

@RIeIN: zet dit in /etc/deny.hosts:

ALL: ip-adres-van-die-aap.

Snelle fix .

[ Voor 23% gewijzigd door Boudewijn op 03-11-2009 18:57 ]

[RielN]

Sallin schreef op dinsdag 03 november 2009 @ 17:53:
Om scriptkiddiesstandaardscans (scrabblewoord) te voorkomen kan je er voor kiezen je ssh op een andere poort te draaien (bv 2222). Ja het is geen echte beveiliging (security through obscurity), en ja het werkt wel . Sowieso, ik neem aan dat je geen rootloginmogelijkheden aan je ssh hebt gegeven, maar dat je users laat inloggen en die eventueel sudo rechten geeft.

Klopt inderdaad, root login is niet mogelijk.
Ik kijk eens naar bovengenoemd programma.

Maar als ik jullie begrijp is dit wel een beetje orde van de dag, als in 'welcome to the net'. Vond het altijd een ver van mijn bed show, maar ik kijk nu naar die plug en er zit aan de andere kant van de wereld inderdaad iemand / iets toch dat ding te benaderen.

[Pim.]

Topic even afgesplitst omdat het een behoorlijke draad op zich begon te worden

[durian]

Ik heb al jaren een computer aan het net hangen, en al jaren proberen ze in te breken. De laatste maanden, vooral de laatste weken is het weer raak. Ik gebruik denyhost om ze af te sluiten, en krijg een aantal honderden mailtjes per dag op dit moment.

Een paar dagen geleden was ik het beu, en ik laat nu sshd op een andere poort luisteren. De rust is overweldigend De scriptjes proberen blijkbaar alleen poort 22...

[Pim.]

Ik gebruik portsentry voor dat soort dingen, je sshd naar een exotische poort verhuizien is eiigenlijk geen goede oplossing maar aach

[durian]

Helemaal mee eens, maar zoals ik zei, ik was de troep in de logs beu.

Maar het is idd een beetje een 'security through obscurity' maatregel (hoewel ik niet bang ben dat er iemand in kan).

[RielN]

Vanaf een externe linuxhost een nmap 'mijn website' commando geeft:

code:

Starting Nmap 4.76 ( http://nmap.org ) at 2009-11-04 07:48 UTC
Interesting ports on xx.xx.xx.xx:
Not shown: 968 closed ports
PORT      STATE    SERVICE
1/tcp     open     tcpmux
21/tcp    open     ftp
22/tcp    open     ssh
25/tcp    open     smtp
79/tcp    open     finger
80/tcp    open     http
110/tcp   open     pop3
111/tcp   open     rpcbind
119/tcp   open     nntp
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
143/tcp   open     imap
445/tcp   filtered microsoft-ds
465/tcp   open     smtps
993/tcp   open     imaps
995/tcp   open     pop3s
1025/tcp  open     NFS-or-IIS
1080/tcp  open     socks
1110/tcp  open     nfsd-status
1524/tcp  open     ingreslock
1723/tcp  open     pptp
2000/tcp  open     callbook
3128/tcp  open     squid-http
3306/tcp  open     mysql
6667/tcp  open     irc
10000/tcp open     snet-sensor-mgmt
12345/tcp open     netbus
31337/tcp open     Elite
32771/tcp open     sometimes-rpc5
32772/tcp open     sometimes-rpc7
32773/tcp open     sometimes-rpc9
32774/tcp open     sometimes-rpc11

Moet ik die poorten niet op 'stealth' zetten?

[Stamgastje]

Sosabowski schreef op dinsdag 03 november 2009 @ 17:28:
http://www.fail2ban.org/wiki/index.php/Main_Page

Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.

Een andere, vergelijkbare optie is sshguard. Deze bant IP adressen die een paar keer (instelbaar, standaard 4x) een authentication failure geven, voor een aantal minuten (ook instelbaar). Dit is een zeer effectieve manier van blokkeren, de meeste (alle?) bots gaan na een timeout direct door naar het volgende slachtoffer.

[Verwijderd]

Dat zijn echt belachelijk veel poorten die open staan. Ik zou me als ik jou was eens gaan verdiepen in een firewall. Je kunt kijken naar Shorewall, of zelf de regels intikken in iptables.

[RielN]

Dit was na installatie van Portsentry ...
Na de-installatie:

code:

PORT      STATE    SERVICE
21/tcp    open     ftp
22/tcp    open     ssh
25/tcp    open     smtp
80/tcp    open     http
110/tcp   open     pop3
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
143/tcp   open     imap
445/tcp   filtered microsoft-ds
465/tcp   open     smtps
993/tcp   open     imaps
995/tcp   open     pop3s
1025/tcp  open     NFS-or-IIS
1080/tcp  open     socks
1110/tcp  open     nfsd-status
1723/tcp  open     pptp
3128/tcp  open     squid-http
3306/tcp  open     mysql
10000/tcp open     snet-sensor-mgmt

En die gebruik ik allemaal.

fail2ban geinstalleerd.

Heeft iemand toevallig goede configuratiefiles? Die werken mijns inziens voor elk systeem wel goed.

[ Voor 79% gewijzigd door RielN op 04-11-2009 09:10 ]

[Sallin]

Je kan ook eens naar firestarter kijken. Een simpele firewall gui.

[Tout]

Waarom heb je eigenlijk mysql op een open poort staan?

[Herko_ter_Horst]

Je zegt: "die gebruik ik allemaal". Allemaal van buitenaf? MySQL zo even open aan het net hangen is (als gezegd) niet echt wat je noemt "best-practice"... En waarom imap en pop3 nog open als je ook al imaps en pop3s hebt? Ik zou toch nog eens goed evalueren wat je echt nodig hebt en hoe je daar secure aan kunt connecten. Als het protocol zelf geen encryption/encrypted variant ondersteunt, kun je overwegen over SSH te tunnelen.

[ Voor 3% gewijzigd door Herko_ter_Horst op 04-11-2009 09:19 ]

[Cidolfas]

Dat kan je ook met iptables oplossen, hier een (oud) voorbeeldje:

http://kanslozebagger.org/archives/64

De opzet is heel simpel, als je meer dan 4 keer per minuut een ssh connectie opzet naar de server wordt je voor een uur gebanned.

Ook niet de meest practische oplossing misschien, maar hij is te tunen en je hebt geen last van een iptables configuratie file die steeds groter wordt.

[Verwijderd]

Verwijderd schreef op woensdag 04 november 2009 @ 08:58:
Dat zijn echt belachelijk veel poorten die open staan. Ik zou me als ik jou was eens gaan verdiepen in een firewall. Je kunt kijken naar Shorewall, of zelf de regels intikken in iptables.

Inderdaad dat zijn belachelijk veel openstaande poorten. Verder is shorewall zo'n beetje de beste iptables frontend zo zie je shorewall wel erg veel in productie omgevingen gebruikt worden

shorewall++

[Elijan9]

"ESTABLISHED" betekent niks anders dan dat er geprobeerd wordt om in te loggen, absoluut niet dat dit gaat lukken. Het wil niets anders zeggen dan dat iemand een ssh login prompt weet te krijgen. Als iemand jouw voordeur weet te vinden, wil dat ook niet zeggen dat hij zomaar binnen kan komen.

Als je dit erg irritant vindt, kun je naast de al genoemde oplossingen ook gewoon ssh instellen om op een andere poort te draaien dan 22, bijvoorbeeld 8022 of iets anders. Sinds ik dat gedaan heb word ik nooit meer gescand op mijn ssh poort en kan ik nog steeds overal vandaan inloggen via ssh...

[Verwijderd]

Elijan9 schreef op woensdag 04 november 2009 @ 11:10:
en kan ik nog steeds overal vandaan inloggen via ssh...

Om die reden draaien wij op enkele speciale servers ssh op port 80

[The Flying Dutchman]

Net zoals iemand anders hier al aangaf draai ik op mijn server `denyhosts'. Het is eenvoudig te installeren (onder Ubuntu/Debian gewoon via apt-get, bij andere distro's vast ook eenvoudig).

Dagelijks pikt denyhost twee a drie IP adressen op van botjes die op goed geluk proberen in te loggen met SSH Denyhosts zet de bewuste IP adressen in het `/etc/hosts.deny' bestand en je kunt configureren of deze na een tijdje weer verwijderd moeten worden, en welke services geblokkeerd zijn.

Persoonlijk blokkeer ik alle services voor deze ip addressen en laat ik ze ook voor altijd in mijn hosts.deny bestand staan. De afgelopen paar weken al zo'n 100 IP addressen verzamelt, terwijl de server alleen overdag aan staat (ik ben net verhuisd, voor mijn verhuizing had ik nergens last van... ben bij dezelfde internet provider gebleven, ik woon nu wel in een heel ander gebied... blijft frapant).

Oh... en denyhosts kan geloof ik ook synchroniseren met een database van vervuilde IP addressen.

[Verwijderd]

RielN schreef op woensdag 04 november 2009 @ 09:08:
Heeft iemand toevallig goede configuratiefiles?

/etc/fail2ban/jail.conf

Bash:

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables-all[name=ssh]
logpath  = /var/log/sshd/current

[apache-iptables]
enabled  = true
filter   = apache-auth
action   = iptables-all[name=apache]
logpath  = /var/log/httpd-error.log

[proftpd-iptables]
enabled  = true
filter   = proftpd
action   = iptables-all[name=proftpd]
logpath  = /var/log/ftpd/current

/etc/fail2ban/action.d/iptables-all.conf

Bash:

[Definition]
actionstart = iptables -N fail2ban-<name>
              iptables -A fail2ban-<name> -j RETURN
              iptables -I INPUT -p all -j fail2ban-<name>

actionstop = iptables -D INPUT -p all -j fail2ban-<name>
             iptables -F fail2ban-<name>
             iptables -X fail2ban-<name>

actioncheck = iptables -n -L INPUT | grep -q fail2ban-<name>
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP

[Init]
name = default

Als iemand een overtreding maakt worden ze hiermee geblocked van je hele server, niet alleen van die service. Met iptables -L kan je mooi zien wie gebanned is voor welke service, omdat deze het netjes uit elkaar houdt ipv alles op één hoop te gooien.

[ Voor 8% gewijzigd door Verwijderd op 04-11-2009 13:43 ]

[Sosabowski]

Cidolfas schreef op woensdag 04 november 2009 @ 09:17:
Dat kan je ook met iptables oplossen, hier een (oud) voorbeeldje:

http://kanslozebagger.org/archives/64

De opzet is heel simpel, als je meer dan 4 keer per minuut een ssh connectie opzet naar de server wordt je voor een uur gebanned.

Ook niet de meest practische oplossing misschien, maar hij is te tunen en je hebt geen last van een iptables configuratie file die steeds groter wordt.

Dat is dus precies wat fail2ban doet (/kan doen).

Hier mijn configuratie om mijn ftp server een beetje te beveiligen:
/etc/fail2ban/filter.d/vsftpd.conf

code:

# Fail2Ban configuration file
#
[Definition]
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = \[. \] FAIL LOGIN: Client "<HOST>"$ 
            \[.+\] FTP response: Client "<HOST>", "530 Login incorrect."

[ Voor 35% gewijzigd door Sosabowski op 04-11-2009 13:48 ]