OpenBSD php/MySQL till chrootat Apache?

Permalänk
Medlem

OpenBSD php/MySQL till chrootat Apache?

Apache verkar man ju få färdigt i jail (om man så vill), men hur är det om man vill ha php och MySQL tillsammans med Apache?
Finns det färdiga paket från OpenBSD som fixar allt automatiskt, eller måste man helt manuellt böka in dessa i sin chroot???
Verkar inte vara så enkelt eller trevligt att fixa sånt och sedan vara säker på att allt blev korrekt och säkert, så om det finns nåt som fixar det automatiskt vore det ju skönt.

Inte för att jag ska byta upp mig nu men när servern dyker blir det nog OpenBSD nästa gång. Verkar bra om man inte är så haj på UNIX, att OpenBSD är så säkrat från början. Ska man bara ha webserver och filserver så är det ju skit samma om massa annat är avstängt eller svårt och knöligt att få igång.

Vet förövrigt inte så mycket om chroot, så om nån anser att det är onödigt eller dåligt av någon anledning är jag intresserad av att höra argument för/emot

Tack

Visa signatur

CCNA sedan juni 2006

Permalänk
Hedersmedlem

PHP är bara att installera, det fungerar fint direkt.

MySQL är lite pillande med men inga större problem.
Detta kräver dock att /var/www ligger på samma partition som /var, annars fungerar inte hårdlänken...
I /etc/rc.local:

# MySQLd if [ -x /usr/local/libexec/mysqld ]; then /usr/bin/install -d -o _mysql -g _mysql /var/run/mysql echo -n " mysqld"; /usr/local/libexec/mysqld & for i in 1 2 3 4 5 6; do if [ -S /var/run/mysql/mysql.sock ]; then break else sleep 1 echo -n "." fi done # Apache chroot /bin/mkdir -p /var/www/var/run/mysql sleep 2 /bin/ln -f /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock fi

Du kan behöva ändra sökvägen till mysql.sock i php.ini.

Visa signatur

Vim
Kinesis Classic Contoured (svart), Svorak (A5)
Medlem i signaturgruppen Vimzealoter.

Permalänk
Medlem

Oj, inte mycket man förstod

Men hur kommer det sig att php fungerar med vanlig installation? Är det så att det hamnar i chroot automatiskt? Eller är det så att det inte behövs, även fast php verkar kunna exploitas en del...

Vad skulle hända om man installerar MySQL som vanligt? Kommer det inte fungera då?

Synpunkter på chroot i allmänhet, någon?

Visa signatur

CCNA sedan juni 2006

Permalänk
Inaktiv
Citat:

Ursprungligen inskrivet av Seb74
Oj, inte mycket man förstod

Synpunkter på chroot i allmänhet, någon?

Jag använder verktyg som loggar systemanrop från angiven process så att man kan se vilka filer och bibliotek som behövs om man gör det manuellt.

Chroot är ett säkerhets-hack tycker jag, ingen långsiktig lösning. Det är en del att tänka på för att förhindra att någon tar sig ut.

  • inga suid-root binärer

  • inte köra något som root i chroot

  • root bör äga alla filer och de skall inte vara skrivbara av någon annan

  • inte köra någon process utanför som körs av samma användare som servern

  • inte erbjuda något skal i chroot:et

  • inte tillåta exekvering av binärer i kataloger där uppladdat material hamnar (annars finns det möjlighet att ladda upp kompilatorer, skal och alla de verktyg som kan tänkas behövas om man skall bryta sig ur)

  • etc etc

Verklig separation är den rätta vägen och jag hoppas att Xen (och hårdvaran) utvecklas så att man kan konsolidera servrar utan risk för att domäner sniffar PCI-bussar och liknande elakheter. Amd har ju IOMMU och det är ju ett steg i rätt riktning...

Om du är _riktigt_ paranoid kan du köra:

  • använda en hårdvaru-platform som har stöd för separering av data och kod i stacken (sidvis), exempel alpha eller amd64

  • Apache med minimalt antal moduler

  • chroot

  • PF som bara tillåter anslutningar till port 80 (stoppa all trafik ut som inte är svar på en förfrågan)

  • systrace

  • securelevel 2, dock verkar OpenBSD skita i securelevels. NetBSD's securelevel 2 förhindrar t ex att man monterar om endast läsbara diskar till läs- och skrivbara, även om man är root

  • endast läsbara diskar (du får skapa skrivbara partitioner för loggar och uppladdat material)

  • använder noexec, nodev, nosuid etc på skrivbara områden

  • tar bort allt onödigt på servern, framförallt suid- och sgid-binärer som inte används, du kan ta bort dessa bitar också om du vill ha kvar programmen

  • och självklart uppdaterar mjukvaran regelbundet

  • använda mod_security och/eller snort

  • endast tillåta inloggning lokalt (vilket du måste göra ändå om du använder securelevels eftersom man måste gå ner i singleuser för att kunna montera om diskarna vid uppdateringar)

Kanske inte den mest smidiga lösningen ur underhållssynpunkt men några steg mot en säkrare server...

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av mickeus
Jag använder verktyg som loggar systemanrop från angiven process så att man kan se vilka filer och bibliotek som behövs om man gör det manuellt.

Chroot är ett säkerhets-hack tycker jag, ingen långsiktig lösning. Det är en del att tänka på för att förhindra att någon tar sig ut.

  • inga suid-root binärer

  • inte köra något som root i chroot

  • root bör äga alla filer och de skall inte vara skrivbara av någon annan

  • inte köra någon process utanför som körs av samma användare som servern

  • inte erbjuda något skal i chroot:et

  • inte tillåta exekvering av binärer i kataloger där uppladdat material hamnar (annars finns det möjlighet att ladda upp kompilatorer, skal och alla de verktyg som kan tänkas behövas om man skall bryta sig ur)

  • etc etc

Verklig separation är den rätta vägen och jag hoppas att Xen (och hårdvaran) utvecklas så att man kan konsolidera servrar utan risk för att domäner sniffar PCI-bussar och liknande elakheter. Amd har ju IOMMU och det är ju ett steg i rätt riktning...

Om du är _riktigt_ paranoid kan du köra:

  • använda en hårdvaru-platform som har stöd för separering av data och kod i stacken (sidvis), exempel alpha eller amd64

  • Apache med minimalt antal moduler

  • chroot

  • PF som bara tillåter anslutningar till port 80 (stoppa all trafik ut som inte är svar på en förfrågan)

  • systrace

  • securelevel 2, dock verkar OpenBSD skita i securelevels. NetBSD's securelevel 2 förhindrar t ex att man monterar om endast läsbara diskar till läs- och skrivbara, även om man är root

  • endast läsbara diskar (du får skapa skrivbara partitioner för loggar och uppladdat material)

  • använder noexec, nodev, nosuid etc på skrivbara områden

  • tar bort allt onödigt på servern, framförallt suid- och sgid-binärer som inte används, du kan ta bort dessa bitar också om du vill ha kvar programmen

  • och självklart uppdaterar mjukvaran regelbundet

  • använda mod_security och/eller snort

  • endast tillåta inloggning lokalt (vilket du måste göra ändå om du använder securelevels eftersom man måste gå ner i singleuser för att kunna montera om diskarna vid uppdateringar)

Kanske inte den mest smidiga lösningen ur underhållssynpunkt men några steg mot en säkrare server...

Just det, "ldd" verkar man ha användning för när man ska sätta upp jails....verkar rätt omständigt och avancerat för en newbie.

Kom på det också att det kanske blir rätt opraktiskt att ha Apache och htdocs i jail när man som jag har det i sambas share så att windowsburkarna kan kopiera in filer till htdocs utan något strul.
Ska det ligga i jail och root äga allt, ja, då är det ju adjöss med den smidigheten...antar jag.

Visa signatur

CCNA sedan juni 2006

Permalänk
Hedersmedlem
Citat:

Ursprungligen inskrivet av Seb74
Just det, "ldd" verkar man ha användning för när man ska sätta upp jails....verkar rätt omständigt och avancerat för en newbie.

Kom på det också att det kanske blir rätt opraktiskt att ha Apache och htdocs i jail när man som jag har det i sambas share så att windowsburkarna kan kopiera in filer till htdocs utan något strul.
Ska det ligga i jail och root äga allt, ja, då är det ju adjöss med den smidigheten...antar jag.

Det är inget strul alls, du gör bara en share av /var/www/htdocs också. Att apache är chrootat gör ingen skillnad för samba. Root måste inte vara ägare till alla filer, däremot skall den användare apache körs under inte vara ägare till något och inte ha skrivrätt till något, vilket är precis så som /var/www-strukturen är ordnad från installation.

Citat:

securelevel 2, dock verkar OpenBSD skita i securelevels.

OpenBSD har securelevels och de fungerar som beskrivet i manualen. däremot är det inte identiskt med NetBSDs implementation.

Citat:
  • endast tillåta inloggning lokalt (vilket du måste göra ändå om du använder securelevels eftersom man måste gå ner i singleuser för att kunna montera om diskarna vid uppdateringar)

Kanske inte den mest smidiga lösningen ur underhållssynpunkt men några steg mot en säkrare server...

Att inte kunna installera säkerhetsuppdateringar och liknande utan att fysiskt befinna sig vid servern kan lika gärna vara katastrofalt för säkerheten, beroende på hur den eller du är placerad. och då halkade vi också in på varför securelevels fungerar lite annorlunda i OpenBSD..

Visa signatur

Det kan aldrig bli fel med mekanisk destruktion

Permalänk
Medlem

Ah, tack. Ja man kan såklart skaffa en samba utdelning till ju som pekar in i chroot....eller iallafall htdocs (eller om den nu kallades www).

Undrar dock varfrö php funkar direkt att bara installera medans MySQL kräver massa krångligt strul.

Visa signatur

CCNA sedan juni 2006

Permalänk
Hedersmedlem
Citat:

Ursprungligen inskrivet av Seb74
Undrar dock varfrö php funkar direkt att bara installera medans MySQL kräver massa krångligt strul.

Den chroot-moddade Apache som finns i OpenBSD laddar in sina moduler (php bl a), öppnar log-filer och sånt innan den går ner i chrooten och släpper root-privs. Mysql är däremot ett fristående program som webservern inte har någon kontroll över.

Visa signatur

Det kan aldrig bli fel med mekanisk destruktion

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Aphex
Den chroot-moddade Apache som finns i OpenBSD laddar in sina moduler (php bl a), öppnar log-filer och sånt innan den går ner i chrooten och släpper root-privs. Mysql är däremot ett fristående program som webservern inte har någon kontroll över.

Aha, ok, tack för svaret
Synd dom inte kunde fixa en färdig chroot till MySQL också...lär ju inte va många som kör Apache utan MySQL.....eller iofs finns ju några andra databaser att välja mellan också så det kanske skulle bli för mycket jobb för dom.

Men antar att det är antingen Apache OCH MySQL i samma chroot, eller också inget av dom i nån jail överhuvudtaget.

Visa signatur

CCNA sedan juni 2006

Permalänk
Inaktiv
Citat:

Ursprungligen inskrivet av Aphex
OpenBSD har securelevels och de fungerar som beskrivet i manualen. däremot är det inte identiskt med NetBSDs implementation.
Att inte kunna installera säkerhetsuppdateringar och liknande utan att fysiskt befinna sig vid servern kan lika gärna vara katastrofalt för säkerheten, beroende på hur den eller du är placerad. och då halkade vi också in på varför securelevels fungerar lite annorlunda i OpenBSD..

Lite mer om skillnaden mellan OpenBSD's och NetBSD's implementation, mer specifikt ett säkerhetshål som upptäckts i OpenBSD's variant. Securelevels kom till för att förhindra/förminska möjligheterna för en cracker som fått root att skada maskinen.

Citat:

No fix will be released for OpenBSD. To quote Theo de Raadt:
"Sorry, we are going to change nothing. Securelevels are useless."

Citat:

NetBSD isn't vulnerable, and I doubt that implementing their solution (don't allow mounts at all at securelevel 2, unless they're just downgrading a file system to read-only) would be very difficult.

Källa http://www.securityfocus.com/columnists/380

Har man möjlighet så kan securelevels 2 vara användbart (förutsatt att man kör NetBSD). Har man fysisk tillgång till maskinen så ser jag inga nackdelar med att använda det...

ldd fungerar men ktruss och ktrace är bättre (jag antar att OpenBSD har något liknande).

Permalänk
Hedersmedlem
Citat:

Ursprungligen inskrivet av mickeus
Lite mer om skillnaden mellan OpenBSD's och NetBSD's implementation, mer specifikt ett säkerhetshål som upptäckts i OpenBSD's variant.

Källa http://www.securityfocus.com/columnists/380

Har man möjlighet så kan securelevels 2 vara användbart (om man kör NetBSD). Ett alternativ är att använda hårddiskar som har en switch eller bygel för att inaktivera skrivning. Har man fysisk tillgång till maskinen så ser jag inga nackdelar med att använda det...

Sen har vi ju level 1 också...

Att du eller någon annan inte gillar hur OpenBSD är designat eller tycker att det saknar en feature betyder inte att det har ett säkerhetshål.. Kom ihåg att det du talar om kräver root-privs.. att kunna göra ALLT när man är root är knappast att betrakta som ett säkerhetshål, det är så unix alltid fungerat.

Securelevels under OpenBSD gör precis vad det är spec:at att göra, att i första hand förhindra modifikation av filer som skyddas av immutable-flaggor, plus lite annat. Det har aldrig varit tänkt att vara något totalskydd mot intrång eller att kunna hålla systemet säkert även om en hacker lyckas bli root, vilket det knappast klarar i något annat OS heller, även om en del gärna inbillar sig det.

För övrigt verkar FreeBSD inte heller ha ansett det vara något säkerhetshål, mtp att inga relaterade advisories dykt upp hos dem.

Visa signatur

Det kan aldrig bli fel med mekanisk destruktion

Permalänk
Hedersmedlem
Citat:

Ursprungligen inskrivet av Seb74
Men antar att det är antingen Apache OCH MySQL i samma chroot, eller också inget av dom i nån jail överhuvudtaget.

m0REc gav ju lite shell-kod som startar mysql och länkar in dess socket i www-chrooten, så det ska nog funka fint att ha mysql på utsidan.

Visa signatur

Det kan aldrig bli fel med mekanisk destruktion

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Aphex
m0REc gav ju lite shell-kod som startar mysql och länkar in dess socket i www-chrooten, så det ska nog funka fint att ha mysql på utsidan.

Ok, jag förstod inte alls vad koden skulle göra.
Gillar heller inte att "skriva av" saker utan att fatta något....jag kanske gör detta om någon månad och då kanske det är nån ny version av någonting som gör att det inte funkar exakt såhär längre. Känns lite trist att det ska va så bökigt, att man måste vara shellprogrammerare för att få MySQL att funka med chrootat Apache, men det är ju så det brukar va med UNIX, har man inte full koll på allt så är det svårt med det mesta.

Visa signatur

CCNA sedan juni 2006

Permalänk
Hedersmedlem

Det där är egentligen inget avancerat shellskript och jag kan beskriva lite vad det gör (det finns dessutom ett antal varianter av det vilka kan hittas i guider om man söker på exempelvis "openbsd apache chroot mysql".

Först kollas det så att mysqld existerar (ingen mening att försöka starta det annars ), därefter skapas katalogen /var/run/mysql med _mysql:_mysql som ägare, sedan startas mysqld.

Därefter så kollar vi i sex sekunder om /var/run/mysql/mysql.sock skapats (för varje sekund skrivs en punkt ut). När det är klart skapas katalogen /var/www/var/run/mysql och väntar i två sekunder på att det innan ska bli klart. Sedan skapar vi en hårdlänk från /var/run/mysql/mysql.sock till /var/www/var/run/mysql/mysql.sock (skriver över den om den redan existerar).

Tänk på att när man pratar om / i ett chroot jail så pratar man om katalogen som man chrootas i (/var/www i det här fallet), så om man skriver /etc/fil.conf i en konfigurationsfil som körs efter chrootningen så kommer programmet att leta i /var/www/etc/fil.conf, likaså är det därför som PHP:s moduler installeras i /var/www/lib/php/modules.

EDIT: För den delen så behöver man faktiskt inte göra såhär, man kan lika gärna strunta i att utnyttja UNIX-socketen och använda sig av TCP-sockets istället (använda 127.0.0.1 istället för localhost i PHP-skripts). Man slipper då hårdlänka in mysql.sock i chroot jailet.

Visa signatur

Vim
Kinesis Classic Contoured (svart), Svorak (A5)
Medlem i signaturgruppen Vimzealoter.

Permalänk
Inaktiv
Citat:

Ursprungligen inskrivet av Aphex
Att du eller någon annan inte gillar hur OpenBSD är designat eller tycker att det saknar en feature betyder inte att det har ett säkerhetshål.. Kom ihåg att det du talar om kräver root-privs.. att kunna göra ALLT när man är root är knappast att betrakta som ett säkerhetshål, det är så unix alltid fungerat.

Securelevels under OpenBSD gör precis vad det är spec:at att göra, att i första hand förhindra modifikation av filer som skyddas av immutable-flaggor, plus lite annat. Det har aldrig varit tänkt att vara något totalskydd mot intrång eller att kunna hålla systemet säkert även om en hacker lyckas bli root, vilket det knappast klarar i något annat OS heller, även om en del gärna inbillar sig det.

För övrigt verkar FreeBSD inte heller ha ansett det vara något säkerhetshål, mtp att inga relaterade advisories dykt upp hos dem.

Ok, det kanske låter som om jag inte gillar OpenBSD, men det gör jag (eller vissa delar av det iaf).

Jag vet att det kräver root-behörigheter och det är det som är hela poängen. Det finns betydligt bättre verktyg (systrace) men hela iden med securelevels är att förhindra root från att göra vissa saker under drift. Som du säger så är det inget totalförsvar mot attacker, men kan potentiellt minska skadorna av dessa.

Om du läste beskrivningen av problemet kan man montera filsystem ovanpå ett existerande och modifiera valfria filer, även de som har immutable-flaggor satta genom att skapa en ny fil ovanpå den gamla. Om detta är en del av spec:en kanske det inte ska kallas säkerhetshål, det hamnar nog under problem med designen. Securelevels på OpenBSD ger en falsk känsla av trygghet och borde därmed inte användas, modifieras för att förhindra montering av filsystem eller tas bort helt.

Och det är nog smidigast att kommunicera över localhost, men lite långsammare skulle jag tro än än domän-socket.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av m0REc
Det där är egentligen inget avancerat shellskript och jag kan beskriva lite vad det gör (det finns dessutom ett antal varianter av det vilka kan hittas i guider om man söker på exempelvis "openbsd apache chroot mysql".

Först kollas det så att mysqld existerar (ingen mening att försöka starta det annars ), därefter skapas katalogen /var/run/mysql med _mysql:_mysql som ägare, sedan startas mysqld.

Därefter så kollar vi i sex sekunder om /var/run/mysql/mysql.sock skapats (för varje sekund skrivs en punkt ut). När det är klart skapas katalogen /var/www/var/run/mysql och väntar i två sekunder på att det innan ska bli klart. Sedan skapar vi en hårdlänk från /var/run/mysql/mysql.sock till /var/www/var/run/mysql/mysql.sock (skriver över den om den redan existerar).

Tänk på att när man pratar om / i ett chroot jail så pratar man om katalogen som man chrootas i (/var/www i det här fallet), så om man skriver /etc/fil.conf i en konfigurationsfil som körs efter chrootningen så kommer programmet att leta i /var/www/etc/fil.conf, likaså är det därför som PHP:s moduler installeras i /var/www/lib/php/modules.

EDIT: För den delen så behöver man faktiskt inte göra såhär, man kan lika gärna strunta i att utnyttja UNIX-socketen och använda sig av TCP-sockets istället (använda 127.0.0.1 istället för localhost i PHP-skripts). Man slipper då hårdlänka in mysql.sock i chroot jailet.

Aha, tack, förstår lite mer
Men det känns som att mycket av det där är sånt man kan göra manuellt....skapa kataloger här, skapa hårdlänken där.
Vet faktiskt inte om det här scriptet är något man ska köra vid installation, eller efter installation som ett startupscript? Kanske uppenbart, men jag är inte så insatt i vad som händer ändå så

Och menar du att om man skiter i att kunna skriva localhost och istället kör 127.0.0.1 (vad nu det där med UNIX-socks vs TCP-socks handlar om) så slipper man hur mycket av strulet?

Visa signatur

CCNA sedan juni 2006

Permalänk
Hedersmedlem

Lägg de där raderna i /etc/rc.local så körs MySQL igång vid startup.

Om man använder 127.0.0.1 istället för localhost så kommunicerar man med servern via nätverket (TCP-sockets) istället för via filsystemet (UNIX-sockets) och därmed spelar chrooten ingen roll, eftersom att vi inte pratar med MySQL via filsystemet som är chrootat.

Men som sagt, det där är knappast struligt så det finns ingen direkt anledning att strunta i det.

Visa signatur

Vim
Kinesis Classic Contoured (svart), Svorak (A5)
Medlem i signaturgruppen Vimzealoter.

Permalänk
Hedersmedlem
Citat:

Ursprungligen inskrivet av mickeus
Om du läste beskrivningen av problemet kan man montera filsystem ovanpå ett existerande och modifiera valfria filer, även de som har immutable-flaggor

Men du kan inte modifiera orginalen, bara kopiorna.. Loggfiler med sappnd kan t ex inte rensas och schg på rätt ställen kan förhindra att ändringar som kräver en reboot genomförs.
Syftet är att skydda mot bestående ändringar, inte att försöka hålla liv i det körande systemets integritet eftersom den måste anses förlorad samma ögonblick som hackern blev root.
[QUOTE] satta genom att skapa en ny fil ovanpå den gamla. Om detta är en del av spec:en kanske det inte ska kallas säkerhetshål, det hamnar nog under problem med designen. Securelevels på OpenBSD ger en falsk känsla av trygghet och borde därmed inte användas, modifieras för att förhindra montering av filsystem eller tas bort helt.[/QUOTE]Skall det tas bort för att det inte matchar netbsd-användares förväntningar? OpenBSD och FreeBSD anser tydligen inte att det partiella skydd man får för det körande systemet är värt att offra möjligheten att mounta enheter för. Du kan fortfarande göra det om du tycker det är viktigt, men det är inte en del av securelevels.

Om det ger en falsk känsla av säkerhet så är det för att folk tänker "yay, levla upp min säkerhet till +3 tack!" istället för att försöka förstå vilka konsekvenser inställningen får, vad den är tänkt att skydda mot och vilka begränsningar den har.
Detta är inget problem som är unikt för OpenBSD.

Visa signatur

Det kan aldrig bli fel med mekanisk destruktion

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av m0REc
Lägg de där raderna i /etc/rc.local så körs MySQL igång vid startup.

Om man använder 127.0.0.1 istället för localhost så kommunicerar man med servern via nätverket (TCP-sockets) istället för via filsystemet (UNIX-sockets) och därmed spelar chrooten ingen roll, eftersom att vi inte pratar med MySQL via filsystemet som är chrootat.

Men som sagt, det där är knappast struligt så det finns ingen direkt anledning att strunta i det.

Aha, så det funkar.
Men, då sätter man alltså inte MySQL i jail?
Och varför strula i så fall? Är det bara att installera MySQL som vanligt om man kör 127.0.0.1 istället för localhost?

Är det förresten samma i XP? Att det är skillnad på 127.0.0.1 och localhost, eller är det bara alias i hostfilen?

Visa signatur

CCNA sedan juni 2006

Permalänk
Medlem

localhost är hostnamnet för 127.0.0.1.

Så localhost är samma sak som att skriva ip-adressen 127.0.0.1

Visa signatur

Kriga mot min brute: http://gunnard.se.mybrute.com om du vågar :D

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av GunnarD
localhost är hostnamnet för 127.0.0.1.

Så localhost är samma sak som att skriva ip-adressen 127.0.0.1

Tydligen inte i UNIX/Linux då?

Visa signatur

CCNA sedan juni 2006

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Seb74
Tydligen inte i UNIX/Linux då?

Jodå, titta i /etc/hosts så ser du en rad liknande denna:

127.0.0.1 localhost.localdomain localhost

Du kan ju också prova att ping'a localhost:

$ ping localhost PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.183 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.079 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.078 ms --- localhost ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2020ms rtt min/avg/max/mdev = 0.078/0.113/0.183/0.050 ms $

Fungerar på samma sätt på alla OS som använder TCP/IP.

Visa signatur

Kriga mot min brute: http://gunnard.se.mybrute.com om du vågar :D

Permalänk
Inaktiv
Citat:

Ursprungligen inskrivet av Aphex
Om det ger en falsk känsla av säkerhet så är det för att folk tänker "yay, levla upp min säkerhet till +3 tack!" istället för att försöka förstå vilka konsekvenser inställningen får, vad den är tänkt att skydda mot och vilka begränsningar den har.
Detta är inget problem som är unikt för OpenBSD.

Där är vi helt överrens, det faligaste är att man tror att det finns någon magisk switch man kan slå på så är allt frid och fröjd, ta exemplet brandväggar.

Citat:

On the Internet, it doesn't take many licks to get to the center of that bonbon.

Permalänk
Hedersmedlem

Angående localhost vs. 127.0.0.1, ja det är samma sak, men MySQL-libet tolkar dem olika.

Citat:

Från PHPs hemsida (http://php.net/mysql_connect)
Note: Whenever you specify "localhost" or "localhost:port" as server, the MySQL client library will override this and try to connect to a local socket (named pipe on Windows). If you want to use TCP/IP, use "127.0.0.1" instead of "localhost".

(jag sa aldrig att localhost och 127.0.0.1 skiljde sig åt i systemet, remember? )

Visa signatur

Vim
Kinesis Classic Contoured (svart), Svorak (A5)
Medlem i signaturgruppen Vimzealoter.

Permalänk
Medlem

Aha

Visa signatur

CCNA sedan juni 2006