FORUM.M.NU

Hej alla glada entusiaster.

Det är otroligt roligt att se all kreativitet, alla lösningar och att följa projekten här. Var dag så poppar det upp en ny Raspberry med en liten webserver som visar olika mätdata, har själv ett par stycken. Men ... (finns ju alltid ett men)

Tänk på att skydda koden mot Cross Site Scriptning (XSS), både server och klientsidan, det vore så tråkigt om någon av våra projekt PI här skulle användas för en attack och alla bevis kommer att leda tillbaka till ditt ADSL och din dator, inte kul när en bank blivit hackad och du står där med bevisbördan.

För dom som aldrig hört talats om XSS uppmanar jag er att Ni måste läsa på om detta innan ni publicerar er PI med en webserver och någon form av scriptspråk.

Det finns massor att läsa, en källa att börja med:
https://www.owasp.org/index.php/XSS_(Cr ... heat_Sheet

I korthet så är XSS ett sätt att skicka scriptkod i ett formulär som sedan exekveras av servern. Testa följande på din server i något formulär som du har:

<b onmouseover=alert('Opps! XSS vulnerability found')>Testa klicka!</b>
eller
<a href="http://www.dn.se">DN</a>

Får du fram meddelandet eller kan klicka på länken till DN så är din server sårbar. Du bör då genast ta din server offline från nätet, och ändra din kod. Frågan du ska ställa dig är inte om du kommer att bli hackad, utan när du kommer att bli hackad.

Andra saker att tänka på är: SQL Injections för er som kör en databas. Om ni har port 22 eller SSH öppet mot Internet, vilket många nerdar som mig vill ha för att kunna fjärrköra sin dator, bör ni skydda den med en brandvägg och någon form av programvara mot intrång. Ett enkelt program som fungerar för Debian Wheezy är Fail2ban som kontrollerar felaktiga inloggningar i olika loggfiler och sedan dynamiskt skriver en brandväggsregel för att blockera den IP adressen.

### Installera IP-tables och nmap
# sudo apt-get install nmap iptables-persistent

### Installera fail2ban
### http://www.fail2ban.org/wiki/index.php/ ... he_problem
# sudo apt-get install fail2ban

Redan default installationen kommer skydda er SSHD bra.

Lycka till med alla projekt.

Mvh
Janne

TACK!!

Min server verkar vara ganska utsatt för intrångsförsök i alla fall

Kod: Markera allt

root@server:/home/user# cat /var/log/auth.log |grep 'Failed password'
Feb 10 09:36:42 server sshd[21855]: Failed password for invalid user oracle from 219.139.81.50 port 35991 ssh2
Feb 10 18:25:40 server sshd[2880]: Failed password for root from 85.214.108.67 port 47079 ssh2
Feb 10 18:25:43 server sshd[2883]: Failed password for root from 85.214.108.67 port 49830 ssh2
Feb 10 18:25:46 server sshd[2885]: Failed password for root from 85.214.108.67 port 52036 ssh2
Feb 10 18:25:48 server sshd[2887]: Failed password for root from 85.214.108.67 port 54111 ssh2
Feb 10 18:25:51 server sshd[2889]: Failed password for root from 85.214.108.67 port 55523 ssh2
Feb 10 18:25:54 server sshd[2891]: Failed password for root from 85.214.108.67 port 57705 ssh2
Feb 10 18:25:56 server sshd[2893]: Failed password for root from 85.214.108.67 port 59162 ssh2
Feb 10 18:26:02 server sshd[2895]: Failed password for root from 85.214.108.67 port 60601 ssh2
Feb 10 18:26:08 server sshd[2924]: Failed password for root from 85.214.108.67 port 36112 ssh2
Feb 10 18:26:11 server sshd[2934]: Failed password for root from 85.214.108.67 port 40066 ssh2
Feb 10 18:26:14 server sshd[2946]: Failed password for root from 85.214.108.67 port 41841 ssh2
Feb 10 18:26:17 server sshd[2948]: Failed password for root from 85.214.108.67 port 44129 ssh2
Feb 10 18:26:20 server sshd[2951]: Failed password for root from 85.214.108.67 port 46226 ssh2
Feb 10 18:26:26 server sshd[2953]: Failed password for root from 85.214.108.67 port 48146 ssh2
Feb 10 18:26:32 server sshd[2955]: Failed password for root from 85.214.108.67 port 52398 ssh2
Feb 10 18:26:35 server sshd[2957]: Failed password for root from 85.214.108.67 port 56465 ssh2
Feb 10 18:26:44 server sshd[2959]: Failed password for root from 85.214.108.67 port 58611 ssh2
Feb 10 18:26:47 server sshd[2963]: Failed password for root from 85.214.108.67 port 36946 ssh2
Feb 11 03:20:24 server sshd[15913]: Failed password for invalid user guest from 46.166.168.177 port 33319 ssh2
Feb 11 04:38:29 server sshd[17797]: Failed password for invalid user a from 83.212.107.28 port 44848 ssh2
Feb 11 05:17:30 server sshd[18731]: Failed password for invalid user support from 46.166.168.177 port 56759 ssh2

Och detta är bara senaste 24 timmarna

är det något mer som man bör kolla upp?

Med detta kommando kan ni kontrollera antalet försök och från vilken IP som någon försöker komma in:

awk 'gsub(".*sshd.*authentication failure", "") {print $7}' /var/log/auth.* | sort | uniq -c

Det är aldrig personer som sitter och testar, utan det är script/robotar som hela tiden scannar av nätet efter kända portar och sedan försöker komma in via bruteforce. Tips kan ju vara att antingen spärra den IP helt eller i alla fall sätta upp "ban"-tiden.

Själv har jag i min jail.conf satt ner för SSH till bara 1 försök och jag vill spärra ut den IP ganska länge, flera timmar. Det finns andra liknande program som lägger till dom i en blacklist som sedan tankas ut i molnet och du får även IP från molnet som läggs till i din blacklist. Det kan vara mycket effektivt.

Det finns nog fler saker man bör tänka på, men XSS och SQL Injections är det viktigaste. Sen att skydda sig då mot rena intrång som man kan göra med Fail2ban programmet och iptables.

Det man kan tänka på är att, inte ha guest konton, inte ha några onödiga konton och framför allt se till att ha komplexa och långa lösenord på samtliga konton. Bra grundregel är att blanda versaler, gemener, siffror och specialtecken. Ju längre destobättre men minst 8-10 tecken, gärna 14-20 om du kan komma ihåg så långa. Använd aldrig ord eller namn, felstava gärna om du använder ett ord. För vissa fungerar det bra att skapa en ramsa, tex "Jag tycker om att fiska på sommaren" som ger "jtoafps" sen får man lägga till sifrror i det och blanda lite stort o smått.

Jo, som tur är har jag långa komplexa lösenord.

men shit! är detta normalt med så många försök?

Hur listar man enklast användarkonton?
räcker det med cat på passwd filen?

och hur ser jag lyckade inloggningsförsök?

räcker userdel för att radera konton?

Kod: Markera allt

     13 rhost=108.163.159.72
      1 rhost=113.195.5.231
      2 rhost=118.194.218.85
     10 rhost=119.226.223.18
      1 rhost=121.8.154.35
      1 rhost=123.183.208.187
      2 rhost=1.234.51.243
     38 rhost=125.112.124.186
     15 rhost=159.253.5.253
     31 rhost=166.78.4.210
      1 rhost=174.142.207.57
    407 rhost=176.31.50.203
     15 rhost=186.232.120.75
      1 rhost=192.168.1.104
      1 rhost=195.242.72.145
    139 rhost=195.33.219.58
    420 rhost=201.117.190.121
     26 rhost=202.22.193.31
    139 rhost=203.114.227.94
      1 rhost=210.14.79.133
      1 rhost=211.245.216.196
    139 rhost=218.4.83.44
      2 rhost=218.54.31.102
      1 rhost=219.139.81.50
      1 rhost=219.239.26.13
     16 rhost=222.184.230.118
      2 rhost=46.166.168.177
    215 rhost=5.199.133.223
     19 rhost=88-191-236-10.rev.dedibox.fr
      1 rhost=91.219.181.46
     27 rhost=91.223.223.62
     18 rhost=h1747488.stratoserver.net
     94 rhost=host213-123-171-99.in-addr.btopenworld.com
      6 rhost=p15198440.pureserver.info
      1 rhost=snf-15530.vm.okeanos.grnet.gr

Bytte port på SSH oxå, kändes som en bra grej. tänkte dock inte på att brandväggen är stängd

hjälper det är bytta port eller hittas även udda portar med höga nummer?

bertilson skrev:Jo, som tur är har jag långa komplexa lösenord.

men shit! är detta normalt med så många försök?

Har dom möjlighet så hamrar dom med massssor av försök i sekunden, dygnet runt. (Har lekt lite med en Honeypot tidigare)

bertilson skrev:hjälper det är bytta port eller hittas även udda portar med höga nummer?

En variant är att sätta SSH (på utsidan) till någon port som normalt används till något helt annat...

Ex. 3389 som Windows RDP-protokoll går på i vanliga fall.
Börjar dom då hammra så använder dom (mest troligt) fel verktyg (eftersom dom tror att det är en RDP-session dom ska starta) och tar sig inte in.

Just ja... ett till hyffsat enkelt tips.

Se till att root inte får logga in via SSH.

Det är bra mycket svårare att gissa kombinationen av användare och lösen.

Tror det finns en "PermitRootLogon" eller något liknande i sshd-configen.

bertilson skrev: men shit! är detta normalt med så många försök?

Ja. Därför brukar jag alltid stänga av inloggning med lösenord och bara tillåta inloggning med nyckel, alltså "PasswordAuthentication no" i sshd_config. Givetvis efter att det är säkerställt att inloggning med nyckel fungerar..

bertilson skrev:
och hur ser jag lyckade inloggningsförsök?

cat /var/log/auth.* | grep -i "Accepted password"

Finns det någon (med någorlunda kunskap om ämnet), som skulle kunna beskriva lite eller skriva en kort guide/lista på hur man kan göra för att få en säkrare webbserver, kanske tillochmed "riktat" åt de med en Hallonpaj (Raspberry Pi)

Kanske inte alla här (däribland jag) som är så hemma på den biten.

Mvh Henrik

Om stavningen är knas så skyller jag på autocorrect i luren.

Svårt att skriva en guide som passar, det har inget med PI att göra utan vilket os, vilken webserver och vilket scriptspråk du skriver i, men grunden för att skydda sig mot XSS är input validation. Både client och server side, där server side är den viktigaste.

Input validation innebär att du kontrollerar innehållet, tex med en regex, innan du gör något mer med det. Om du har ett input form för telefonnr, så kontrollerar du att det endast innehåller siffror och inget annat. Är det en gatuaddress så kontrollera längden, kanske Max 25 tecken, men det räcker inte, sen kollar du om det finns specialtecken, tex <>\_, osv

Många språk har färdiga funktioner för dessa kontroller, att skala bort HTML mm.

Lycka till

FORUM.M.NU

Tänk efter före ...

Tänk efter före ...

Re: Tänk efter före ...

Re: Tänk efter före ...

Re: Tänk efter före ...

Re: Tänk efter före ...

Re: Tänk efter före ...

Re: Tänk efter före ...

Re: Tänk efter före ...

Re: Tänk efter före ...

Re: Sv: Tänk efter före ...

Re: Tänk efter före ...