aboutsummaryrefslogtreecommitdiff
path: root/it_IT.ISO8859-15/books/handbook/security/chapter.xml
blob: 6d983c6e333baca7ce47708e0313d87cce31560e (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
<?xml version="1.0" encoding="iso-8859-15" standalone="no"?>
<!--
     The FreeBSD Italian Documentation Project

     $FreeBSD$
     Original revision: 1.312
-->

<chapter id="security">
  <chapterinfo>
    <authorgroup>
      <author>
        <firstname>Matthew</firstname>

        <surname>Dillon</surname>

        <contrib>La maggior parte di questo capitolo  stata presa
          dalla manual page security(7) di </contrib>
      </author>
    </authorgroup>
  </chapterinfo>

  <title>Sicurezza</title>

  <indexterm><primary>security</primary></indexterm>

  <sect1 id="security-synopsis">
    <title>Sinossi</title>

    <para>Questo capitolo d un'introduzione di base sui concetti dei
      sistemi di sicurezza, alcune buone regole di comportamento e alcuni
      argomenti avanzati per &os;.  Molti degli argomenti qua trattati possono
      essere applicati anche ai sistemi e alla sicurezza su Internet in
      generale.  Internet non  pi il luogo
      <quote>amichevole</quote> dove ognuno vuole essere il tuo gentile vicino.
      Mettere in sicurezza il tuo sistema  un imperativo per la
      protezione dei tuoi dati, della tua propriet intelletuale, del tuo
      tempo e molto altro dalla mano di hacker e simili.</para>

    <para>&os; d un insieme di utility e di meccanismi per assicurare
      l'integrit e la sicurezza del tuo sistema e della tua rete.</para>

    <para>Dopo la lettura di questo capitolo, conoscerai:</para>

    <itemizedlist>
      <listitem>
        <para>Concetti di base dei sistemi di sicurezza, rispetto a &os;.</para>
      </listitem>

      <listitem>
        <para>Vari meccanismi di crittografia disponibili in &os;,
          come <acronym>DES</acronym> e <acronym>MD5</acronym>.</para>
      </listitem>

      <listitem>
        <para>Come configurare l'autenticazione OTP (password a singolo
          uso).</para>
      </listitem>

      <listitem>
        <para>Come configurare i <acronym>TCP</acronym> Wrapper per l'uso con
          <command>inetd</command>.</para>
      </listitem>

      <listitem>
        <para>Come configurare <application>KerberosIV</application> su
          &os;.</para>
      </listitem>

      <listitem>
        <para>Come configurare <application>Kerberos5</application> su &os; 5.0
          o successivi.</para>
      </listitem>

      <listitem>
        <para>Come configurare IPsec e creare una <acronym>VPN</acronym> tra
          macchine &os;/&windows;.</para>
      </listitem>

      <listitem>
        <para>Come configurare e usare <application>OpenSSH</application>,
          l'implementaizone <acronym>SSH</acronym> usata da &os;.</para>
      </listitem>

      <listitem>
        <para>Cosa sono le <acronym>ACL</acronym> del file system e come
          usarle.</para>
      </listitem>

      <listitem>
        <para>Come usare l'utility <application>Portaudit</application> per
          monitorare i pacchetti software di terze parti installati dalla
          Ports Collection.</para>
      </listitem>

      <listitem>
        <para>Come utilizzare le pubblicazioni sugli avvisi di sicurezza di
          &os;.</para>
      </listitem>

      <listitem>
        <para>Avere un'idea di cosa sia il Process Accounting e come abilitarlo
          su &os;.</para>
      </listitem>
    </itemizedlist>

    <para>Prima di leggere questo capitolo dovresti:</para>

    <itemizedlist>
      <listitem>
        <para>Capire concetti base di &os; e Internet.</para>
      </listitem>
    </itemizedlist>

    <para>Altri argomenti inerenti la sicurezza sono trattati in altre parti di
      questo libro.  Ad esempio i meccanismy di MAC sono discussi in <xref
      linkend="mac"/> e la gestione dei firewall in <xref
      linkend="firewalls"/>.</para>
  </sect1>


  <sect1 id="security-intro">
    <title>Introduzione</title>

    <para>La sicurezza  una funzione che inizia e finisce con
      l'amministratore di sistema.  Nonostante ogni sistema multi-utente &unix;
      BSD abbia della sicurezza insita, il lavoro di costruire e mantenere
      meccanismi di sicurezza aggiuntivi in modo da mantenere
      <quote>onesti</quote> gli utenti  probabilmente uno dei maggiori
      lavori di un amministratore di sistema.  La macchine sono sicure solo
      quanto le si rende e le richieste di sicurezza si scontrano sempre con
      l'umana necessit per la comodit.  I sistemi &unix;, in
      generale, sono capaci di eseguire un gran numero di processi contemporanei
      e ognuno di questi processi opera come server &mdash; nel senso che
      entit esterne possono connettersi e parlarci.  Mentre i mini e i
      mainframe di ieri diventano i desktop di oggi, mentre i computer diventano
      interconnessi e internet-connessi, la sicurezza diventa un problema
      sempre maggiore.</para>

    <!--DELETED
    <para>Il modo migliore per implementare la sicurezza  con un
      approccio <quote>a cipolla</quote>.  In pratica, quello che vuoi fare
       creare tanti livelli di sicurezza quanto  conveniente e
      poi tenere sotto controllo il sistema per vedere eventuali intrusioni.
      Non vuoi esagerare nella sicurezza o interferirai con l'individuazione e
      quest'ultima  una delle parti pi importanti di ogni
      meccanismo di sicurezza.  Per esempio, ha poco senso imopstare il flag
      <literal>schg</literal> (vedi &man.chflags.1;) su ogni binario di sistema
      dato che questo potr s proteggere temporaneamente i
      binari, ma evita che l'attaccante faccia una modifica facilmente
      individuabile e potrebbe far in modo che il tuo meccanismo di sicurezza
      non individui l'attaccante del tutto.</para>-->

    <para>La sicurezza di un sistema riguarda anche il gestire varie forme di
      attacco, compresi attacchi che tentano di bloccare, o comunque rendere
      inusabile, il sistema, anche se non necessariamente cercano di
      compromettere l'account di root <username>root</username> (<quote>rompere
      root</quote>).  I problemi di sicurezza possono essere suddivisi in
      svariate categorie:</para>

    <orderedlist>
      <listitem>
        <para>Attacchi che limitano la disponibilit dei servizi
          (<quote>Denial of service</quote> o, in breve, DoS).</para>
      </listitem>

      <listitem>
        <para>Compromissione degli account utente.</para>
      </listitem>

      <listitem>
        <para>Compromissione di root tramite server accessibili.</para>
      </listitem>

      <listitem>
        <para>Compromissione di root tramite gli account utente.</para>
      </listitem>

      <listitem>
        <para>Crazione di backdoor (letteralmente <quote>porte sul
            retro</quote>, ovvero accessi secondari personalizzati).</para>
      </listitem>
    </orderedlist>

    <indexterm>
      <primary>attacchi DoS</primary>
      <see>Denial of Service (DoS)</see>
    </indexterm>
    <indexterm>
      <primary>sicurezza</primary>
      <secondary>attacchi DoS</secondary>
      <see>Denial of Service (DoS)</see>
    </indexterm>
    <indexterm><primary>Denial of Service (DoS)</primary></indexterm>

    <para>Un attacco DoS  un'azione che priva la macchina di risorse.
      Tipicamente un attacco DoS  un meccanismo a forza-bruta che tenta
      di bloccare e comunque rendere inusabile una macchina travolgendo di
      richieste i server che rende disponibili o direttamente lo stack di rete.
      Alcuni attacchi DoS tentano di trarre vantaggio da bug nello stack di rete
      per bloccare la macchina con un singolo pacchetto.  Questo genere di
      attacchi pu evitato solo mettendo a posto il bug direttamente nel
      kernel.  Gli attacchi sui server possono spesso essere evitati
      specificando con attenzione dei limiti sul carico che i server stessi
      devono accettare in caso che il sistema lavori in condizioni avverse.
      Gli attacchi a forza-bruta generati da un'intera rete di attaccanti sono
      pi difficili da gestire.  Ad esempio un attacco con pacchetti
      in spoof (ovvero con il campo mittente falsato)  praticamente
      impossibile da fermare, a meno di staccare del tutto il sistema da
      Internet.  Potr anche non fermare la tua macchina, ma sicuramente
      pu saturare la tua connessione Internet.</para>

    <indexterm>
      <primary>sicurezza</primary>
      <secondary>compromissione degli account</secondary>
    </indexterm>

    <para>La compromissione di un account utente  ancora pi
      comune di un attacco DoS.  Molti sysadmin usano ancora i server standard
      <application>telnetd</application>, <application>rlogind</application>,
      <application>rshd</application> e <application>ftpd</application> sulle
      loro macchine.  Questi programmi, normalmente, non usano connessioni
      crittate.  Il risultato  che quando hai una base utenti di medie
      dimensioni, uno o pi degli utenti connessi al tuo sistema da
      remoto (il modo pi comune e conveniente per collegarsi a un
      sisetma) avr una password compromessa da un'operaizone di
      sniffing.  Gli amministratori di sistema attenti controllano i registri
      degli accessi remoto cercando indirizzi sospetti anche tra gli accessi
      permessi.</para>

    <para>Bisogna sempre dare per scontato che una volta che un attaccante ha
      accesso ad un account utente, pu rompere anche
      <username>root</username>.
      In realt, comunque, in un sistema ben configurato e mantenuto,
      questo non  necessariamente vero.  La distinzione 
      importante perch senza accesso a <username>root</username>
      l'attaccante in genere non pu nascondere le proprie tracce e
      pu, alla peggio, rovinare i file dell'utente o mandare la
      macchina in crash.  La compromissione degli account utente  molto
      comune dato che gli utenti tendono a non prendere precauzioni tanto
      quanto gli amministratori di sistema.</para>

    <indexterm>
      <primary>sicurezza</primary>
      <secondary>backdoor</secondary>
    </indexterm>

    <para>Gli amministratori di sistema devono ricordare che su una macchina ci
      sono potenzialmente molti modi per rompere <username>root</username>.
      L'attaccante potrebbe conoscere la password di <username>root</username>,
      potrebbe trovare un bug in un programma server in esecuzione con diritti
      di <username>root</username> e sfruttarlo per entrare da remoto, oppure
      una volta ottenuto un account utente potrebbe fare lo stesso con un bug in
      un programma con suid <username>root</username>.  Se un attaccante rompe
      <username>root</username> su una macchina, potrebbe non aver bisogno di
      installare una backdoor.  Molti dei buchi per l'accesso come
      <username>root</username> trovati (e chiusi) fino ad oggi richiedono un
      considerevole lavoro da parte dell'attaccante per pulire le tracce
      lasciate, quindi molti attaccanti installano delle backdoor.  Una backdoor
      d all'attaccante un modo semplice per riottenere accesso
      <username>root</username> al sistema, ma danno anche un modo semplice per
      individuare l'intrusione, all'amministratore di sistema furbo.  Rendere
      impossibile installare backdoor all'attaccante potrebbe in realt
      diminuire la sicurezza del sistema, dato che comunque non chiuder
      il buco che l'attaccante ha trovato la prima volta.</para>

    <para>Le soluzioni di sicurezza devono sempre essere implementate con un
      approccio multi-strato a <quote>cipolla</quote> e possono essere
      categorizzate come segue:</para>

    <orderedlist>
      <listitem>
        <para>Rendere sicuro <username>root</username> e gli account dello
          staff.</para>
      </listitem>

      <listitem>
        <para>Rendere sicuri i server e i binari suid/sgid in esecuzione come
          <username>root</username>.</para>
      </listitem>

      <listitem>
        <para>Rendere sicuri gli account utente.</para>
      </listitem>

      <listitem>
        <para>Rendere sicuro il file delle password.</para>
      </listitem>

      <listitem>
        <para>Rendere sicuro il nucleo del kernel, i device raw e il file
          system.</para>
      </listitem>

      <listitem>
        <para>Individuazione rapida delle modifiche non appropriate fatte al
          sistema.</para>
      </listitem>

      <listitem>
        <para>Paranoia.</para>
      </listitem>
    </orderedlist>

    <para>La prossima sezione di questo capitolo coprir questi punti in
      maggior dettaglio.</para>
  </sect1>


  <sect1 id="securing-freebsd">
    <title>Rendere sicuro &os;</title>

    <indexterm>
      <primary>sicurezza</primary>
      <secondary>rendere sicuro &os;</secondary>
    </indexterm>

    <note>
      <title>Comandi o Protocolli</title>
      <para>In questo documento useremo testo
        <application>grassetto</application> per riferirci ad applicazioni e
        testo <command>a spaziatura fissa</command> per riferirci a specifici
        comandi.  I protocolli useranno un font normale.  Questa distinzione
        tipografica  utile per casi come ssh, che  un protocollo
        oltre che un comando.</para>
    </note>

    <para>Le sezioni seguenti descrivono i metodi per rendere sicuro il vostro
      sistema &os; che sono stati menzionati nella <link
      linkend="security-intro">sezione precedente</link> di questo
      capitolo.</para>

    <sect2 id="securing-root-and-staff">
      <title>Rendere sicuro <username>root</username> e gli account dello
        staff.</title>

      <indexterm>
        <primary><command>su</command></primary>
      </indexterm>

      <para>Innanzitutto, non preoccuparti di rendere sicuri gli account di
        staff se non hai reso sicuro l'account <username>root</username>.  La
        maggior parte dei sistemi hanno una password assegnata per l'account
        <username>root</username>.  La prima cosa che devi dare per assunta
         che la password  <emphasis>sempre</emphasis>
        compromessa.  Questo non significa che devi togliere la password; la
        password  quasi sempre necessaria per l'accesso dalla console
        della macchina.  Quello che questo significa  che non dovresti
        render possibile l'uso di questa password tranne che da console e
        possibilmente neanche dal comando &man.su.1;.  Per esempio, assicurati
        che le tue pty siano specificate come <literal>insecure</literal> nel
        file <filename>/etc/ttys</filename> in modo che accessi diretti
        <username>root</username> tramite <command>telnet</command> o
        <command>rlogin</command> non siano permessi.  Se usi altri servizi di
        login come ad esempio <application>sshd</application>, fai in modo che
        accessi diretti come <username>root</username> siano vietati anche per
        questi.  Puoi farlo modificando il file
        <filename>/etc/ssh/sshd_config</filename> e assicurandoti che
        <literal>PermitRootLogin</literal> sia impostato a
        <literal>NO</literal>.  Tieni conto di tutti i modi di accesso &mdash;
        servizi come ad esempio FTP vengono spesso trascurati.  Login
        <username>root</username> diretti dovrebbero essere permessi solo
        tramite la console di sistema.</para>

      <indexterm>
        <primary><groupname>wheel</groupname></primary>
      </indexterm>

      <para>Ovviamente, come sysadmin (amministratore di sistema) hai bisogno
        di accesso a <username>root</username>, quindi apriremo alcuni passaggi;
        ci assicureremo per che questi passaggi richiedano ulteriori
        verifiche di password per funzionare.  Un modo per accedere a
        <username>root</username>  aggiungere gli appropriati account di
        staff al gruppo <groupname>wheel</groupname> (in
        <filename>/etc/group</filename>).  I membri del gruppo
        <groupname>wheel</groupname> possono accedere a
        <username>root</username> tramite <command>su</command>.
        Non dovresti mai dare ai membri dello staff accesso nativo al gruppo
        <groupname>wheel</groupname> mettendoli in quel gruppo nel file
        <filename>/etc/passwd</filename>; dovresti metterli nel gruppo
        <groupname>staff</groupname> e quindi aggiungerli al gruppo
        <groupname>wheel</groupname> tramite il file
        <filename>/etc/group</filename>.  Solo i membri dello staff che hanno
        effettivo bisogno di accesso a <username>root</username> dovrebbero
        essere nel gruppo <groupname>wheel</groupname> group.  Altra
        possibilit, quando si utilizzi Kerberos come  metodo di
        autenticazione, &grave; quella di utilizzare il file
        <filename>.k5login</filename> dell'account <username>root</username> in
        modo da permettere l'accesso a <username>root</username> tramite
        &man.ksu.1; senza bisogno di mettere nessuno nel gruppo
        <groupname>wheel</groupname>.  Questa potrebbe essere la soluzione
        migliore dato che il meccanismo <groupname>wheel</groupname> permette
        all'attaccante di diventare <username>root</username> se 
        riuscito ad ottenere accesso ad un account di staff.  Bench il
        meccanismo <groupname>wheel</groupname> sia meglio di niente, non
         necessariamente la soluzione pi sicura.</para>

      <para>Un metodo indiretto per rendere sicuri gli account di staff e quindi
        l'accesso a <username>root</username>  quello di eseguire
        l'operazione nota come <quote>starring</quote> delle password cifrate.
        password for the staff accounts: utilizzando il comando &man.vipw.8; si
        pu rimpiazzare ogni password cifrata con un singolo carattere
        <quote><literal>*</literal></quote> (asterisco, in inglese
        <quote>star</quote>).  Questo comando aggiorna il file
        <filename>/etc/master.passwd</filename> e il database utenti/password
        in modo da disabilitare i login autenticati da password.</para>

      <para>Un account di staff come il seguente:</para>

      <!--TODO:aggiustare la password per essere moderna ($1$...)-->
      <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>

      <para>Andrebbe modificato cos:</para>

      <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>

      <para>Questo previene i normali login dato che la password cifrata non
        sar mai <quote><literal>*</literal></quote>.  Fatto questo i
        membri dello staff dovranno utilizzare un diverso meccanismo di
        autenticazione come ad esempio &man.kerberos.1; o &man.ssh.1;
        utilizzando una coppia di chiavi pubblica/privata.  Utilizzando Kerberos
        bisogna generalmente rendere sicure sia le macchine su cui viene
        eseguito il server Kerberos che la propria workstation.  Utilizzando una
        coppia di chiavi bisogna in generale rendere sicura la macchina
        <emphasis>da cui</emphasis> ci si sta collegando (in genere la propria
        workstation); si pu aggiungere un ulteriore strato di protezione
        proteggendo la coppia di chiavi con una password all'atto della
        creazione con &man.ssh-keygen.1;.  Eseguire lo <quote>starring</quote>
        degli account dello staff garantisce che questi possano eseguire il
        login solo tramite i metodi di accesso sicuri che sono stati
        configutati.  Quest forze l'intero staff all'uso di connessioni sicure e
        cifrate in tutte le loro sessioni, chiudendo un importante falla di
        sicurezza utilizzata da molti attaccanti: ascoltare il traffico di rete
        da un'altra macchina meno sicura.</para>

      <!--TODO: questo paragrafo  poco leggibile, anche in inglese -->
      <para>I meccanismi di sicurezza pi indiretti assumono anche che ci
        si colleghi da un server pi restrittivo a uno che lo  di
        meno; per esempio se il tuo server primario ha in esecuzione una grande
        variet di servizi, la tua workstation non dovrebbe averne in
        esecuzione nessuno. Per fare in modo che la tua workstation sia
        ragionevolmente sicura dovresti eseguire meno servizi possibile, o
        perfino nessuno del tutto, e dovresti utilizzare uno screen saver
        protetto da password.  Ovviamente, avendo accesso fisico alla
        workstation un attaccante pu rompere qualsiasi protezione che tu
        possa aver importato, ma bisogna sempre considerare che la magior parte
        degli attacchi avviene remotamente, tramite una rete, da parte di
        persone che non hanno accesso fisico alle tue workstation o ai tuoi
        server.</para>

      <indexterm><primary>KerberosIV</primary></indexterm>

      <para>L'uso di sistemi come Kerberos permette di disabilitare o cambiare
        la pasword ad un account di staff in un solo posto ed avere effeto
        immediato su tutte le macchine in cui il membro dello staff ha un
        account.  Nel caso l'account di un membro dello staff venga compromesso,
        la possibilit di poter cambiare la sua password su tutte le
        macchine non &grave; cosa di poco conto.  Con password separate,
        cambiare una password su molte macchine pu essere un bel
        problema.  Con Kerberos puoi anche imporre restrizioni di cambio
        password:  non solo un ticket Kerberos pu essere fatto per
        scadere dopo un tempo predeterminato, ma il sistema Kerberos pu
        richiedere all'utente di scegliere una nuova passsword dopo un certo
        periodo di tempo (per esempio, una volta al mese).</para>
    </sect2>

    <sect2>
      <title>Rendere sicuri i server Root e i binari SUID/SGID</title>

      <indexterm>
        <primary><command>ntalk</command></primary>
      </indexterm>
      <indexterm>
        <primary><command>comsat</command></primary>
      </indexterm>
      <indexterm>
        <primary><command>finger</command></primary>
      </indexterm>
      <indexterm>
        <primary>sandboxes</primary>
      </indexterm>
      <indexterm>
        <primary><application>sshd</application></primary>
      </indexterm>
      <indexterm>
        <primary><application>telnetd</application></primary>
      </indexterm>
      <indexterm>
        <primary><application>rshd</application></primary>
      </indexterm>
      <indexterm>
        <primary><application>rlogind</application></primary>
      </indexterm>

      <para>Il sysadmin prudente esegue soltanto i server che gli sono
        necessari, n&acute; di pi n di meno.  Bisogna tenere
        conto del fatto che i server di terze parti sono generalmente i
        pi affetti da bug.  Per esempio, utilizzare una versione
        obsoleta di <application>imapd</application> o
        <application>popper</application>  equivalente a dare accesso
        <username>root</username> al mondo intero.  Non eseguire mai un server
        senza controllarlo accuratamente.  Molti server non hanno bisogno di
        essere eseguiti come <username>root</username>.  Per esempio i demoni
        <application>ntalk</application>, <application>comsat</application> e
        <application>finger</application> possono essere eseguiti in speciali
        <firstterm>sandbox</firstterm> utente.  Difficilmente una sandbox
        sar una soluzione completa del problema, a meno di dedicarci
        parecchio tempo, ma resta valido l'approccio a cipolla alla sicurezza:
        se qualcuno riesce ad irrompere in un server eseguito in una sandbox,
        deve ancora riuscire ad evadere da quest'ultima.  Pi strati
        l'attaccante deve superare, minore la sua probabilit di
        successo.  Storicamente sono state trovate falle di accesso a root in
        virtualmente ogni server mai eseguito come <username>root</username>,
        inclusi i server del sistema base.  Se hai una macchina alla quale la
        gente accede solamente tramite <application>sshd</application> e mai
        tramite <application>telnetd</application> o
        <application>rshd</application> o <application>rlogind</application>,
        allora disattiva questi servizi!</para>

      <para>&os; attualmente esegue per default
        <application>ntalkd</application>, <application>comsat</application> e
        <application>finger</application> in una sandbox.  Un altro programma
        candidato ad essere eseguito in una sandbox  &man.named.8;.
        <filename>/etc/defaults/rc.conf</filename> comprende le opzioni
        necessarie per eseguire <application>named</application> in una sandbox
        in forma comentata.  A seconda se state installando un nuovo sistema o
        aggiornando un sistema esistente, gli speciali account utente utilizzati
        da queste sandbox potrebbero non essere presenti.  Il sysadmin prudente
        dovrebbe cercar di utilizzare delle sandbox per i server ogniqualvolta
        possibile.</para>

      <indexterm>
        <primary><application>sendmail</application></primary>
      </indexterm>

      <para>Esiste un certo numero di altri servizi che generalmente non vengono
        eseguiti in una sandbox: <application>sendmail</application>,
        <application>popper</application>, <application>imapd</application>,
        <application>ftpd</application> e altri.  Ci sono software alternativi
        ad alcuni di questi ma installarli potrebbe richiedere pi lavoro
        di quello che si intende dedicargli (il fattore convenienza colpisce
        ancora).  Potresti dover eseguire questi servizi come
        <username>root</username> ed affidarti ad altri meccanismi per
        individuare le intrusioni che potrebbero essere fatte attraverso
        questi.</para>

      <para>L'altra grande potenziale fonte di falle per l'accesso a
        <username>root</username> sono i binari suid-root e sgid installati nel
        sistema, come ad esempio <application>rlogin</application>, nelle
        directory <filename>/bin</filename>, <filename>/sbin</filename>,
        <filename>/usr/bin</filename> o <filename>/usr/sbin</filename>.
        Bench niente sia sicuro al 100%, i binari suid e sgid presenti
        nel sistema per default possono essere considerati ragionevolmente
        sicuri.  In ogni caso, delle falle da <username>root</username> sono
        occasionalmente trovate anche in questi.  Nel 1998  stata
        trovata una falla da <username>root</username> in
        <literal>Xlib</literal> che rendeva vulnerabile
        <application>xterm</application> (che tipicamente  suid).
        <!--TODO-->
        It is better to be safe than sorry and the prudent
        sysadmin will restrict suid binaries, that only staff should run,
        to a special group that only staff can access, and get rid of
        (<command>chmod 000</command>) any suid binaries that nobody uses.
        A server with no display generally does not need an
        <application>xterm</application> binary.  Sgid binaries can be
        almost as dangerous.  If an intruder can break an sgid-kmem binary,
        the intruder might be able to read <filename>/dev/kmem</filename>
        and thus read the encrypted password file, potentially compromising
        any passworded account.  Alternatively an intruder who breaks
        group <literal>kmem</literal> can monitor keystrokes sent through
        ptys, including ptys used by users who login through secure
        methods.  An intruder that breaks the <groupname>tty</groupname>
        group can write to
        almost any user's tty.  If a user is running a terminal program or
        emulator with a keyboard-simulation feature, the intruder can
        potentially generate a data stream that causes the user's terminal
        to echo a command, which is then run as that user.</para>
    </sect2>

    <sect2 id="secure-users">
      <title>Rendere sicuri gli account utente</title>

      <para>Gli account utente sono generalmente i pi difficili da
        rendere sicuri.  Bench*eacute; tu possa imporre restrizioni d'accesso
        <!--TODO: draconian --> allo staff ed eseguire lo
        <quote>starring</quote> delle loro password, potresti non poter farlo
        con l'account di un generico utente.  Se hai sufficiente controllo
        <!--TODO:potere?--> potesti farcela e rendere gli account utente
        sufficientemente sicuri, altrimenti dovrai essere pi vigile nel
        controllo di questi account.  L'uso di ssh e Kerberos per gli account
        utente  pi problematico, a causa del maggiore supporto
        amministrativo e tecnico richiesto, ma  sempre un'ottima
        soluzione se confrontata all'uso di un file password cifrato.</para>
    </sect2>

    <sect2>
      <title>Rendere sicuro il file password</title>

      <para>L'unica strada sicura  quella di eseguire lo starring so
        pi password possibile e utilizzare ssh o Kerberos per accedere a
        quegli account.  Anche se il file di password cifrato
        (<filename>/etc/spwd.db</filename>) pu essere letto solo da
        <username>root</username>, potrebbe essere possibile per un attaccante
        ottenere accesso in lettura a quel file anche senza aver ottenuto
        accesso in scrittura.</para>

      <para>I tuoi script di sicurezza dovrebbero sempre verificare che il file
        password non venga modificato e in caso riportarlo ad un amministratore
        (cfr. la sezione <link
          linkend="security-integrity">Verifica dell'integrit dei
          file</link> sottostante).</para>
    </sect2>

    <sect2>
      <title>Rendere sicuri il kernel, i raw device e i file system</title>

      <para>Quando un attaccante irrompe nell'account di
        <username>root</username> pu fare qualsiasi cosa, ma alcune cose
        sono pi comode di altre. <!--there are certain conveniences-->
        Per esempio, la maggior parte dei kernel moderni comprende un device
        per l'ascolto dei pacchetti di rete.  In &os; questo device si chiama
        <devicename>bpf</devicename>.  Un intrusore generalmente cercher
        di ascoltare i pacchetti delle reti a cui la macchina compromessa
         collegata.  Non  obbligatorio dare all'intrusore questa
        possibilit e d'altro canto la maggior parte dei sistemi non ha
        bisogno di avere il device <devicename>bpf</devicename>.</para>

      <indexterm>
        <primary><command>sysctl</command></primary>
      </indexterm>

      <para>Anche nel caso di aver disattivato il device
        <devicename>bpf</devicename>, bisogna comunque preoccuparsi di
        <filename>/dev/mem</filename> e <filename>/dev/kmem</filename>; tra
        l'altro l'intrusore ha anche la possibilit di scrivere sui
        device disco raw o utilizzare il comando di caricamento moduli del
        kernel, &man.kldload.8;.  Un intrusore intraprendente pu
        utilizzare un proprio modulo del kernel per l'ascolto dei pacchetti e
        caricarlo su un kernel in esecuzione.  Per evitare questi problemi
        bisogna eseguire il kernel ad un livello di sicurezza pi alto,
        almeno al livello 1.  Il livello di sicurezza pu essere
        impostato con <command>sysctl</command> modificando la variabile
        <varname>kern.securelevel</varname>.  Se il livello di sicurezza
         impostato ad 1, l'accesso in scrittura ai device raw
        sar negato e alcuni <command>chflags</command> speciali,
        come ad esempio <literal>schg</literal>, verranno verificati.
        Devi anche verificare che il flag <literal>schg</literal> sia impostato
        sui binari, cartelle e script utilizzati all'avvio prima
        dell'impostazione del livello di sicurezza.  L'uso di un livello di
        sicurezza superiore potrebbe essere una misura eccesiva, dato che rende
        l aggiornamento del sistema molto pi complesso.
        You may compromise and run the
        system at a higher secure level but not set the
        <literal>schg</literal> flag for every system file and directory
        under the sun.  Another possibility is to simply mount
        <filename>/</filename> and <filename>/usr</filename> read-only.
        It should be noted that being too draconian in what you attempt to
        protect may prevent the all-important detection of an
        intrusion.</para>
    </sect2>

    <sect2 id="security-integrity">
      <title>Verifica dell'integrit dei file: binari, file di
        configurazione, etc.</title>

      <para>TODO:When it comes right down to it, you can only protect your core
        system configuration and control files so much before the
        convenience factor rears its ugly head.  For example, using
        <command>chflags</command> to set the <literal>schg</literal> bit
        on most of the files in <filename>/</filename> and
        <filename>/usr</filename> is probably counterproductive, because
        while it may protect the files, it also closes a detection window.
        The last layer of your security onion is perhaps the most
        important &mdash; detection.  The rest of your security is pretty
        much useless (or, worse, presents you with a false sense of
        security) if you cannot detect potential intrusions.  Half the job
        of the onion is to slow down the attacker, rather than stop him, in
        order to be able to catch him in the act.</para>

      <para>The best way to detect an intrusion is to look for modified,
        missing, or unexpected files.  The best way to look for modified
        files is from another (often centralized) limited-access system.
        Writing your security scripts on the extra-secure limited-access
        system makes them mostly invisible to potential attackers, and this
        is important.  In order to take maximum advantage you generally
        have to give the limited-access box significant access to the
        other machines in the business, usually either by doing a
        read-only NFS export of the other machines to the limited-access
        box, or by setting up ssh key-pairs to
        allow the limited-access box to ssh to
        the other machines.  Except for its network traffic, NFS is the
        least visible method &mdash; allowing you to monitor the
        file systems on each client box virtually undetected.  If your
        limited-access server is connected to the client boxes through a
        switch, the NFS method is often the better choice.  If your
        limited-access server is connected to the client boxes through a
        hub, or through several layers of routing, the NFS method may be
        too insecure (network-wise) and using
        ssh may be the better choice even with
        the audit-trail tracks that ssh
        lays.</para>

      <para>Once you have given a limited-access box at least read access to the
        client systems it is supposed to monitor, you must write scripts
        to do the actual monitoring.  Given an NFS mount, you can write
        scripts out of simple system utilities such as &man.find.1; and
        &man.md5.1;.  It is best to physically md5 the client-box files
        at least once a day, and to test control files such as those
        found in <filename>/etc</filename> and
        <filename>/usr/local/etc</filename> even more often.  When
        mismatches are found, relative to the base md5 information the
        limited-access machine knows is valid, it should scream at a
        sysadmin to go check it out.  A good security script will also
        check for inappropriate suid binaries and for new or deleted files
        on system partitions such as <filename>/</filename> and
        <filename>/usr</filename>.</para>

      <para>When using ssh rather than NFS,
        writing the security script is much more difficult.   You
        essentially have to <command>scp</command> the scripts to the client
        box in order to
        run them, making them visible, and for safety you also need to
        <command>scp</command> the binaries (such as find) that those
        scripts use.  The <application>ssh</application> client on the
        client box may already be compromised.  All in all, using
        ssh may be necessary when running over
        insecure links, but it is also a lot harder to deal with.</para>

      <para>A good security script will also check for changes to user and
        staff members access configuration files:
        <filename>.rhosts</filename>, <filename>.shosts</filename>,
        <filename>.ssh/authorized_keys</filename> and so forth,
        files that might fall outside the purview of the
        <literal>MD5</literal> check.</para>

      <para>If you have a huge amount of user disk space, it may take too
        long to run through every file on those partitions.  In this case,
        setting mount flags to disallow suid binaries and devices on those
        partitions is a good idea.  The <literal>nodev</literal> and
        <literal>nosuid</literal> options (see &man.mount.8;) are what you
        want to look into.  You should probably scan them anyway, at least
        once a week, since the object of this layer is to detect a break-in
        attempt, whether or not the attempt succeeds.</para>

      <para>Process accounting (see &man.accton.8;) is a relatively
        low-overhead feature of the operating system which might help
        as a post-break-in evaluation mechanism.  It is especially
        useful in tracking down how an intruder has actually broken into
        a system, assuming the file is still intact after the break-in has
        occured.</para>

      <para>Finally, security scripts should process the log files, and the
        logs themselves should be generated in as secure a manner as
        possible &mdash; remote syslog can be very useful.  An intruder
        will try to cover his tracks, and log files are critical to the
        sysadmin trying to track down the time and method of the initial
        break-in.  One way to keep a permanent record of the log files is
        to run the system console to a serial port and collect the
        information to a secure machine monitoring the consoles.</para>
    </sect2>

    <sect2>
      <title>Paranoia</title>

      <para>Un po' di paranoia non fa mai male.  Come regola, un sysadmin
        pu aggiungere qualsiasi feature di sicurezza fintantoch
        non impattano la comodit e pu aggiungerne altre
        <emphasis>che la</emphasis> impattano, ma solo dopo averci pensato bene.
        <!--TODO: questa parte di paragrafo  decisamente opinabile-->
        Even more importantly, a security administrator should mix it up a
        bit &mdash; if you use recommendations such as those given by this
        document verbatim, you give away your methodologies to the
        prospective attacker who also has access to this document.</para>
    </sect2>

    <sect2>
      <title>Attacchi Denial of Service</title>

      <indexterm><primary>Denial of Service (DoS)</primary></indexterm>

      <para>Questa sezione parla degli attacchi Denial of Service, ovvero quelli
        atti ad interrompere i servizi in esecuzione su una macchina.
        Tipicamente un attacco DoS  un attacco a pacchetto;
        bench non si possa fare molto riguardo ad un attacco moderno
        che satura la vostra rete con pacchetti <!--TODO: spoofed-->, si
        pu cercare di limitare il danno assicurandosi che l'attacco non
        blocchi i vostri servizi, utilizzando le seguenti tecniche:</para>

      <orderedlist>
        <listitem>
          <para>Limitare le fork dei server.</para>
        </listitem>

        <listitem>
          <para>TODO:Limiting springboard attacks (ICMP response attacks, ping
            broadcast, etc.).</para>
        </listitem>

        <listitem>
          <para>Sovraccaricare la Kernel Route Cache. <!--TODO: anche in inglese
            questo punto non ha molto senso assieme agli altri: non  qualcosa
            che si fa per evitare il danno--></para>
        </listitem>
      </orderedlist>

      <para>Un comune scenario  l'attacco di un server che fa fork e
        fargli creare cos tanti processi figli da esaurire le risorse
        della macchina, come ad esempio la memoria, i file descriptor o altri e
        costringerlo quindi a fermarsi.  <application>inetd</application>
        (cfr. &man.inetd.8;) ha molte opzioni per limitare questo tipo di
        attacchi.  Si deve notare che bench sia possibile evitare che la
        macchina si fermi, non  generalmente possibile evitare che i
        servizi vengano resi non disponibili dall'attacco.  Leggete attentamente
        la pagina del manuale di <application>inetd</application>, con
        particolare attenzione alle opzioni <option>-c</option>,
        <option>-C</option> e <option>-R</option>.  Un attacco con IP
        <!--TODO: spoofed--> aggira l'opzione <option>-C</option> quindi
         bene utilizzare una combinazione di opzioni.  Alcuni server
        indipendenti hanno meccanismi interni per la limitazione delle
        fork.</para>

      <para><application>Sendmail</application> ha l'opzione
        <option>-OMaxDaemonChildren</option> che generalmente funziona molto
        meglio che cercare di utilizzare le funzioni di limitazione basate sul
        carico della macchina, a causa del ritardo di aggiornamento del valore
        di carico.  Quando lanci <application>sendmail</application> dovresti
        specificare un parametro <literal>MaxDaemonChildren</literal> abbastanza
        alto da gestire il carico previsto , ma non cos alto da non
        essere gestibile dal computer.   anche prudente eseguire
        <application>Sendmail</application> in modalit queued
        (<option>-ODeliveryMode=queued</option>) ed eseguire il demone
        (<command>sendmail -bd</command>) separatamente dalla gestione code
        (<command>sendmail -q15m</command>).  Se vuoi che i messaggi vengano
        consegnati in tempo reale puoi utilizzare un intervallo molto pi
        breve, come ad esempio <option>-q1m</option>, ma assicurati di
        utilizzare un valore <literal>MaxDaemonChildren</literal> adatto per
        <emphasis>quel</emphasis> <application>Sendmail</application>, in modo
        da prevenire problemi a catena<!--TODO: cascade failures-->.</para>

      <para><application>Syslogd</application> pu essere attaccato
        direttamente ed  fortemente consigliato l'uso dell'opzione
        <option>-s</option> quando possibile, o al limite l'opzione
        <option>-a</option>.</para>

      <para>You should also be fairly careful with connect-back services
        such as <application>TCP Wrapper</application>'s reverse-identd,
        which can be attacked directly.  You generally do not want to use
        the reverse-ident feature of
        <application>TCP Wrapper</application> for this reason.</para>

      <para> un'ottima idea quella di proteggere i servizi interni
        dall'accesso esterno chiudendoli tramite regole del firewall ai bordi
        della vostra rete.  L'idea  di prevenire gli attacchi a
        saturazione provenienti dall'esterno della vostra rete, non tanto di
        proteggere i servizi da attacchi di rete atti a compromettere
        <username>root</username>.  Utilizza sempre un firewall <!--TODO:
        exclusive-->, ovvero <quote>blocca tutto <emphasis>tranne</emphasis> le
        porte A, B, C, D e M-Z</quote>; puoi bloccare tutte le porte basse ad
        eccezione di specifici servizi quali <application>named</application>
        (se sei primario per una zona), <application>ntalkd</application>,
        <application>sendmail</application> e altri servizi accessibili da
        Internet.  Se tu cercassi di configurare il firewall in maniera opposta
        (inclusivo o permissivo) c' una buona probabilit che tu
        ti scordi di <quote>chiudere</quote> qualche servizio o che tu aggiunga
        un nuovo servizio interno e dimentichi di aggiornare il firewall.
        Puoi comunque lasciare aperte tutte le porte <!--TODO: high-numbered-->,
        permettendo un uso permissivo, senza per compromettere le porte
        <!--TODO: low-->.  Nota anche che &os; ti permette di controllare
        l'intervallo di porte utilizzate per il binding dinamico tramite vari
        <command>sysctl</command> <varname>net.inet.ip.portrange</varname>
        (<command>sysctl -a | fgrep portrange</command>), che possono
        semplificare la complessit di configurazione del tuo firewall.
        <!--TODO: For example, you might use a normal
        first/last range of 4000 to 5000, and a hiport range of 49152 to
        65535, then block off everything under 4000 in your firewall
        (except for certain specific Internet-accessible ports, of
        course).--></para>

      <para>Another common DoS attack is called a springboard attack
        &mdash; to attack a server in a manner that causes the server to
        generate responses which overloads the server, the local
        network, or some other machine.  The most common attack of this
        nature is the <emphasis>ICMP ping broadcast attack</emphasis>.
        The attacker spoofs ping packets sent to your LAN's broadcast
        address with the source IP address set to the actual machine they
        wish to attack.  If your border routers are not configured to
        stomp on ping packets to broadcast addresses, your LAN winds up
        generating sufficient responses to the spoofed source address to
        saturate the victim, especially when the attacker uses the same
        trick on several dozen broadcast addresses over several dozen
        different networks at once.  Broadcast attacks of over a hundred
        and twenty megabits have been measured.  A second common
        springboard attack is against the ICMP error reporting system.
        By constructing packets that generate ICMP error responses, an
        attacker can saturate a server's incoming network and cause the
        server to saturate its outgoing network with ICMP responses.  This
        type of attack can also crash the server by running it out of
        memory, especially if the server cannot drain the ICMP responses
        it generates fast enough.
        Use the <application>sysctl</application>
        variable <literal>net.inet.icmp.icmplim</literal> to limit these attacks.
        The last major class of springboard
        attacks is related to certain internal
        <application>inetd</application> services such as the
        udp echo service.  An attacker simply spoofs a UDP packet with the
        source address being server A's echo port, and the destination
        address being server B's echo port, where server A and B are both
        on your LAN.  The two servers then bounce this one packet back and
        forth between each other.  The attacker can overload both servers
        and their LANs simply by injecting a few packets in this manner.
        Similar problems exist with the internal
        <application>chargen</application> port.  A
        competent sysadmin will turn off all of these inetd-internal test
        services.</para>

      <para>Spoofed packet attacks may also be used to overload the kernel
        route cache.  Refer to the <varname>net.inet.ip.rtexpire</varname>,
        <varname>rtminexpire</varname>, and <varname>rtmaxcache</varname>
        <command>sysctl</command> parameters.  A spoofed packet attack
        that uses a random source IP will cause the kernel to generate a
        temporary cached route in the route table, viewable with
        <command>netstat -rna | fgrep W3</command>.  These routes
        typically timeout in 1600 seconds or so.  If the kernel detects
        that the cached route table has gotten too big it will dynamically
        reduce the <varname>rtexpire</varname> but will never decrease it
        to less than <varname>rtminexpire</varname>.  There are two
        problems:</para>

      <orderedlist>
        <listitem>
          <para>The kernel does not react quickly enough when a lightly
            loaded server is suddenly attacked.</para>
        </listitem>

        <listitem>
          <para>The <varname>rtminexpire</varname> is not low enough for
            the kernel to survive a sustained attack.</para>
        </listitem>
      </orderedlist>

      <para>If your servers are connected to the Internet via a T3 or
        better, it may be prudent to manually override both
        <varname>rtexpire</varname> and <varname>rtminexpire</varname>
        via &man.sysctl.8;.  Never set either parameter to zero (unless
        you want to crash the machine).  Setting both
        parameters to 2 seconds should be sufficient to protect the route
        table from attack.</para>
    </sect2>

    <sect2>
      <title>Access Issues with Kerberos and SSH</title>

      <indexterm><primary><command>ssh</command></primary></indexterm>
      <indexterm><primary>KerberosIV</primary></indexterm>

      <para>There are a few issues with both Kerberos and
        ssh that need to be addressed if
        you intend to use them.  Kerberos 5 is an excellent
        authentication protocol, but there are bugs in the kerberized
        <application>telnet</application> and
        <application>rlogin</application> applications that make them
        unsuitable for dealing with binary streams.  Also, by default
        Kerberos does not encrypt a session unless you use the
        <option>-x</option> option.  <application>ssh</application>
        encrypts everything by default.</para>

      <para>Ssh works quite well in every respect except that it forwards
        encryption keys by default.  <!--TODO: ma non  vero!??--> What
        this means is that if you have a secure workstation holding keys
        that give you access to the rest of the system, and you
        ssh to an insecure machine, your keys
        are usable.  The actual keys themselves are not exposed, but
        ssh installs a forwarding port for the
        duration of your login, and if an attacker has broken
        <username>root</username> on the
        insecure machine he can utilize that port to use your keys to gain
        access to any other machine that your keys unlock.</para>

      <para>We recommend that you use ssh in
        combination with Kerberos whenever possible for staff logins.
        <application>Ssh</application> can be compiled with Kerberos
        support.  This reduces your reliance on potentially exposed
        ssh keys while at the same time
        protecting passwords via Kerberos.  Ssh
        keys should only be used for automated tasks from secure machines
        (something that Kerberos is unsuited to do).  We also recommend that
        you either turn off key-forwarding in the
        ssh configuration, or that you make use
        of the <literal>from=IP/DOMAIN</literal> option that
        ssh allows in its
        <filename>authorized_keys</filename> file to make the key only
        usable to entities logging in from specific machines.</para>
    </sect2>

  </sect1>


  <sect1 id="crypt">
    <sect1info>
      <authorgroup>
        <author>
          <firstname>Bill</firstname>

          <surname>Swingle</surname>

          <contrib>Parti riscritte e aggiornate da </contrib>
        </author>
      </authorgroup>
    </sect1info>

    <title>DES, MD5 e Crypt</title>

    <indexterm>
      <primary>sicurezza</primary>
      <secondary>crypt</secondary>
    </indexterm>

    <indexterm><primary>crypt</primary></indexterm>
    <indexterm><primary>DES</primary></indexterm>
    <indexterm><primary>MD5</primary></indexterm>

    <para>Ogni utente su un sistema &unix; ha una password associata con il
      proprio account.   pvviamente necessario che queste password siano
      note solamente all'utente e al sistema operativo vero e proprio.  Per
      poter mantenere segrete queste password, sono cifrate con quello che si
      chiama un <quote><!--TODO-->one-way hash</quote>, ovvero possono essere
      facilmente cifrate ma non decifrate.  In altre parole, quel che poco fa
      abbiamo dato per ovvio non  neanche vero: il sistema operativo in
      s non conosce <emphasis>realmente</emphasis> la password, conosce
      soltanto la forma <emphasis>cifrata</emphasis> della password.  L'unico
      modo per ricavare la password <emphasis>in chiaro</emphasis>  una
      brutale ricerca nell'intero spazio delle password possibili.</para>

    <para>Sfortunatamente l'unico modo sicuro di cifrare le password quando
      &unix;  nato era di utilizzare DES (Data Encryption Standard).
      Questo non era un grosso problema per gli utenti residenti in USA, ma dato
      che il codice sorgente riguardante DES non poteva essere esportato al di
      fuori degli USA, &os; ha dovuto cercare un modo per poter
      contemporaneamente essere in regola con la legge USA e mantenere la
      compatibilit con tutte le altre varianti &unix; che ancora
      utilizzavano DES.</para>

    <para>La soluzione  stata quella di suddividere le librerie di
      cifratura in modo tale che gli utenti USA potessero installare le librerie
      DES ed utilizzarlo ma gli utenti internazionali avessero comunque a
      disposizioni metodi crittografici che potessero essere esportati
      all'estero.  Questo  il modo in cui &os; adott MD5 come
      metodo di cifratura di default.  MD5  considerato pi
      sicuro di DES, quindi installare DES  una possibilit
      pensata principalmente per motivi di compatibili.</para>

    <sect2>
      <title>Riconoscere il funzionamento del tuo crypt</title>

      <para>Attualmente la libreria supporta gli algoritmi DES, MD5 e Blowfish.
        Per default &os; utilizza MD5 per cifrare le password.</para>

      <para> piuttosto semplice identificare il tipo di cifratura
        utilizzato; ad esempio uno dei metodi  di leggere il file
        <filename>/etc/master.passwd</filename>.  Le password cifrate con l'hash
        MD5 sono pi lunghe e iniziano con i caratteri
        <literal>&dollar;1&dollar;</literal>.  Le password che iniziano con
        <literal>&dollar;2a&dollar;</literal> sono cifrate con Blowfish.
        Le password DES non hanno alcun carattere identificativo particolare, ma
        sono pi corte e sono codificate in un alfabeto di 64 caratteri
        che non include il <literal>&dollar;</literal>, quindi una stringa
        relativamente corta che non inizia con un simbolo di dollaro 
        molto probabilmente una password DES.</para>

      <para>Il formato utilizzato per le nuove password  deciso dal
        valore del campo <literal>passwd_format</literal> nel file
        <filename>/etc/login.conf</filename>, che pu avere i valori di
        <literal>des</literal>, <literal>md5</literal> oo
        <literal>blf</literal>.  Fai riferimento alla pagina del manuale
        &man.login.conf.5; per avere ulteriori informazioni sulle configurazioni
        di login.</para>
    </sect2>
  </sect1>

  <sect1 id="one-time-passwords">
    <title>Password One-time</title>

    <indexterm><primary>one-time passwords</primary></indexterm>
    <indexterm>
      <primary>security</primary>
      <secondary>one-time passwords</secondary>
    </indexterm>

    <para>Per default &os; include il supporto per OPIE (One-time Passwords
      In Everything), configurato per utilizzare l'hash MD5.</para>

    <para>Ci sono tre tipi di diverse password di cui parleremo in seguito.  Le
      prime sono le normali pasword &unix; o Kerberos, che verranno chiamate
      <quote>password &unix;</quote>.  Il secondo tipo sono le password one-time
      generate dal programma OPIE &man.opiekey.1; e accettate dal programma
      &man.opiepasswd.1; e dal prompt di login, che chiameremo
      <quote>password one-time</quote>.  L'ultimo tipo di password  la
      password segreta che darai al programma <command>opiekey</command> (e
      qualche volte al programma <command>opiepasswd</command>) e che viene
      utilizzata per generare le password one-time, che chiameremo
      <quote>password segreta</quote> o pi semplicemente
      <quote>password</quote>.</para>

    <para>La password segreta non ha niente a che vedere con la password &unix;;
      possono essere uguali ma questo  sconsigliato.  Le password
      segrete di OPIE non sono limitate a 8 caratteri come le vecchie password
      &unix;<footnote><para>In &os; le normali password di login possono essere
      lunghe fino a 128 caratteri.</para></footnote>, possono essere lunghe
      quanto ti pare.  Sono abbastana diffuse password composte da frasi di sei
      o sette parole.  Per la maggior parte, il sistema OPIE funziona in modo
      totalmente indipendente dal sistema di password &unix;.</para>

    <para>Oltre alla password, ci sono altre due informazioni utili a OPIE.  Una
       nota come <quote>seme</quote> o <quote>chiave</quote> e consiste
      di due lettere e cinque numeri.  L'altra  nota come
      <quote>numero di iterazioni</quote> ed  un valore tra 1 e 100.
      OPIE crea la password one-time concatenando il seme e la password segreta
      ed applicandovi l'hash MD5 tante volte quanto specificate dal numero di
      iterazioni, trasformando poi il risultato in sei corte parole inglesi, che
      saranno la tua password one-time.  Il sistema di autenticazione
      (principalmente PAM) mantiene traccia dell'ultima password one-time usata
      e autentica l'utente  se l'hash della password fornita dall'utente
       uguale alla password precedente.  Dato che viene usato un hash,
      ovvero una funzione matematica a senso unico
      <!--TODO:non invertibile? "Because a one-way hash is used"-->
       impossibile generare password one-time future se viene catturata
      una password durante il suo utilizzo; il numero di iterazioni viene
      decrementato dopo un login avvenuto con successo per mantenere l'utente e
      il programma di login in sincrono.  Quando il numero di iterazioni scende
      a 1, OPIE deve essere reinizializzato.</para>

    <para>Nelle seguenti spiegazioni si far riferimento a vari
      programmi: il programma <command>opiekey</command> richiede un numero di
      iterazioni, un seme e una password segreta e genera una password one-time
      o una lista di password one-time consecutive; il programma
      <command>opiepasswd</command> viene utilizzato per inizializzzare OPIE e
      per cambiare password, numeri di iterazioni, semi e password one-time; il
      programma <command>opieinfo</command> analizza i file di credenziali
      (<filename>/etc/opiekeys</filename>) e stampa il numero di iterazioni
      e il seme correnti dell'utente che lo richiama.</para>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="tcpwrappers">
    <title>TCP Wrappers</title>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="kerberosIV">
    <title><application>KerberosIV</application></title>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="kerberos5">
    <title><application>Kerberos5</application></title>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="openssl">
    <title>OpenSSL</title>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="ipsec">
    <title>IPsec</title>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="openssh">
    <title>OpenSSH</title>

    <sect2 id="security-ssh-tunneling">
      <title>SSH Tunneling</title>

      <para>Traduzione in corso</para>
    </sect2>
  </sect1>

  <sect1 id="fs-acl">
    <title>File System Access Control Lists</title>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="security-portaudit">
    <title>Monitoring Third Party Security Issues</title>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="security-advisories">
    <title>&os; Security Advisories</title>

    <para>Traduzione in corso</para>
  </sect1>

  <sect1 id="security-accounting">
    <title>Process Accounting</title>

    <para>Traduzione in corso</para>
  </sect1>
</chapter>