Sécurisation de salles étudiantes Université Toulouse 1

1. Sécurisation de salles étudiantesUniversité Toulouse 1 • Contexte • Définitions & Principes • Socks : Implémentation NEC • Résultats • Analyse et Perspectives

2. Contexte

3. Contexte local • Dominantes juridiques, économiques, gestion • Enseignements et recherche en informatique • 17000 étudiants (Email, Internet) • CRI • Pédagogie (6 personnes), mutualisé • Réseau-Gestion du parc (3 personnes) • Gestion (6 personnes)

4. Contexte Internet • De nombreux outils très « efficaces » • Nessus • Nmap • BackOrifice • Beaucoup d ’inconscience • Internet « Libre »

5. Structure technique • 3 sites (15 bâtiments) hors délocalisations • 3 routeurs France-Télécom • 5 routeurs «internes» • 12 classes C • 1200 machines (360 en pédagogie) • 19 salles pédagogiques en 3 classes C

6. Pourquoi ? • Problèmes antérieurs (incivilités, provocations, ...) • Protéger les secteurs stratégiques de gestion • Détecter les intrusions • Assurer l’image de l’université • Réduire le travail des administrateurs

7. Contraintes • Techniques • Recherche/Pédagogie nécessite l’ouverture de tout protocole IP. • Financières • Humaines • Acquisition des compétences • Temps

8. Comment ? • Isolement des secteurs stratégiques par filtrage sur routeurs • Observation continuelle du réseau (argus) • Installation d’antivirus réseau (Interscan et AMaViS) • Filtrage de la pédagogie par des relais

9. Implémentation locale Mail Squid Socks Argus (audit) Email Web Autres Pédagogie

10. Notre configuration • 360 postes (IPX/IP): • 1 Linux Pentium II 300 Mhz, serveur Socks • ftp, telnet, irc, ... • 1 Linux Pentium 233 Mhz, serveur Squid • http (netscape, internet explorer) • 1 HP serveur mail antiviral

11. Définitions

12. Relais : schéma 1) 2) Réseaux & serveurs distants Réseaux locaux Relais

13. Relais • Interdiction des connexions directes pédagogie/extérieur • Passage obligatoire par des relais • relais applicatifs • relais circuit

14. Principe Relais R R-S Serveur S Règles C-R Accepte Décision Port du relais R-R2 Machine cliente C Redirige Interdit 2ème Relais Logs

15. Relais applicatifs : l’interprète • La communication C-R est conforme au protocole relayé : • R comprend la communication • R peut intervenir dans la connexion • Exemples • Squid : accélère le web , restreint les URLs et efface les bannières publicitaires • Interscan : désinfecte les attachements

16. Relais circuit : la standardiste • La communication C-R encapsule la communication C-S. Elle est spécifique : • Le client demande au relais une communication à l’extérieur • Autorisation basée sur • l’origine (machine, port) • la destination (machine, port) • l’identification ou l’authentification du client

17. Relais circuit : suite • Le relais • place un tunnel de communication avec le serveur • note le début de la communication • clôt le tunnel • note la fin de la communication

18. Relais circuit : les socks • Koblas & Koblas • En version 5 ==> RFC 1928 • Passage UDP en V5 (< 1%) • Passage des ping et traceroute

19. Socks : avantages 1 • Simplicité pour le client • un logiciel client encapsule les communications de manière transparente • Simplicité du serveur relais • un seul daemon à lancer • des règles de filtrage simples • Généralités (presque tout protocole IP)

20. Socks : avantages 2 • Pas de serveur possible (FTP pirate, etc...) • Authentification forte possible • Cryptage possible des communications • Relais en cascade • Coûts faibles • 1 PC suffit • Logiciel client/serveur gratuit

21. Socks : inconvénients • Pas de serveur possible • Pas de contrôle DANS la communication (bien que théoriquement possible) • Nécessité de logiciels clients adaptés • Déjà fait pour de nombreux clients • Piles d’encapsulation • Pas de pile TCP/IP dynamique pour les Mac • 5 clients « socksifiés »

22. Implémentation NEC • http://www.socks.nec.com • Version 1.0 release 8 (sources) • 1 serveur UNIX • 1 librairie cliente dynamique UNIX • 1 librairie cliente dynamique Windows (Sockscap)

23. Serveur NEC • Authentification password ou GSS-API • Supporte l’identd et un moniteur d’accounting. • Peut se lancer en daemon, (normal, preforking, threaded) ou inetd • Peut limiter le nombre de connexions • Recopie totale de transaction

24. Client Sockscap : utilisation

25. Client SocksCap : utilisation

26. Client Sockscap : configuration

27. Les spécificités de Sockscap • Disponible en windows 3.x/9x/NT • Le GSS-API n’est pas intégré • Seuls les logiciels placés dans la fenêtre seront « socksifiés »

28. Autres implémentations • Dante : client/serveur gratuit • Hummingbird : client gratuit • Aventail • Nec en version professionnelle • Netscape Proxy server • Wingate (NT)

29. Résultats

30. Configuration serveur • Tous les protocoles en sortie (hormis Web) • Aucune entrée autorisée • Demande d’ident (pour indication) • Pas d’authentification

31. Fichier configuration set SOCKS5_DEBUG 3 ## Toute méthode d'identification est autorisée auth - - - ## permit auth cmd ## src-host/netmask dest-host/netmask ## src-port dest-port ## [user-list] ## deny - - - {réseaux-internes} - - deny - - - {réseaux-RFC1918} - - deny - - - - - 80 deny - - - - - - INIT permit - - {réseaux-internes} - - - deny - - - - - -

32. Utilisation du serveur socks • Etude sur la semaine du 4 au 9 Janvier • 130 postes clients socks • De 15 à 50 connexions simultanées (2-3 par utilisateur) • 250 utilisateurs socks • Utilisation CPU proche de 1%

33. Nombre de connexions

34. Débit Entrées/Sorties

35. Bilan des socks • Mise en place aisée et rapide • Coût faible (5-10 Kf) • Gains • Calme plat des tentatives d’intrusion internes • Protection contre les attaques externes • Statistiques d’utilisation d’Internet • Complément indispensable aux autres outils (Squid, Interscan, etc...)

36. Conclusion Les socks sont la première marche pour un firewall plus intelligent

37. Annexes • http://cache.univ-tlse1.fr/securite/socks • http://www.socks.nec.com • http://www.socks5.nec.com (commercial) • RFC 1928 (AFT : protocole Socks 5) • RFC 1929 (authentification password) • RFC 1961 (les GSS-API)

38. Autres outils

39. Squid/SquidGuard • http://squid.nlanr.net/Squid • Relais applicatif pour le WWW • Efficacité : 50% en requête, 30% en débit • Linux P233, 128 Mo, 5 Go de disque • 7 Go/semaine • 2% de trafic non souhaitable (4500 URLs) • 30% de CPU

40. FWTK: FireWall ToolKit • http://www.tis.com • http://www.erols.com/avenger • Relais applicatifs • ftp • telnet, X11, rlogin, ssh • smtp • mbone • pop, nntp, IRC

41. Argus • ftp://ftp.sei.cmu.edu/argus • Moniteur connexions IP • Processus de 1Mo le matin à 20 Mo le soir • 40 à 50 lignes chaque matin • Concurrent : Bro 0.5Beta (plus efficace)

42. AMaViS • http://satan-oih.rwth-aachen.de/AMaViS • Lanceur automatique d’antivirus sur mail • Remplace le delivery local • Nécessite un scanner local • Mcafee pour Linux http://www.mcafee.com • Antivir/X http://www.antivir.de

43. Interscan • http://www.trendmicro.fr • Payant (et cher) 65 Kf pour 1000 machines • Passerelle antivirale SMTP/HTTP/FTP

44. Autres implémentations Gratuites ou Payantes

45. Implémentation Hummingbird • http://www.hummingbird.com • Gratuite • Uniquement le client • Remplacement de la pile winsock • Si GSSAPI.DLL est présent il sera utilisé • kerbnet12.zip • Peu convivial (fichier de configuration)

46. Implémentation Dante • http://www.inet.no/dante • Gratuite • Serveur/client • Version Beta 0.91.1

47. Aventail • http://www.aventail.com • Payante • Client : AutoSocks • Serveur :VPN

48. Wingate • http://www.wingate.net • Payante • La plus mauvaise réputation • Tourne sur NT. • Socks n’est qu’un de ses aspects • 700$/1000$ suivant version en utilisateur illimité

49. Netscape proxy-server • http://www.netscape.com/proxy • Payante • Socks est une de ses fonctionnalités

50. Novell Border Manager • http://www.novell.com/bordermanager • Payante • Socks est une de ses fonctionnalités