Grundläggande Linuxsäkerhet

Ja, precis. Skulle någon ha problem med att hitta filen så kan man använda find:


FTP
"Very Secure FTPD"

Nu ska vi konfa lite inställningar:


Användaren "ftp" skapas automatiskt när ni installerar VSFTPD.

Red Hat

Istället för att använda sig av /bin/false och /bin/true för att förhindra inloggning kan man använda sig av /sbin/nologin som låtsas-skal. Fördelen med /sbin/nologin är att det finns inlagt i filen /etc/shells och därför behandlas som ett godkänt skal trots att man inte kan logga in med det.

För att skapa en användare med denna egenskap ger man kommandot

useradd -s /sbin/nologin <new username>

iptraf: iptraf är ett program för att kontrollera nätverksaktiviteten. Iptraf ger väldigt detaljerad statistik och information om vad som händer i nätverket. Det är väldigt enkelt att använda och kommer med en enkel användarmeny.



ulimit: är ett program som begränsar systemets resurser. Detta skulle bland annat skydda mot diverse forkbombs.
listar vad ulimit har för värden och vilka flaggor du ska använda. ulimit -u 10 sätter alltså max antal processer till 10.



Isowall är en isolerande brandvägg. Isowall är alltså en brandvägg som isolerar en dator i ett nätverk men ger den fortfarande tillgång till Internet vilket t.ex skulle skydda mot att ett virus vill sprida sig via LAN'et.

På Github så står det detaljerat hur du konfigurerar brandväggen.

Bra tips det finns en hel del kan göra sen när frågan vad som är nödvändigt .Personligen ser jag att man kommer väldigt långt med säkerheten om man ser till att man kör på kända och uppdaterade programvaror, använder bra lösenord krypterar alla förbindelse som har med inloggning att göra.
Fail2ban kör jag alltid in på Linux server är ju hela tiden bottar som försöker koma in. Dock kan det ställa till problem. t.e.x om en användare råkar logga in fel ex antal gånger så bannar det hela det lokala nätverket och låser ute alla användare på samma nätverk.

Brandvägg tycker jag ställer till mer problem än nytta. En öppen port som inte används är i sig inget säkerhetshål. Om man däremot har tjänster som bara ska vara tillgängliga för vissa ip-adresser så är det oftast mer smidigt med brandvägg ex(Ufw) än att gå in i en specifik config fil för en tjänst och ändra.
Att köra jail/chroot på min webbsidor är något jag funderar men då bör man också ha separata php instanser för varje site. Samtidigt som jag vill kunna redigera alla sidor ifrån en användare.

Du är fortfarande sårbar för okända säkerhetshål samt bruteforce. Sen ser du att jag tipsade om att låsa in sina FTP-användare och använda ulimit, utan detta så skulle det vara fullt möjligt att skada ett system.

Men långt kommer man, men att hålla god säkerhet är inget som kostar. Det låter som ren okunskap och lathet i mina öron om man påstår att utföra mindre säkerhetsåtgärder är något som duger.

Bara till att sätta antal försök till ett högre antal, t.ex 20. Stoppar ändå en bruteforce.

Säkerhetshål? Nej. Men säkerhetsrisk. Det bådar endast ont att ha en port öppen om du inte ska använda den. Det är som att säga att jag inte behöver låsa dörren för grannen inte är hemma.

Varför ska man ha separata php insatser för varje site? Ifrån en användare? Inte bra, men använd en user som är medlem i sudoers eller om du är modig så använd root.

Se så mycket skit ni måste göra för att hålla linux säkert,, det är ett riktigt skit OS:. i windows behöver man bara 2 program så är det klart.

Haha, jadu.

Den mesta diskussionen i denna tråd handlar om att säkerhetsställa olika tjänster så som SSH och FTP. Det är givetvis redan säkert från början men att t.ex inte låta en användare tillverka forkbombs är alltid en finess som är mer än valfri.

Windows är långt ifrån säkert. Anledningen till varför jag inte kommer skriva en guide om Windows det är för att den hade blivit överfylld och inte haft något direkt värde. De flesta virus är just till Windows så redan där är du motbevisad.

Windows XP CVE stats(714)
Linux Debian CVE stats(273)

Ja, 714 säkerhetsbrister på ett closed source OS är en siffra som även får mig fnissa.

"2 program så är det klart". DBAN och Truecrypt då eller?

Ja Wintendo är ju supersäkert.

Vore det inte bättre att lägga servern på ett livefilsystem baserat på ett SD-kort med WP satt till ON?

+ en watchdog som startar om servern om vissa villkor inte uppfylls eller uppfylls. Bäst är en hårdvaru-watchdog som drar RESET ifall den inte får en "ping" från serieporten tillräckligt ofta.

Då är det så vattentätt att man t.o.m. kan köra webbservern som root.

"Nackdelen" är att all uppdatering av webbsidan m.m. kräver fysisk tillgång till servern så man kan stänga av WP-switchen först.

Så därför får man då ha en databasserver, som förslagsvis brandväggas och placeras så att bara SQL-porten är öppen, och webbservern har bara korrekta rättigheter till denna SQL-server så att SQL-servern är "omöjlig" att fjärradministrera.

Den stora fördelen är då att all deface eller liknande av hemsidan löses genom omstart. Programmet som sköter watchdogen kan ställas in att sluta pinga watchdogen ifall hemsidan deface:as. Vips omstart och hemsidan åter igen.


Den stora fördelen är att det då gör det inget om det är säkerhetshål i webbservern eller operativet som riktar sig ut mot nätet. Det krävs altså ett säkerhetshål i SQL för att något ska hända och med vettigt kofigurerade rättigheter på SQL-servern så kommer man ingen vart. Bara en enda tjänst att säkra upp vettigt.

Du får nog se till att ha korrekta villkor i sådant fall. En ping kommer inte hjälpa om ett shell har startats. Så du får sätta exklusiva villkor, dvs "allt utom detta ska hända".

Att göra det omöjligt att fjärradministrera en SQL-server kan du ju ställa in i MySQL t.ex. Endast login från local borde sättas då. Detta skulle inte hjälpa mot SQL-injektioner så har du någon lösning på det förutom korrekt PHP-kod?

Kan du förklara hur den ska kolla att sidan inte defaca's? Är det helt enkelt att den slutar pinga om något överhuvudtaget ändras på webbservern? Det håller ju inte om det är ett forum t.ex, men förklara för jag har säkert missuppfattat.

Min tanke var att man sätter upp 2 servrar.
En server som är "vänd utåt mot nätet".

Denna server har sitt filsystem på ett SD-kort med WP-switchen satt till ON, dvs du kan fysiskt sett inte skriva till kortet.
Filsystemet är ett "livefilsystem" så att ändringar tillåts fullt ut (ramdisk) men försvinner vid omstart.

På systemet finns en programvara som "pingar" (ping i detta fallet syftas INTE på ICMP utan en signal som t.ex. att RTS/DTR dras hög en ggr i sekunden eller att den skickar ordet "ping" på TxD) en hårdvaruwatchdog, som kan baseras på en 555:a. Hårdvaruwatchdogen drar RESET på moderkortet ifall den inte får signalen tillräckligt ofta, säg att signal uteblir i 5 sek.

Programvaran kan kolla efter alla ändringar. Har du ett forum hämtas ju detta från databasen, dvs det ändrar ju inte hemsidan utan det är något som ligger i databasen.


Därefter har du en annan server som då är SQL-server. SQL-servern är brandväggad och isolerad så den bara tillåter anslutningar på SQL-porten och SQL-porten är stängt ut mot internet.
Det som utgör hemsidan kan ju till exempel basera sig på en användare som bara har läsrättigheter, och sedan ansluter du till liveservern för att sedan ansluta till SQL-servern för att ändra texterna på hemsidan. Givetvis startar man om webbservern innan varje gång man ska ändra för att förhindra att det ligger något på webbservern och lyssnar efter lösenord.


Har man ett forum eller liknande så kan ju forumet ändras utan att någon fil på webbservern behöver ändras. Eventuellt om det går i den SQL-server man för tillfället kör, begränsa genom rättigheter så bara vissa specifika frågor får köras - därmed omöjliggörs SQL-injektion också.

Märker du att servern på något sätt är påverkad eller beter sig konstigt, så kan man ha någon form av fjärrstyrning - säg via SMS som drar RESET-pinnen i 1sek. Servern återställd på ett nafs.

Känns väldigt overkill och det stoppar inte en fysisk attack. Även om det hade stoppat en fysik attack så kan man kopiera hela systemet till en annan disk fast denna disk har en bakdörr i sig. Sedan startar någon om servern som ingenting hade hänt. Sen går det fortfarande att exploita tjänster för du behöver inte skrivrättigheter till det.

SQL-bakdörrar samt kan man skriva filer med MySQL.

Efter varje reboot så är det bara att exploita samma vuln igen, så länge servern körs så är den sårbar.(vi leker med tanken att serven faktiskt är sårbar för remote exec t.ex)


Förstår inte vilka frågor man ska begränsa för att göra SQL-injektioner omöjliga. Det handlar ju endast om att hämta data vilket man alltid gör, men denna data är manipulerad så problemet ligger inte i SQL-förfrågningarna utan endast i koden. Kan tänka mig en proxy för alla förfrågningar för att kontrollera att du hämtar legit data.