[aDonis]

Ska precis inhandla min första server som jag kommer konfigurera själv inför en plats på colocation.


Vad bör jag tänka på säkerhetsmässigt (förutom att hålla alla program uppdaterade)?

Hur viktigt/användbart är IMPI-kort? Är det en god investering, har aldrig haft det på en server innan.

Några program som är viktiga?


Vill bara försäkra mig om så jag inte glömt något innan jag slänger in den. Har köpt upp servers förut som stått på colocation redan men som sagt aldrig konfat dessa själv.

[patrikweb]

Kör på server med IPMI eller ännu bättre med ILO/DRAC. Blir dyrt med omstarter annars om den hänger sig i slutändan.

[Danielos]

Det är en hel del att tänka på, ska du köra Linux eller FreeBSD?

[studiox]

Jag skulle nog låta co-lo leverantören configurera den om du aldrig gjort det själv. Det är ju en hel del o tänka på. Eftersom den kommer vara igång dygnet runt, året runt du kanske inte vill åka ut till hallen så fort någon äcklig trojan smittar sig in (om du kör windows) så kan det vara bra och både sätta upp smarta brandväggsregler och stänga av tjänster som inte används (det gäller både windows och linux)

[pkallberg21]

Har lagt ihop lite punkter angående detta. Hoppas det hjälper.

-Install only necessary software; delete or disable everything else.
-Keep all system and application software up-to-date. Subscribe to software and operating system mailing lists to receive updates. Updating Debian: apt-get update and apt-get -u update. Debian mailing lists: http://www.debian.org/mailinglists/subscribe.
-Delete or disable unnecessary user accounts. Check /etc/passwd and comment out any unnecessary entries. If in doubt, use find / -user yard -print to find directories owned. Then use ls -lu directory to gain more information. Check amount of files, and last accessed.
-Don't needlessly grant shell access.
-Allow each service to be publicly accessible only by design, never by default.
-Run each publicly accessible service in a chrooted filesystem (ie., a subset of /). Processes should be run with as low a set of privileges as possible or ran in a chroot jail.
-Don't leave any executable file needlessly set to run with superuser privileges, ie. with its SUID bit set (unless owned by a sufficiently nonprivileged user).
-If your system has multiple administrators, delegate root's authority.
-Configure logging and check logs regularly.
-Configure each host as its own firewall; ie. bastion hosts should have their own packet filters and access controls in addition to (but not instead of) the firewall's.
-Check your work now and then with a security scanner, especially after patches and upgrades.
-Understand and use the security features supported by your operating system and applications, especially when they add redundancy to your security fabric.
-After hardening a bastion host, document its configuration so it may be used as a baseline for similar systems and so you can rebuild it quickly after a system compromise or failure.
-Utilize SSH, not clear-text transfer protocols such as telnet.
-Use SFTP and SCP for encrypted file transfers.
-Edit ssh_config and sshd_config to control the behaviour of the SSH client and server. These can usually be found in /etc.

Edit: Listan kommer från Linux Server Security boken.

[emilv]

Jag rekommenderar att köra SSH på en annan port än 22 och att du kör Denyhosts eller liknande program för att låsa ute IP-adresser efter ett visst antal misslyckade inloggningar. Stäng också av root-inloggningar (över SSH eller helt och hållet).

Kolla upp med hallen vilka regler och priser som gäller för omstart av maskinen och åtkomst till hallen.
Ett kort på egen IP-adress för detta är inte alls en dum idé, men det riskerar att kosta en del extra.

Undvik att tillåta databasuppkopplingar utifrån. Behöver du koppla upp till databasen ska du antingen göra det direkt på maskinen eller genom en SSH-tunnel.

[aDonis]

Ursprungligen postat av patrikweb

Kör på server med IPMI eller ännu bättre med ILO/DRAC. Blir dyrt med omstarter annars om den hänger sig i slutändan.

Ok då blir det ett sådant.

Originally posted by -danielos@Feb 1 2009, 20:22
Det är en hel del att tänka på, ska du köra Linux eller FreeBSD?

Debian.

Originally posted by -pkallberg21@Feb 1 2009, 21:02
Har lagt ihop lite punkter angående detta. Hoppas det hjälper.
-Install only necessary software; delete or disable everything else.
-Keep all system and application software up-to-date. Subscribe to software and operating system mailing lists to receive updates. Updating Debian: apt-get update and apt-get -u update. Debian mailing lists: http://www.debian.org/mailinglists/subscribe.
-Delete or disable unnecessary user accounts. Check /etc/passwd and comment out any unnecessary entries. If in doubt, use find / -user yard -print to find directories owned. Then use ls -lu directory to gain more information. Check amount of files, and last accessed.
-Dont needlessly grant shell access.
-Allow each service to be publicly accessible only by design, never by default.
-Run each publicly accessible service in a chrooted filesystem (ie., a subset of /). Processes should be run with as low a set of privileges as possible or ran in a chroot jail.
-Dont leave any executable file needlessly set to run with superuser privileges, ie. with its SUID bit set (unless owned by a sufficiently nonprivileged user).
-If your system has multiple administrators, delegate roots authority.
-Configure logging and check logs regularly.
-Configure each host as its own firewall; ie. bastion hosts should have their own packet filters and access controls in addition to (but not instead of) the firewalls.
-Check your work now and then with a security scanner, especially after patches and upgrades.
-Understand and use the security features supported by your operating system and applications, especially when they add redundancy to your security fabric.
-After hardening a bastion host, document its configuration so it may be used as a baseline for similar systems and so you can rebuild it quickly after a system compromise or failure.
-Utilize SSH, not clear-text transfer protocols such as telnet.
-Use SFTP and SCP for encrypted file transfers.
-Edit ssh_config and sshd_config to control the behaviour of the SSH client and server. These can usually be found in /etc.
Edit: Listan kommer från http://books.google.com/books?id=F1FquvLFo...=result#PPP1,M1 boken.

Du är underbar, funderar nästan på att köpa boken bara för det.

Ursprungligen postat av emilv

Jag rekommenderar att köra SSH på en annan port än 22 och att du kör Denyhosts eller liknande program för att låsa ute IP-adresser efter ett visst antal misslyckade inloggningar. Stäng också av root-inloggningar (över SSH eller helt och hållet).
Kolla upp med hallen vilka regler och priser som gäller för omstart av maskinen och åtkomst till hallen.
Ett kort på egen IP-adress för detta är inte alls en dum idé, men det riskerar att kosta en del extra.
Undvik att tillåta databasuppkopplingar utifrån. Behöver du koppla upp till databasen ska du antingen göra det direkt på maskinen eller genom en SSH-tunnel.

Check!



Tack allesammans, riktigt bra tips. Tror nog jag ska kunna knåpa ihop detta själv minsann!

[Jonas]

Originally posted by aDonis@Feb 1 2009, 23:50

Du är underbar, funderar nästan på att köpa boken bara för det.

http://www.bokus.com/b/9780596006709.html

Billigaste jag hittade i Sverige.

(Annars kika här: http://www.bokpris.se/0596006705 )

Lite onödigt att slänga ut dubbla summan hos O'Reilly

[Magnus_A]

Ta gärna bort inloggningen på ssh och kör endast med nyckelpar. Då är det din(a) dator(er) och endast den(m) som kan ansluta.

[KristianE]

Magnus:
Risken finns ju att något händer med nyckeln och då är han
ganska rökt. Beror lite på ILO-kortet visserligen..

Men byt port för SSH. Installera Fail2Ban och konfigurera den
för att blocka brute-force-attacker.

Och förstås det som ingen här har nämnt:

STARKA LÖSENORD. Minst 15 tecken, från alla fyra grupper;
versaler (A)
gemener (b)
siffror (1)
tecken (€)

Det finns en femte grupp som är grymt effektiv. Så länge du
använder ett svenskt tangentbord - ÅÄÖ. De räknas som
metatecken och används inte direkt i dictionary attacks.. :)