SFTP szerver hardening

Fórumok

Mit tennetek ha egy olyan SFTP szervert kene hardenelnetek ahol a userek fel- es letoltenek es semmi masra nincs szukseg?

Nagyvonalakban:
- Umask 077
- Csak CTR cipherek engedelyezese (AES256 es Blowfish) a CBC cipherekben nem bizunk, akkor sem ha az OpenSSHban mindent megtettek a sebehezhetoseg kivedese erdekeben (http://www.mozilla.org/projects/security/pki/nss/news/vaudenay-cbc.html)
- Compression engedelyezve
- checkFile, versionSelect es posixRename SFTP extensionoket engedelyezzuk, copyFile es vendorID extensionokre deny
- Maximum 5 szimultan kapcsolat egy IProl
- A feltoltott fileok jogosultsagait nem vesszuk figyelembe, a umaskot huzzuk ra minden filera
- Csereljuk a keyt bizonyos idokozonkent (mondjuk orankent) a man-in-the-middle tamadasok hatasait csokkentendo
- A forgalomanalizis ellen vedekezzunk azzal, hogy bizonyos idokozonkent random adatokat szurunk be a forgalomba
- minden user chrootba
- Chmod, chown, symlink, lock es setstat tiltasa

Egyeb otlet?

Hozzászólások

az sftp/ssh szervert magát is chrootba tenném, ahol az a chroot úgy van összerakva, hogy
- csillagos legyen a root account passwordje
- minden, ezen chroot alatt elérhető írható mount point nodev,nosuid,noexec legyen (ami nem lehet ilyen, az legyen ro)

ezt az sftp/ssh szervert véletlenül sem a default portra raknám (ne próbálgassák már be állandóan), és "természetesen" ennek a szervernek csak az sftp userek kiszolgálása lenne a feladata.

Esetleg vess egy pillantást ide: http://www.tectia.com

Eme cég Tectia SSH megoldását már több ügyfélnél is láttam az sftp/ssh leváltásával...

"Csereljuk a keyt bizonyos idokozonkent (mondjuk orankent)"

Mar hogy a melyiket?

--
"You're NOT paranoid, we really are out to get you!"

Ha már itt tartunk ez a patch szerintetek elfogadhatóan biztonságos?


--- sftp-server.c	2010-01-13 11:44:06.000000000 +0000
+++ sftp-server3.c	2011-09-07 15:30:23.000000000 +0000
@@ -13,6 +13,12 @@
  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ ************************************************************************
+ * This version modified to provide chroot'd SFTP
+ *
+ * Search for 'Minstrel' in this file to find modifications
+ ************************************************************************
  */
 
 #include "includes.h"
@@ -51,6 +57,10 @@
 #include "sftp.h"
 #include "sftp-common.h"
 
+/* Following single line added by Minstrel */
+
+#define CHROOT
+
 /* helper */
 #define get_int64()			buffer_get_int64(&iqueue);
 #define get_int()			buffer_get_int(&iqueue);
@@ -1441,6 +1451,20 @@ sftp_server_main(int argc, char **argv,
 
 	logit("session opened for local user %s from [%s]",
 	    pw->pw_name, client_addr);
+/* Start additions by Minstrel */
+
+#ifdef CHROOT
+	if(strcmp(pw->pw_shell,"/bin/sftpsh") == 0){
+		if (chroot(pw->pw_dir) != 0)
+			fatal("Couldn't chroot to user directory %s: %s", pw->pw_dir, strerror(errno));
+		else
+			setenv("HOME", "/", 1);
+	}
+#endif
+	if (setuid(getuid()) != 0 || setgid(getgid()) != 0)
+		fatal("Couldn't drop privileges: %s", strerror(errno));
+
+/* End additions by Minstrel */
 
 	in = STDIN_FILENO;
 	out = STDOUT_FILENO;

A légyege hogy setuid-os az sftpserver, és ledobja miután chroot-oldt.
Az is lenne a kérdésem, hogy más ezt hogy szokta megoldani?

Szerk: Válasz a kérdésemre:
Aha:
http://www.debian-administration.org/articles/590

Szóval ez is egy elavult gányolás a részemről. Gondoltam, de csak most vetődött fel a kérdés bennem egyáltalán.

Húzzál rá még valamilyen MAC megoldást, szerintem evidens, chroot-nál mindenképp jobb. Hiába a chroot, ott még azért van shell és kernel exploit-tal próbálkozhat a támadó ha bejutott, igaz-e?

SMS one time password
fail2ban
És két overkill a végére: vmilyen VPN megoldás + xen virtuális gépbe chrootolt SFTP

Sziasztok !

Nálunk ezt a problémát proftpd+mod_sftp -vel oldottuk meg
fix umask-al, virtual userekkel ...