This file is indexed.

/usr/share/doc/HOWTO/fr-html/Domain.html is in doc-linux-fr-html 2013.01-3ubuntu1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

   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
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.2.0">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.72">
<title>Installation de votre nouveau domaine Mini-HOWTO</title>
</head>
<body>
<h1>Installation de votre nouveau domaine Mini-HOWTO</h1>
<h2>Christopher Neufeld
<code>&lt;neufeld@linuxcare.com&gt;</code><br>
Traduction française par Geneviève Gracian
<code>&lt;ggracian@free.fr&gt;</code> le 7 février 2001</h2>
version 0.12 du 17 octobre 2000
<hr>
<em>Ce document survole les opérations que vous serez probablement
amené à réaliser quand vous voudrez mettre en place un réseau
d'ordinateurs sous votre propre domaine. Il couvre la configuration
du réseau, des services réseau ainsi que les paramétrages relatifs
à la sécurité.</em>
<hr>
<h2><a name="s1">1. Notes</a></h2>
<h2><a name="ss1.1">1.1 Mise en garde</a></h2>
<p>Ce texte est une introduction. J'ai passé sous silence beaucoup
de choses qui pourraient être présentées bien plus en détail et
j'ai, probablement, raté entièrement des paragraphes importants.
Toute suggestion concernant des compléments, suppressions, ou
aspects sur lesquels je devrais donner plus ou moins de précisions
est la bienvenue.</p>
<h2><a name="ss1.2">1.2 Nouvelles versions de ce document</a></h2>
<p>La version la plus récente de ce document peut être trouvée
à&nbsp;: <a href=
"http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/">http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/</a>.</p>
<h2><a name="ss1.3">1.3 Copyright</a></h2>
<p>Copyright (c) Christopher Neufeld. Ce document peut être
distribué selon les termes et conditions énoncés dans la licence
LDP à l'adresse <a href=
"http://www.linuxdoc.org/COPYRIGHT.html">http://www.linuxdoc.org/COPYRIGHT.html</a>.</p>
<h2><a name="s2">2. Introduction</a></h2>
<p>Le présent document est un guide pour mettre en place votre
propre domaine de machines Linux ou d'un mélange de machines Linux
et de machines Windows sur une connexion permanente avec une IP
fixe et un domaine propre.</p>
<p>Il n'est pas vraiment approprié pour des installations qui
utilisent des adresses IP dynamiques, ou qui sont régulièrement
déconnectées de leur fournisseur d'accès pendant de longues
périodes&nbsp;; cependant, des conseils de base pour mettre en
place de telles installations figurent dans la section <a href=
"#IP_dynamique">Utiliser une IP dynamique</a>.</p>
<p>Avec la démocratisation des connexions permanentes et des IPs
statiques, il est devenu plus aisé pour les personnes et les
organisations de mettre en place un véritable domaine avec la
présence internet qui y est associée. Une planification rigoureuse
peut réduire les problèmes pouvant se poser par la suite.</p>
<p>L'essentiel de ce document décrit les techniques pour mettre en
place une sécurité discrète sur le réseau nouvellement exposé. Il
traite de la protection contre les attaques extérieures et contre
les attaques internes «&nbsp;fortuites&nbsp;». Il ne prétend pas
proposer une une installation extrêmement sécurisée mais en général
suffisante pour dissuader les agresseurs les moins obstinés.</p>
<p>Ce document s'adresse en premier lieu à de petites organisations
ayant un réseau préexistant, éventuellement une connexion
«&nbsp;dial-up&nbsp;» partagée, qui cherchent à évoluer vers une
connexion permanente relativement rapide, tant pour mettre en
oeuvre des échanges de fichiers avec le monde extérieur que pour
créer un site www ou ftp. Il concerne également de nouvelles
organisations qui veulent sauter les étapes préliminaires et mettre
en place tout de suite une connexion rapide et héberger des
services sous leur propre domaine.</p>
<p>Tout au long de ce document, je traiterai de la configuration
d'un nouveau réseau enregistré sous le nom de <b>example.com</b>.
Notez que example.com est réservé par l'IANA pour une utilisation
dans les documentations et, par conséquent, ne correspondra jamais
à un domaine existant.</p>
<p>La plupart des informations du présent document est disponible
ailleurs. J'ai essayé de synthétiser l'essentiel concernant la
création d'un nouveau domaine. Si les détails sur un sujet
spécifique semblent «&nbsp;simplets&nbsp;», vous pouvez consulter
un des documents plus explicites.</p>
<p>Ce document couvrira également le cas d'un environnement mixte
composé de plusieurs systèmes d'exploitation. Plus spécialement je
suppose que les postes de travail fonctionnent sous Windows, alors
que les serveurs et passerelles fonctionnent sous Linux.</p>
<h2><a name="s3">3. Définir la topologie de votre réseau</a></h2>
<p>Bien qu'il existe des arguments en faveur de différentes
architectures, les exigences de bien des organisations peuvent être
satisfaites en intégrant les postes de travail et les serveurs
privés dans un réseau privé, et les machines publiques sur des
adresses IP externes valides. Les machines possédant les adresses
IP publiques seront appelées dans la suite de ce document
«&nbsp;hôtes exposés&nbsp;». Ceci conduit à la topologie suivante
(exemple)&nbsp;:</p>
<pre>
+--------------+
|              |               +---------------+
| routeur du   |---------------| serveur FTP   |
| fournisseur  |        |      +---------------+
| d'accès      |        |      
|              |        |
+--------------+        |      +----------------+
                        |------| serveur WWW #1 |
                        |      +----------------+
                        |
                        |      +----------------+
                        |------| serveur WWW #2 |
                        |      +----------------+
                        |
                        ~
                        ~
                        |
                        |      +---------------+
                        |------| passerelle    |
                               | de réseau     |
                               | privé         |
                               +---------------+
                                       |
                                       |
                                       |
                                       |
      +------------+                   |      +------------------+
      | station #1 |-------------------|------| serveur privé #1 |
      +------------+                   |      +------------------+
                                       |
             .      -------------------|--------        .
             .                         |                .
             .      -------------------|--------        .
                                       |
      +------------+                   |      +------------------+
      | station #N |-------------------|------| serveur privé #N |
      +------------+                          +------------------+
</pre>
<p>Dans cet exemple, le routeur du FAI (fournisseur d'accès
Internet -- provider--), le serveur FTP, les serveurs WWW et la
machine désignée comme passerelle de réseau privé ont tous des
adresses IP visibles depuis l'extérieur, alors que les stations et
les serveurs privés ont des adresses IP réservées pour une
utilisation privée. Voir la RFC1918&nbsp;: <a href=
"http://www.ietf.org/rfc/rfc1918.txt">http://www.ietf.org/rfc/rfc1918.txt</a>&nbsp;;
<a href=
"http://abcdrfc.free.fr/rfc-vf/rfc1918.html">http://abcdrfc.free.fr/rfc-vf/rfc1918.html</a>
en version française. Les adresses IP que vous choisissez pour
votre réseau privé (tout ce qui est sous votre passerelle de réseau
privé) doivent être uniques, mais pas seulement par rapport à
l'ensemble des hôtes qui sont sous votre contrôle&nbsp;; elles ne
doivent pas non plus entrer en conflit avec des adresses attribuées
dans les autres réseaux privés similaires, sur d'autres sites ou
partenaires, avec lesquels vous pourriez vouloir un jour développer
un réseau privé virtuel&nbsp;; et ceci dans le but d'éviter
déboires et reconfigurations lorsque les deux réseaux seront reliés
de cette manière. Comme indiqué dans la RFC, vous pouvez opter pour
un réseau de classe C entre les plages d'adresses 192.168.0.* et
192.168.255.*, un réseau de classe B compris entre les plages
d'adresses 172.16.*.* et 172.31.*.*, ou bien, un réseau de classe A
10.*.*.*. Dans la suite de ce document, je supposerai que votre
réseau privé (si vous avez choisi d'en créer un) est un réseau de
classe C sur la plage 192.168.1.*, que l'interface extérieure de
votre passerelle de réseau privé a l'adresse IP 10.1.1.9, une des
adresses qui vous ont été allouées par le FAI (notez qu'il ne
s'agit pas d'une adresse publique valide, je ne l'utilise que comme
exemple). Je supposerai également qu'il y a une machine,
betty.example.com à l'adresse 10.1.1.10, qui supporte simultanément
le service FTP et le service www.</p>
<p>Faites le compte du nombre d'adresses IP externes dont vous avez
besoin pour vos machines. Vous aurez besoin d'une adresse pour
chacune des machines installées du coté externe de la passerelle de
réseau privé, plus une pour la passerelle elle-même. Ce compte
n'inclut pas toute IP qui pourrait être attribuée à d'autres
routeurs, adresses de diffusion, etc. Vous devez demander à votre
fournisseur d'accès un bloc d'adresses suffisamment grand pour
mettre en place toutes vos machines. Par exemple, sur mon réseau
professionnel, parmi les huit adresses IP allouées par le FAI,
trois n'étaient pas utilisables par mes ordinateurs, laissant la
place pour quatre machines à l'extérieur de la passerelle, plus la
passerelle elle-même.</p>
<p>Cette topologie de réseau ne vaut pas pour tout le monde, mais
elle constitue un point de départ raisonnable pour beaucoup de
configurations qui n'ont pas de besoin particulier. Les avantages
de cette configuration sont les suivants &nbsp;:</p>
<ul>
<li>facilité de développement. Si vous souhaitez doubler le nombre
de vos noeuds dans le réseau privé, vous n'avez pas besoin de faire
appel à votre fournisseur pour obtenir une plage d'adresses
supplémentaire ni reconfigurer l'ensemble des interfaces de vos
machines.</li>
<li>contrôle local du réseau. Ajouter une nouvelle station de
travail sur votre réseau privé ne requiert aucune intervention de
votre provider, contrairement à l'ajout d'hôtes exposés&nbsp;;
ceux-ci ont besoin d'être cartographiés (connus) dans les bases de
données DNS (direct et inversé) s'ils veulent accomplir certaines
tâches (ssh et ftpd risquent de se plaindre s'il ne peuvent faire
du DNS direct ou du DNS inversé sur des connexions entrantes). Une
requête DNS inversé se fait dans le but d'obtenir le nom d'hôte à
partir de l'adresse IP.</li>
<li>sécurité centralisée. La passerelle de réseau privé, en
filtrant les paquets et notant les attaques, permet de mettre en
vigueur les règles de sécurité sur l'ensemble du réseau privé
plutôt que d'avoir à installer de telles mesures sur chacun des
serveurs et stations du réseau privé. Ceci est applicable non
seulement pour les paquets entrants mais aussi pour les paquets
sortants de sorte qu'une station mal configurée ne peut pas, par
erreur, diffuser au monde extérieur une information qui doit rester
interne.</li>
<li>déplacement facilité. Du fait que les adresses IP à l'intérieur
du réseau privé sont les vôtres pour autant de temps que vous le
souhaitez, vous pouvez transposer l'ensemble du réseau sur une
nouvelle série d'adresses IP publiques sans avoir à effectuer une
quelconque modification de la configuration du réseau privé. Bien
sûr, les hôtes publics nécessitent quand même d'être
reconfigurés.</li>
<li>accès à Internet transparent. Les machines du réseau privé
peuvent continuer à utiliser FTP, telnet, WWW, et autres services
avec un minimum d'embarras moyennant un camouflage
«&nbsp;Linux-Masquerading&nbsp;». Les utilisateurs peuvent même
n'avoir jamais conscience que leurs machines n'ont pas d'adresse IP
visible depuis l'extérieur.</li>
</ul>
<p>Les désavantages potentiels de ce type de configuration sont les
suivants &nbsp;:</p>
<ul>
<li>certains services ne seront pas disponibles directement sur les
machines du réseau interne. La synchronisation NTP avec un hôte
extérieur, quelques obscurs services dont les règles de masquage ne
sont pas supportées dans le noyau, et l'authentification .shosts
sur des hôtes externes sont tous difficiles voire impossibles, mais
il existe quasiment toujours des procédures de contournement.</li>
<li>coûts de matériel réseau plus élevé. La passerelle de réseau
privé nécessite deux cartes réseau, et vous avez besoin d'au moins
deux concentrateurs (hubs) ou commutateurs (switchs), l'un sur le
réseau visible, l'autre sur le réseau privé.</li>
<li>Les machines localisées à l'extérieur du réseau privé ne
peuvent pas facilement se connecter sur les machines à l'intérieur
du réseau privé. Elles doivent d'abord ouvrir une session sur la
passerelle de réseau privé, puis se connecter au travers de
celle-ci sur l'hôte interne. Il est possible de router des paquets
de manière transparente à travers le pare-feu (firewall), mais ceci
n'est pas recommandé pour des raisons de sécurité qui seront
abordées plus tard.</li>
</ul>
<p>Vous devriez tenir compte de tous ces points lors de
l'élaboration de la topologie de votre réseau, et décider si un
réseau entièrement visible est mieux adapté à votre cas. Dans la
suite du document, je supposerai que vous avez configuré votre
réseau comme montré ci-dessus. Si vous avez opté pour un réseau
entièrement visible, certains détails différeront, et j'essayerai
de signaler de telles différences.</p>
<p>Au cas où vous n'auriez pas besoin de serveur externe, le
routeur fourni par le provider peut être directement connecté à
l'interface externe de la passerelle de réseau privé, plutôt que
par l'intermédiaire d'un hub.</p>
<h2><a name="s4">4. Vous procurer votre connexion</a></h2>
<h2><a name="ss4.1">4.1 Choisir votre fournisseur d'accès</a></h2>
<p>Comme pour tout, prospectez. Déterminez quelle est l'offre de
services dans votre région, aussi bien que les coûts associés à
chacun de ces services. Toutes les lieux ne sont pas câblés pour
DSL, et certaines ne sont pas appropriés pour des connexions sans
fils, à cause de contraintes géographiques, architecturales ou
environnementales. Dans la mesure où la rapidité des liaisons DSL
est intimement liée à la distance entre le point de liaison et le
switch, soyez prêt à fournir l'adresse postale du lieu où la tête
de votre liaison sera localisée, et posez également des questions
précises sur la bande passante entre votre machine et le
fournisseur d'accès, sur ce qui doit être fait pour installer la
connexion et sur le matériel dont la location est comprise dans le
forfait mensuel proposé. Vous devez également avoir une idée du
nombre d'adresses IP dont vous avez besoin pour vos machines
propres (rappelez-vous que les adresses de la série que vous
obtiendrez ne seront pas toutes utilisables pour vos ordinateurs).
Demandez au fournisseur d'accès quelle est sa bande passante totale
vers l'extérieur car la vitesse déclarée dans sa proposition
financière ne concerne que la liaison entre votre site et le sien.
Si le provider a une bande passante insuffisante vers l'extérieur,
ses clients auront à pâtir de goulots d'étranglements à l'intérieur
de son réseau.</p>
<p>Une fois que vous avez présélectionné une liste de candidats,
renseignez-vous, voyez si personne ne peut vous conseiller sur les
prestataires que vous envisagez. Demandez leur quel type de bande
passante ils obtiennent vers des sites non chargés. En outre, si
vous avez l'intention d'avoir des connexions rapides entre le
nouveau domaine et un accès internet personnel depuis chez vous,
pour télétravailler ou bien pour faire de l'administration à
distance, il est essentiel que vous fassiez un <i>traceroute</i>
depuis votre connexion personnelle vers un hôte localisé chez le
prestataire envisagé. Ceci vous renseignera sur le nombre de
«&nbsp;pas&nbsp;», et la latence auxquels vous devez vous attendre
entre chez vous et le nouveau domaine. Des latences supérieures à
100-200 millisecondes peuvent être problématiques pour des
utilisations prolongées. Le <i>traceroute</i> doit être lancé aux
moments de la journée pendant lesquels vous souhaitez utiler une
connexion réseau entre votre domicile et le nouveau domaine.</p>
<h2><a name="ss4.2">4.2 Faire les préparatifs pour l'installation
matérielle</a></h2>
<p>Après avoir choisi le fournisseur et le type d'accès pour le
nouveau domaine, renseignez-vous sur les détails de l'installation.
Vous pouvez aussi bien avoir besoin d'une prestation de l'opérateur
téléphonique en plus de celle du FAI afin de mettre en place
l'accès, et les techniciens peuvent avoir besoin d'accéder à des
zones contrôlées de vôtre bâtiment&nbsp;; informez donc votre
«&nbsp;responsable de la maintenance immobilière&nbsp;» des
nécessités de l'installation. Avant que le technicien de l'ISP
n'arrive, demandez les paramètres, tout spécialement les adresses
IP, le masque de réseau, l'adresse de diffusion, l'adresse de la
passerelle de routage, celle du serveur DNS, et également quel type
de câblage est nécessaire pour le matériel apporté par le
technicien (par exemple câble droit ou câble croisé RJ45,
etc.).</p>
<p>Ayez une machine disponible pour les tests, et installez-la à
proximité de l'endroit où le matériel de connexion au réseau sera
localisé. Si possible, configurez-la avant que le technicien du
prestataire n'arrive en paramétrant son adresse IP et le masque de
réseau. Ayez également les câbles appropriés sous la main de façon
à ce que les tests puissent être faits rapidement.</p>
<h2><a name="ss4.3">4.3 Tester la connexion</a></h2>
<p>Une fois que votre machine de test est reliée au matériel du
provider, assurez-vous que vous pouvez faire un <i>ping</i> sur une
machine au delà du FAI. Si ce n'est pas possible, un
<i>traceroute</i> vers l'extérieur peut vous aider à localiser la
défaillance de la connexion. Si le traceroute ne montre aucun
«&nbsp;pas&nbsp;» réussi, cela indique que la configuration réseau
de votre machine (route par défaut, adresse de l'interface, pilote
de la carte, DNS, etc.) n'est pas bonne. Si un seul
«&nbsp;pas&nbsp;» est réussi, cela peut signifier que le routeur
n'est pas correctement configuré pour communiquer avec le FAI. Si
plusieurs «&nbsp;pas&nbsp;» sont réussis avant la défaillance, le
problème est très certainement localisé chez le provider ou bien à
l'extérieur, et hors de de votre contrôle immédiat.</p>
<h2><a name="IP_dynamique"></a> <a name="ss4.4">4.4 Utiliser une IP
dynamique</a></h2>
<p>Les avantages d'une connexion d'entreprise avec une plage
d'adresses IP statiques et l'hébergement de divers services
entraînent un coût. Elle peut être 10 fois plus onéreuse qu'une
connexion personnelle à haut débit avec DSL ou un modem-câble. Si
votre budget ne peut supporter une telle connexion ou bien si ce
type de connexion n'est pas disponible dans votre région, vous
voudrez certainement essayer de mettre en place votre domaine sur
une IP dynamique. En général, plutôt qu'une plage d'adresses vous
n'obtiendrez qu'une seule adresse, ce qui veut dire que votre
passerelle de réseau privé devra également héberger tous les
services accessibles depuis l'extérieur.</p>
<p>D'abord vous devriez vérifier si c'est faisable. Beaucoup de
contrats de prestataires interdisent explicitement la mise en place
de services accessibles depuis l'extérieur sur des comptes
personnels. Les prestataires peuvent faire appliquer cette règle
par la mise en place d'un filtrage de paquets bloquant les
connexions entrantes sur les ports http et FTP. Vous devez
également être attentif au fait que la vitesse de transfert
mentionnée dans l'offre pour des accès DSL ou modem-câble est la
vitesse de la voie descendante, et que la voie montante peut être
beaucoup plus lente. La bande passante montante est ce qui est
important pour offrir des contenus web ou FTP.</p>
<p>Si vous avez une IP dynamique et que vous voulez avoir des
connexions entrantes, vous devez vous inscrire à un service
d'hébergement d'IP dynamique tels que ceux listés sur Dynamic DNS
Providers (à l'adresse <a href=
"http://www.technopagan.org/dynamic">http://www.technopagan.org/dynamic</a>).
Ces services fonctionnent ordinairement en exécutant un logiciel
sur votre machine qui communique votre adresse IP actuelle aux
serveurs de l'hébergeur. Quand votre adresse IP est connue de
ceux-ci, leurs tables DNS sont mises à jour pour tenir compte de la
nouvelle valeur. Vous pouvez aussi obtenir un nom de domaine sous
leur nom de domaine, tel que «&nbsp;example.dynip.com&nbsp;» ou
bien «&nbsp;example.dynhost.com&nbsp;», ou bien vous pouvez
enregistrer votre propre domaine et faire pointer le DNS primaire
sur la société fournissant ce service (c'est habituellement plus
cher).</p>
<p>Il existe également un service d'hébergement gratuit à Domain
Host Services (à l'adresse <a href=
"http://www.dhs.org">http://www.dhs.org</a>). Ce service semble
assez récent et il y a peu de détails sur le site web pour
l'instant, mais vous trouverez peut-être que cela vaut le coup
d'être étudié.</p>
<p>Si vous avez mis en place une IP dynamique, et que vous êtes
abonné à l'un de ces services, cela influera sur certaines
décisions que vous ferez dans la section <a href=
"#services_heberges">Décider des services que vous hébergerez</a>.
En particulier, cela ne sert à rien de vous abonner à un service
d'hébergement d'IP dynamique si vous n'envisagez pas de mettre en
place au moins un des services web ou FTP. Vous devrez configurer
le DNS primaire de façon à ce qu'il pointe sur la société que vous
avez choisie. Vous ne devez pas avoir un démon <i>named</i> qui
répond à des requêtes émanant de l'extérieur de votre réseau privé.
D'autres éléments tels que le transport du courrier électronique,
dépendront des spécificités du service auquel vous vous êtes
abonné, et peuvent mieux être expliqués par le service d'assistance
de cette société.</p>
<p>Une remarque finale&nbsp;: si vous voulez avoir un accès distant
à une machine avec une IP dynamique, machine qui n'hébergera pas
d'autres services, une solution bon marché est de créer une
«&nbsp;boite de dépôt&nbsp;» sur une machine publique avec une IP
statique et de faire en sorte que l'hôte ayant une IP dynamique
envoie son adresse IP à cet endroit, soit par mél ou tout
simplement en l'inscrivant dans un fichier sous un compte shell.
Quand vous voulez accéder à distance à votre machine, récupérez
d'abord l'adresse IP actuelle dans la «&nbsp;boite de dépôt&nbsp;»,
puis utilisez <i>slogin</i> pour vous attacher directement à cette
adresse IP. C'est, somme toute, tout ce que fait un service
d'hébergement d'adresses IP dynamiques, il le fait juste de manière
automatique au dessus des services standards, vous épargnant des
manipulations.</p>
<h2><a name="s5">5. Enregistrer un nom de domaine</a></h2>
<p>Afin que les personnes du monde extérieur puissent localiser vos
serveurs sous le nom de domaine de votre choix, que ce soit pour le
web, pour le FTP ou pour la messagerie électronique, vous devrez
enregistrer ce nom de domaine afin qu'il soit intégré dans la base
de données du domaine de premier niveau adéquat.</p>
<p>Usez de prudence en choisissant votre nom de domaine. Certains
mots ou locutions peuvent être interdits en raison de coutumes
locales, ou pourraient être choquants pour des personnes dont le
langage ou l'argot diffère de celui de votre région. Les noms de
domaine peuvent contenir les 26 caractères de l'alphabet latin
(sans accents), le tiret (quoique celui-ci ne peut être mis au
début ou la fin du nom), et les dix chiffres. Les noms de domaines
ne sont pas sensibles à la casse, et peuvent avoir une longueur
maximale de 26 caractères (cette limite est susceptible de
changer). Faites attention à ne pas enregistrer un nom de domaine à
propos duquel vous ne pouvez pas raisonnablement faire valoir que
vous ne saviez pas que celui-ci empétait sur des marques déposées
par des sociétés existantes, les tribunaux ne sont pas indulgents
pour les «&nbsp;cyber-squatters&nbsp;». Des informations concernant
les situations dans lesquelles votre nom de domaine humblement
choisi peut être retiré de votre contrôle sont disponibles dans le
document de l'ICANN «&nbsp;Politique pour une résolution des
conflits sur les noms de domaines&nbsp;» à l'adresse <a href=
"http://www.icann.org/udrp/udrp-policy-24oct99.htm">http://www.icann.org/udrp/udrp-policy24oct99.htm</a>
(en français&nbsp;: <a href=
"http://www.juriscom.net/pro/2/ndm20001011.htm">http://www.juriscom.net/pro/2/ndm20001011.htm</a>).</p>
<p>Il existe beaucoup de sociétés qui proposent l'enregistrement de
noms dans les domaines de premier niveau «&nbsp;.com&nbsp;»,
«&nbsp;.net&nbsp;» et «&nbsp;.org&nbsp;». Pour une liste à jour,
vérifiez la liste de prestataires conventionnés à l'adresse
<a href="http://www.icann.org/registrars/accredited-list.html">http://www.icann.org/registrars/accredited-list.html</a>.
Pour enregistrer un nom dans un domaine de premier niveau
géographique, tel que «&nbsp;.fr&nbsp;», «&nbsp;.ca&nbsp;»,
«&nbsp;.de&nbsp;», «&nbsp;.uk&nbsp;», etc., cherchez quelle est
l'autorité appropriée, ce renseignement pouvant être trouvé dans la
base de données des Country Code Top-Level Domains à l'adresse
<a href=
"http://www.iana.org/cctld.html">http://www.iana.org/cctld.html</a>.</p>
<h2><a name="services_heberges"></a> <a name="s6">6. Décider des
services que vous hébergerez</a></h2>
<p>La plupart des fournisseurs d'accès «&nbsp;full-service&nbsp;»
proposent à leur clients un éventail de services relatifs au
domaine. Ceci est largement dû à la difficulté d'héberger ces
services avec certains autres systèmes d'exploitation, plus
populaires, pour machines de bureau et serveurs. Ces services sont
beaucoup plus faciles à mettre en oeuvre sous Linux et peuvent être
hébergés sur des matériels peu onéreux. Vous devriez donc décider
des services que vous voulez garder sous votre contrôle. Certains
de ces services sont&nbsp;:</p>
<ul>
<li>DNS primaire (le service DNS principal pour votre domaine).
Voyez la section <a href="#dns_primaire">DNS primaire</a></li>
<li>Messagerie électronique. Reportez-vous à la section <a href=
"#messagerie_electronique">Messagerie électronique</a></li>
<li>Hébergement de site web. Reportez-vous à la section <a href=
"#hebergement_web">Hébergement de site web</a></li>
<li>Hébergement de site FTP. Reportez-vous à la section <a href=
"#hebergement_ftp">Hébergement de site FTP</a></li>
<li>Filtrage de paquets. Reportez-vous à la section <a href=
"#filtrage_de_paquets">Filtrage de paquets</a></li>
</ul>
<p>Pour chacun de ces services vous devez évaluer l'intérêt d'en
garder le contrôle. Si votre FAI propose un ou plusieurs de ces
services, vous pouvez généralement avoir l'assurance qu'il a du
personnel expérimenté pour la gestion de ceux-ci&nbsp;; aussi, vous
aurez moins à apprendre et moins de soucis. Parallèlement à cela,
vous perdez la maîtrise de ces services. La moindre modification
impose que vous passiez par le FAI, chose qui peut ne pas être
pratique ou demander des délais plus longs que vous ne le voudriez.
Il y a aussi une question de sécurité, le FAI est une cible
beaucoup plus tentante pour les agresseurs que votre propre site.
Dans la mesure où les serveurs d'un FAI peuvent héberger la
messagerie et/ou les sites web de douzaines de sociétés qui sont
ses clients, un pirate qui endommage un de ces serveurs obtient une
bien meilleure récompense à ces efforts que celui qui attaque votre
serveur personnel où les seules données d'une entreprise sont
stockées.</p>
<h2><a name="dns_primaire"></a> <a name="ss6.1">6.1 DNS
primaire</a></h2>
<p>Quand une personne, quelque part, dans le monde extérieur,
demande à se connecter sur une machine du nouveau domaine
example.com, les requêtes transitent par des serveurs divers sur
internet&nbsp;; et finalement l'adresse IP de la machine est
renvoyée au logiciel de la personne qui demande la connexion. Le
détail de cette séquence est au delà de l'objet de ce document.
Sans entrer dans les détails, quand une demande est faite pour la
machine fred.example.com, une base de données centralisée est
questionnée pour déterminer quelle est l'adresse IP de la machine
qui a l'autorité administrative sur la zone example.com. L'adresse
IP obtenue est ensuite questionnée pour obtenir l'adresse IP de
fred.example.com.</p>
<p>Il doit exister un DNS primaire et un DNS secondaire pour chaque
nom de domaine. Les noms et adresses de ces deux serveurs sont
enregistrés dans une base de données dont les entrées sont
contrôlées par des autorités de nommage telles que «&nbsp;Network
solutions&nbsp;» (à l'adresse <a href=
"http://www.networksolutions.com">http://www.networksolutions.com</a>).</p>
<p>Si vous avez opté pour un DNS primaire hébergé par le FAI, ces
deux machines seront probablement contrôlées par celui-ci. À chaque
fois que vous voudrez ajouter à votre réseau une machine visible
depuis l'extérieur, vous devrez contacter le FAI pour lui demander
d'ajouter la nouvelle machine à sa base de données.</p>
<p>Si vous avez choisi de gérer le DNS primaire sur votre propre
machine, vous devrez également utiliser une deuxième machine comme
serveur secondaire. Techniquement, vous devriez la localiser sur
une connexion internet redondante , mais l'hébergement du DNS
secondaire sur l'une des machines du FAI est très répandu. Si vous
voulez ajouter à votre réseau une machine visible depuis
l'extérieur, vous devrez mettre à jour votre propre base de données
et ensuite attendre que la modification se propage (chose qui,
habituellement, prend un petit nombre d'heures). Ceci vous permet
d'ajouter barney.example.com sans passer par votre FAI.</p>
<p>C'est une bonne idée de mettre en oeuvre le DNS secondaire sur
un hôte distant du point vue géographique&nbsp;; ainsi, une simple
rupture de câble du coté de votre FAI ne met pas simultanément
hors-ligne vos serveurs DNS primaire et secondaire. Le prestataire
d'enregistrement de nom que vous avez utilsé pour enregistrer votre
domaine peut fournir un service de DNS secondaire. Il existe
également un service gratuit, Granite Canyon (à l'adresse <a href=
"http://www.granitecanyon.com">http://www.granitecanyon.com</a>),
disponible pour qui le demande.</p>
<p>Indépendamment du fait que vous avez choisi ou non de constituer
vous même l'autorité DNS principale pour votre domaine, voyez la
section <a href="#mise_en_place_DNS">Mettre en place la résolution
de noms</a> pour une aide concernant la configuration. Vous aurez
besoin d'un système de résolution de noms au sein de votre réseau
privé, même si vous déléguez le DNS primaire à votre FAI.</p>
<h2><a name="messagerie_electronique"></a> <a name="ss6.2">6.2
Messagerie électronique</a></h2>
<p>En général, quand vous vous abonnez chez votre FAI, celui-ci
vous fournit un certain nombre d'adresses de messagerie. Vous
pouvez choisir de n'utiliser que cette possibilité, auquel cas tous
les messages entrants sont stockés sur le serveur du FAI et vos
utilisateurs lisent leur courrier avec des clients POP3 qui se
connectent sur le serveur du FAI. D'une autre manière, vous pouvez
décider d'installer la messagerie sur vos propres machines. Une
fois de plus, vous devez peser le pour et le contre de chacune des
deux possibilités et choisir celle qui vous convient le mieux.</p>
<p>Ce dont il faut se rappeler si vous utilisez les services de
l'ISP pour la messagerie&nbsp;:</p>
<ul>
<li>Il sera plus facile d'accéder à la messagerie depuis votre
domicile, ou depuis d'autres lieux quand vous êtes en déplacement
professionnel, en fonction du type de sécurité que vous utilisez
pour votre domaine.</li>
<li>Les messages sont stockés sur les serveurs de l'ISP, ce qui
peut poser problème si des données confidentielles sont envoyées
sans avoir été chiffrées.</li>
<li>Vous avez un nombre d'adresses limité, et vous pouvez être
amené à payer un supplément si vous dépassez cette limite.</li>
<li>Pour créer de nouvelles adresses, vous devez passer par le
FAI.</li>
</ul>
<p>Ce dont il faut se rappeler si vous gérez vous-même la
messagerie&nbsp;:</p>
<ul>
<li>Les messages sont stockés sur vos serveurs, avec des
enregistrements de sauvegarde chez l'ISP si votre serveur de
messagerie tombe ou si le disque se sature.</li>
<li>Vous avez un nombre illimité de comptes de messagerie, que vous
pouvez créer et supprimer vous-même.</li>
<li>Vous devez supporter les logiciels clients de messagerie
utilisés sur votre réseau privé et, éventuellement, ceux utilisés
par les personnes qui essayent de lire leur courrier depuis leur
domicile.</li>
</ul>
<p>Une approche possible est d'héberger la messagerie vous-même et,
en supplément, d'utiliser quelques unes des adresses fournies par
le FAI. Les personnes qui ont besoin d'une messagerie accessible
depuis l'extérieur du réseau privé peuvent avoir des adresses dans
votre domaine qui sont redirigées sur l'une des adresses fournies
par l'ISP. Les autres peuvent avoir une messagerie locale sur le
réseau privé. Ceci requiert un petit peu plus de coordination et de
configuration, mais donne plus de flexibilité que chacune des
autres approches.</p>
<p>Si vous choisissez d'héberger la messagerie pour votre domaine,
reportez-vous à la section <a href=
"#mise_en_place_messagerie">Mettre en place la messagerie
électronique</a></p>
<p>Si vous décidez de ne pas héberger la messagerie pour votre
domaine, reportez-vous à la section <a href=
"#dns_sans_messagerie">Configuration du DNS si vous n'hébergez pas
le service de messagerie</a>.</p>
<h2><a name="hebergement_web"></a> <a name="ss6.3">6.3 Hébergement
du site web</a></h2>
<p>Votre FAI peut vous allouer une certaine quantité d'espace sur
ses serveurs web. Vous pouvez décider d'utiliser cette possibilité
ou vous pouvez avoir un serveur web que vous mettez dans votre
réseau externe, sur une des IPs externes.</p>
<p>Ce dont il faut se rappeler si vous choisissez d'utiliser
l'hébergement web du FAI&nbsp;:</p>
<ul>
<li>Vous avez une certaine quantité d'espace-disque allouée que
vous ne pouvez pas dépasser. Ceci n'inclut pas seulement le contenu
du site web mais aussi les données collectées auprès des visiteurs
du site.</li>
<li>La bande passante entre votre serveur web et le monde extérieur
sera certainement plus large que si vous hébergiez ce serveur sur
votre propre matériel. Dans tous les cas, elle ne peut pas être
plus lente.</li>
<li>Il peut s'avérer difficile d'installer des CGI personnalisées
ou des progiciels commerciaux sur votre serveur web.</li>
<li>La bande passante entre votre réseau et votre serveur web sera
certainement plus lente qu'elle ne le serait si vous hébergiez le
service sur votre propre réseau.</li>
</ul>
<p>Ce dont il faut se rappeler si choisissez d'héberger votre
propre serveur web.</p>
<ul>
<li>Vous avez plus de maîtrise sur le serveur. Vous pouvez façonner
votre sécurité de manière plus adaptée à votre utilisation.</li>
<li>Les données potentiellement critiques, telles que des numéros
de cartes de crédit ou des adresses mél, résident sur des machines
que vous contrôlez.</li>
<li>Votre stratégie de sauvegarde est probablement moins complète
que celle de votre FAI.</li>
</ul>
<p>Notez que je ne dis rien à propos du fait que l'ISP a du
matériel plus performant, des taux de transfert de données plus
élevés, et ainsi de suite. Au fil du temps, ces choses deviennent
importantes, et l'on parle de connexions réseaux à très hauts
débits, et, très franchement, vous auriez dû déléguer ces décisions
à un consultant spécialisé, pas regarder dans un HOWTO Linux.</p>
<p>Si vous choisissez d'héberger l'espace web de votre domaine sur
vos propres serveurs, reportez-vous à d'autres documents tels que
le WWW-HOWTO (à l'adresse <a href=
"ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO">ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO</a>
ou <a href=
"http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html">http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html</a>
en version française), pour la configuration. Pour des raisons de
sécurité, je vous recommande chaudement de faire fonctionner ce
service sur une autre machine que la passerelle de réseau
privé.</p>
<h2><a name="hebergement_ftp"></a> <a name="ss6.4">6.4 Hébergement
du site FTP</a></h2>
<p>Fondamentalement, les mêmes raisonnements qui s'appliquent à
l'hébergement WWW s'appliquent à l'hébergement FTP, à l'exception
du fait que le ftp n'est pas concerné par les contenus dynamiques
et que les scripts CGI n'y apparaissent pas. La plupart des
exploits récents sur des serveurs ftpd ont été réalisés par des
débordements de tampon consécutifs à la création de répertoires
ayant des noms longs dans des répertoires de téléchargement
modifiables par n'importe qui&nbsp;; ainsi, si votre FAI autorise
le téléchargement et se montre négligent dans la maintenance des
mises à jour de sécurité sur le serveur FTP, vous feriez aussi bien
d'héberger le service vous-même.</p>
<p>Dans le cas où vous choisissez d'héberger FTP pour votre domaine
sur vos propres serveurs, assurez-vous d'avoir la dernière version
du démon FTP, et consultez les instructions de configuration. Une
fois de plus, je recommande fortement, pour des raisons de
sécurité, que ce service fonctionne sur une autre machine que la
passerelle de réseau privé.</p>
<p>Pour <i>wu-ftpd</i>, je recommande les options de configuration
suivantes&nbsp;:</p>
<ul>
<li>--disable-upload (à moins que n'ayez besoin du téléchargement
anonyme)</li>
<li>--enable-anononly (incite vos utilisateurs locaux à utiliser
scp pour le transfert de fichier entre les machines)</li>
<li>--enable-paranoid (désactive toute fonctionnalité de la version
courante qui peut être sujette à caution)</li>
</ul>
<h2><a name="filtrage_de_paquets"></a> <a name="ss6.5">6.5 Filtrage
de paquets</a></h2>
<p>Certains FAI mettent des filtres de paquets, pour protéger les
utilisateurs du système les uns des autres ou vis à vis
d'agresseurs externes. Les réseaux modem-câble et d'autres réseau à
diffusion similaires posent problème quand, sans le faire exprès,
des utilisateurs de Windows 95 ou 98 activent le partage de
fichiers mettant ainsi le contenu entier de leurs disques durs à la
vue de n'importe qui prend le soin d'explorer son «&nbsp;voisinnage
réseau&nbsp;» à la recherche de serveurs actifs. Dans certains cas,
la solution a été de dire aux utilisateurs de ne pas faire cela,
mais certains fournisseurs d'accès ont mis en place un filtrage
dans le matériel de connexion pour empêcher les gens d'exporter
leurs données par inadvertance.</p>
<p>Le filtrage de paquet est vraiment une chose que vous devriez
faire vous-même. Il s'intègre facilement dans le noyau fonctionnant
sur votre passerelle de réseau privé et vous donne une meilleure
idée de ce qui se passe autour de vous. En outre, il arrive souvent
que l'on veuille, pendant l'installation, procéder à de menus
ajustements sur le pare-feu pour l'optimiser, et c'est beaucoup
plus facile à faire en temps réel plutôt que par l'intermédiaire
d'un support technique.</p>
<p>Si vous choisissez de faire le filtrage de paquets pour votre
domaine, reportez-vous à la section <a href=
"#mettre_en_place_filtrage">Mettre en place le filtrage de
paquets</a>.</p>
<h2><a name="s7">7. Configurer les services hébergés</a></h2>
<h2><a name="mise_en_place_DNS"></a> <a name="ss7.1">7.1 Mettre en
place la résolution de noms</a></h2>
<p>Vous devrez mettre en place un moyen pour que les ordinateurs
sur votre réseau se reconnaissent par leur nom, et également que
les personnes à l'extérieur connaissent par leur nom vos machines
exposées. Il existe plusieurs moyens d'aboutir à ce résultat.</p>
<h3><a name="DNS_prive_FAI_gere_domaine"></a> résolution DNS sur le
réseau privé, le FAI gère le domaine</h3>
<p>(remarque&nbsp;: si vous avez choisi de ne pas mettre en place
un réseau privé, allez à la section <a href=
"#reseau_entierement_expose">Réseau entièrement exposé, hébergé par
le FAI</a>)</p>
<p>Dans cette configuration, vous avez délégué la responsabilité du
DNS primaire de votre domaine au FAI. Vous continuez à utiliser DNS
à l'intérieur de votre réseau privé quand les hôtes internes
veulent communiquer ensemble. Vous avez communiqué au FAI une liste
des adresses IP de l'ensemble des hôtes exposés. Si vous voulez
qu'une des machines visibles depuis l'extérieur, par exemple
betty.example.com, soit en même temps le serveur web et le serveur
FTP, vous devez demander au FAI de mettre en place des entrées
CNAME www.example.com et ftp.example.com qui pointent sur
betty.example.com.</p>
<p>Mettez en place le DNS sur votre passerelle de réseau privé.
Ceci peut être réalisé de manière sécurisée, et rendre les mises à
jour plus faciles, au cas où vous décidiez un jour d'héberger
l'autorité primaire du DNS.</p>
<p>Je supposerai que vous avez décidé d'héberger le DNS sur la
machine dns.example.com, qui est la passerelle de réseau privé, et
un surnom (alias) pour fred.example.com à l'adresse 192.168.1.1. Si
ce n'est pas le cas, de petites modifications doivent être faites à
votre configuration. Je ne traiterai pas de cela dans ce HOWTO à
moins que cela ne présente un véritable intérêt.</p>
<p>Vous devrez télécharger et compiler une version de BIND,
Berkeley Internet Name Domain. Il est disponible sur le site de
BIND (à l'adresse <a href=
"http://www.isc.org/products/BIND/">http://www.isc.org/products/BIND/</a>).
Ensuite vous devez configurer les démons. Créez le fichier
<code>/etc/named.conf</code> suivant&nbsp;:</p>
<hr>
<pre>
     options {
             directory "/var/named";
             listen-on { 192.168.1.1 };
     };
 
     zone "." {
             type hint;
             file "root.hints";
     };
 
     zone "0.0.127.in-addr.arpa" {
             type master;
             file "pz/127.0.0";
     };
 
     zone "1.168.192.in-addr.arpa" {
             type master;
             file "pz/1.168.192";
     };
 
     zone "example.com" {
             type master;
             notify no;
             file "pz/example.com";
     };
</pre>
<hr>
<p>Remarquez que nous nous sommes déclarés maîtres du domaine
example.com. Cependant, notre FAI se déclare aussi comme l'autorité
du même domaine. Ce n'est pas un problème tant que l'on fait
attention à l'installation. Toutes les machines du réseau privé
doivent utiliser dns.example.com pour mettre en oeuvre leur
résolution de noms. Elles ne doivent <i>pas</i> utiliser le
«&nbsp;resolver&nbsp;» de l'ISP dans la mesure où le le serveur de
nom de l'ISP croit qu'il fait authorité sur l'intégralité du
domaine mais ne connait pas les adresses IP ou les noms des
machines sur votre réseau privé. De la même manière, les hôtes
ayant les adresses publiques de votre domaine <i>doivent</i>
utiliser le serveur de noms du FAI, pas le serveur de nom privé sur
dns.example.com.</p>
<p>Les différents fichiers sous <code>/var/named</code> doivent
maintenant être créés.</p>
<p>Le fichier <code>root.hint</code> est tel que décrit dans la
documentation de BIND ou dans le DNS-HOWTO (à l'adresse <a href=
"ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/DNS-HOWTO">ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/DNS-HOWTO</a>&nbsp;;
<a href=
"http://www.freenix.org/unix/linux/HOWTO/DNS-HOWTO.html">http://www.freenix.org/unix/linux/HOWTO/DNS-HOWTO.html</a>).
À l'heure où j'écris, Ce qui suit est un fichier root.hint
valide.</p>
<hr>
<pre>
     H.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.63.2.53
     C.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.33.4.12
     G.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.112.36.4
     F.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.5.5.241
     B.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.9.0.107
     J.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.41.0.10
     K.ROOT-SERVERS.NET.     6d15h26m24s IN A  193.0.14.129
     L.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.32.64.12
     M.ROOT-SERVERS.NET.     6d15h26m24s IN A  202.12.27.33
     I.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.36.148.17
     E.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.203.230.10
     D.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.8.10.90
     A.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.41.0.4
</pre>
<hr>
<p>Le fichier <code>pz/127.0.0.0</code> est comme suit&nbsp;:</p>
<hr>
<pre>
@               IN      SOA     example.com. root.example.com. (
                                1       ; numéro de série
                                8H      ; mise à jour
                                2H      ; tentative après échec
                                1W      ; délai d'expiration
                                1D)     ; durée de vie minimale
                        NS      dns.example.com.
1                       PTR     localhost.
</pre>
<hr>
<p>Le fichier <code>pz/1.168.192</code> est comme suit&nbsp;:</p>
<hr>
<pre>
$TTL 86400
 
@       IN      SOA             dns.example.com. root.dns.example.com. (
                                1       ; numéro de série
                                8H      ; mise à jour            8 heures
                                2H      ; tentative après échec  2 heures
                                1W      ; délai d'expiration     1 semaine
                                1D      ; durée de vie minimale  1 jour
                        )
                NS      dns.example.com.
 
1               PTR     fred.example.com.
                PTR     dns.example.com.
                PTR     mail.example.com.
2               PTR     barney.example.com.
3               PTR     wilma.example.com.
</pre>
<hr>
<p>et ainsi de suite, où vous créez un enregistrement PTR pour
chacune des machines ayant une interface sur le réseau privé. Dans
cet exemple, fred.example.com est à l'adresse 192.168.1.1 et il est
«&nbsp;pointé&nbsp;» par les alias dns.example.com et
mail.example.com. La machine barney.example.com est à l'adresse IP
192.168.1.2 et ainsi de suite.</p>
<p>Le fichier <code>pz/example.com</code> est comme suit&nbsp;:</p>
<hr>
<pre>
$TTL 86400
 
@               IN      SOA     example.com. root.dns.example.com. (
                                1       ; numéro de série
                                8H      ; mise à jour             8 heures
                                2H      ; tentative après échec   2 heures
                                1W      ; délai d'expiration      1 semaine
                                1D      ; TTL minimale            1 jour
                        )
                        NS              dns.example.com.
        IN              A               192.168.1.1
        IN              MX          10  mail.example.com.
        IN              MX          20  &lt;IP de la machine de mail de l'ISP&gt;.
 
 
localhost               A           127.0.0.1
fred                    A           192.168.1.1
                        A           10.1.1.9
dns                     CNAME       fred
mail                    CNAME       fred
barney                  A           192.168.1.2
wilma                   A           192.168.1.3
betty                   A           10.1.1.10
www                     CNAME       betty
ftp                     CNAME       betty
</pre>
<hr>
<p>Dans la mesure où les machines à l'intérieur du réseau privé
n'ont pas intérêt à questionner le serveur de noms du FAI pour une
requête sur, disons, betty.example.com, remarquez que nous créons
des entrées tant pour les machines localisées à l'intérieur du
réseau privé que pour celles ayant des adresses IP externes. Nous
déclarons également chacune des deux adresses IP de fred, l'adresse
externe et l'adresse interne.</p>
<p>Une ligne dans la section «&nbsp;options&nbsp;» de
<code>/etc/named.conf</code> appelle une explication &nbsp;:</p>
<pre>
listen-on { 192.168.1.1 };
</pre>
<p>Elle empêche votre démon named de répondre à des requêtes DNS
sur son interface externe (toutes les requêtes émanant de
l'extérieur doivent passer par le serveur de nom du FAI, pas par le
vôtre).</p>
<h3>pas de résolution DNS sur le réseau privé, le FAI gère le
domaine</h3>
<p>(note&nbsp;: si vous avez décidé de ne pas mettre en oeuvre de
réseau privé, reportez-vous à la section <a href=
"#reseau_entierement_expose">Réseau pleinement exposé, hébergé par
le FAI</a>)</p>
<p>Dans cette configuration, vous avez tranché sur le fait que,
somme toute, votre réseau est peu étendu et qu'il est improbable
qu'il s'étende. Vous avez décidé de ne pas utiliser la base de
données centralisée d'un serveur de noms, et, en conséquence, de
maintenir la résolution de noms séparément sur chacune des
machines. Toutes les machines doivent donc utiliser le serveur de
noms de l'ISP pour résoudre les noms d'hôtes situés au delà de la
passerelle de réseau privé. Pour la résolution de nom au sein du
réseau privé, un fichier des hôtes doit être créé. Sous Linux, cela
signifie entrer les noms et les adresses IP de toutes les machines
dans le fichier <code>/etc/hosts</code> sur chacune des machines. À
chaque fois qu'un nouvel hôte est ajouté, ou qu'une adresse IP est
changée, ce fichier doit être modifié sur chaque Linuxette.</p>
<p>Comme dans la section <a href="#DNS_prive_FAI_gere_domaine">le
DNS est sur le réseau privé, le FAI gère le domaine</a>, la liste
des hôtes ayant des adresses IP publiques doit être communiquée au
FAI et chaque alias (tels que les noms www et ftp) doit être
spécifié dans une entrée CNAME créée par le FAI.</p>
<h3>vous êtes l'autorité DNS primaire pour le domaine</h3>
<p>Bien que vous puissiez mettre en oeuvre la résolution
<i>named</i> sur les hôtes exposés, et une base de données privée
de résolution pour le réseau privé, je ne m'étendrai pas sur ce
cas. Si vous envisagez d'utiliser named pour un service, vous
devriez vraiment le faire pour tous, juste pour simplifier la
configuration. Dans cette section je supposerai que la passerelle
de réseau privé gère la résolution de noms tant pour le réseau
privé que pour les requêtes extérieures.</p>
<p>À l'heure où j'écris, sous la version 8.2.2 du paquet BIND, il
n'est pas possible pour un démon <i>named</i> unique de produire
des réponses différenciées en fonction de l'interface sur laquelle
arrive la requête. On veut que la résolution de noms se comporte de
manière différente si la requête vient du monde extérieur parce que
les adresses IP du réseau privé ne doivent pas être envoyées à
l'extérieur &nbsp;; par contre, on doit être capable de répondre à
des requêtes émanant du réseau privé. Une réflexion existe sur de
nouveaux mot-clé «&nbsp;view&nbsp;» qui pourraient, à l'avenir,
être intégrés à BIND pour combler cette lacune, mais, avant que
cela ne soit effectif, la solution est de faire fonctionner deux
démons <i>named</i> avec des configurations différentes.</p>
<p>D'abord, configurez le serveur de noms du domaine privé comme
décrit dans la section <a href=
"#DNS_prive_FAI_gere_domaine">résolution DNS sur le réseau privé,
le FAI gère le domaine</a>, il constituera le
«&nbsp;resolver&nbsp;» visible depuis le réseau privé.</p>
<p>Ensuite, vous devez mettre en place le DNS de votre domaine de
façon à ce qu'il soit visible des hôtes du monde extérieur.
D'abord, vérifiez auprès de votre FAI s'il se déléguera lui-même
les recherches DNS inversé sur vos adresses IP. Bien que la norme
DNS d'origine ne donne pas la possibilité de contrôler le DNS
inversé sur des sous-réseaux plus petits qu'un réseau de classe C,
une méthode de contournement a été développée qui fonctionne avec
tous les clients compatibles DNS et a été ébauchée dans la RFC 2317
(à l'adresse <a href=
"http://www.ietf.org/rfc/rfc2317.txt">http://www.ietf.orf/rfc/rfc2317.txt</a>).
Si votre provider accepte de vous déléguer le DNS inversé sur votre
série d'adresses IP, vous devez obtenir de lui le nom du
pseudo-domaine in-addr qu'il a choisi pour la délégation (la RFC ne
propose pas de normalisation pour une utilisation ordinaire) et
vous devrez déclarer votre autorité sur ce pseudo-domaine. Je
supposerai que le FAI vous a délégué l'autorité et que le nom du
pseudo-domaine est 8.1.1.10.in-addr.arpa. L'ISP devra créer des
entrées sous la forme&nbsp;:</p>
<hr>
<pre>
8.1.1.10.in-addr.arpa.     2H IN CNAME 8.8.1.1.10.in-addr.arpa.
9.1.1.10.in-addr.arpa.     2H IN CNAME 9.8.1.1.10.in-addr.arpa.
10.1.1.10.in-addr.arpa.    2H IN CNAME 10.8.1.1.10.in-addr.arpa.
etc.
</pre>
<hr>
<p>dans son fichier de zone pour le domaine 1.1.10.in-addr.arpa. La
configuration de votre fichier de zone 8.1.1.10.in-addr.arpa est
donnée plus loin dans cette section.</p>
<p>Si votre provider accepte de vous déléguer le contrôle du DNS
inversé, il créera, pour les adresses IP sous votre contrôle, des
entrées CNAME dans la table des zones de son DNS inversé qui
pointent vers les enregistrements correspondants dans votre
pseudo-domaine comme montré ci-dessus. S'il n'envisage pas de vous
déléguer l'autorité, vous devrez lui demander de mettre à jour son
DNS à chaque fois que vous ajouterez, supprimerez ou changerez le
nom d'un hôte visible depuis l'extérieur dans votre domaine. Si la
table DNS inversé n'est pas synchronisée avec les entrées DNS
direct, certains services peuvent émettre des avertissements ou
bien refuser de traiter des requêtes produites par des machines
affectées par ce dysfonctionnement.</p>
<p>Vous devez maintenant mettre en place un second <i>named</i>,
celui là pour traiter les requêtes provenant de machines à
l'extérieur de la passerelle de réseau privé.</p>
<p>D'abord, créez un second fichier de configuration, par exemple
<code>/etc/named.ext.conf</code> pour les requêtes sur l'interface
externe. Dans notre exemple, il pourrait être comme suit&nbsp;:</p>
<hr>
<pre>
options {
        directory "/var/named";
        listen-on { 10.1.1.9; };
};
 
zone "." {
        type hint;
        file "root.hints";
};
 
zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};
 
 
zone "8.1.1.10.in-addr.arpa" {
        type master;
        file "ext/8.1.1.10";
};
 
zone "example.com" {
        type master;
        notify no;
        file "ext/example.com";
};
</pre>
<hr>
<p>Les fichiers <code>root.hint</code> et <code>pz/127.0.0</code>,
tous les deux sous <code>/var/named</code>, sont partagés par les
démons actifs. Le fichier <code>/ext/8.1.1.10</code> est comme
suit&nbsp;:</p>
<hr>
<pre>
$TTL 86400
 
@       IN      SOA             fred.example.com. root.fred.example.com. (
                                1               ; numéro de série
                                10800           ; mise à jour            3 heures
                                3600            ; tentative après échec  1 heure
                                3600000         ; délai d'expiration     1000 heures
                                86400 )         ; TTL minimale           24 heures
                NS      dns.example.com.
9       IN      PTR     fred.example.com.
                PTR     dns.example.com.
                PTR     mail.example.com.
10      IN      PTR     betty.example.com.
                PTR     www.example.com.
                PTR     ftp.example.com.
</pre>
<hr>
<p>Le fichier <code>ext/example.com</code> contient ce qui
suit&nbsp;:</p>
<hr>
<pre>
$TTL 86400
 
@               IN      SOA     example.com. root.fred.example.com. (
                                10021   ; numéro de série
                                8H      ; mise à jour             8 heures
                                2H      ; tentative après échec   2 heures
                                1W      ; délai d'expiration      1 semaine
                                1D      ; durée de vie minimale   1 jour
                        )
                        NS              fred.example.com.
        IN              A               10.1.1.9
        IN              MX          10  mail.example.com.
        IN              MX          20  &lt;machine mail du FAI&gt;.
 
 
localhost               A           127.0.0.1
fred                    A           10.1.1.9
betty                   A           10.1.1.10
dns                     CNAME       fred
mail                    CNAME       fred
www                     CNAME       betty
ftp                     CNAME       betty
</pre>
<hr>
<p>Démarrez les deux démons sur votre passerelle de réseau privé.
Mettez ce qui suit dans vos scripts d'initialisation&nbsp;:</p>
<pre>
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.conf
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.ext.conf
</pre>
<p>J'ai supposé ici que vous avez créé l'utilisateur sans privilège
«&nbsp;dnsuser&nbsp;» et le groupe sans privilège correspondant
«&nbsp;dnsgroup&nbsp;». Si un bogue se fait jour, permettant à un
attaquant d'exécuter du code à l'intérieur de <i>named</i>,
l'agresseur sera limité aux actions permises à un utilisateur sans
privilège. Le répertoire <code>/var/named</code> et les fichiers
qui y sont inclus ne doivent pas être modifiables par
«&nbsp;dnsuser&nbsp;».</p>
<p>Les machines du réseau privé doivent avoir leur résolution de
noms réglée pour s'en référer à dns.example.com (à l'IP 192.168.1.1
dans notre exemple) alors que les machines visibles depuis
l'extérieur peuvent envoyer leurs requêtes à l'interface externe de
la passerelle réseau (à l'IP 10.0.1.9) ou au serveur de noms du
FAI.</p>
<h3><a name="reseau_entierement_expose"></a> réseau pleinement
exposé, hébergé par le FAI</h3>
<p>Dans cette configuration, vous avez choisi d'exposer tous vos
hôtes. Vous avez une «&nbsp;véritable&nbsp;» adresse IP pour
chacune des machines de votre domaine et vous avez communiqué à
votre FAI la liste des noms de machines et de leurs adresses IP. Le
FAI vous a donné l'adresse d'un au moins de ses serveurs de noms.
Vos machines Linux sont alors configurées pour la résolution de
noms dans /etc/resolv.conf&nbsp;:</p>
<hr>
<pre>
search example.com
nameserver &lt;premier hôte DNS&gt;
nameserver &lt;deuxième hôte DNS&gt;
</pre>
<hr>
<p>Les machines Windows sont configurées de la même manière dans
les boites de dialogue de configuration du réseau.</p>
<h3>préparer le DNS avant de déplacer votre domaine</h3>
<p>Si vous décidez de déplacer votre domaine sur de nouvelles
adresses IP, soit parce que vous devez changer de FAI soit parce
que vous avez apporté des modifications à vos services et que ceci
vous impose de migrer vers de nouvelles adresses IP chez le même
FAI, vous devrez faire quelques préparatifs avant la migration.</p>
<p>Vous devez mettre les choses en place de façon à ce que, avant
la migration, l'adresse IP demandée par une recherche DNS quelque
part dans le monde pointe correctement sur l'adresse IP d'origine
et, qu'ensuite, après la migration, elle pointe rapidement sur la
nouvelle adresse IP. Des sites distants peuvent avoir mis en cache
votre adresse IP, et des requêtes postérieures peuvent obtenir une
réponse localement, depuis le cache, plutôt qu'en questionnant les
serveurs appropriés. L'effet de ceci peut être que des personnes
ayant visité votre site récemment sont dans l'impossibilité de se
connecter alors que de nouveaux visiteurs récupèrent des
informations valides non mises en cache. Le fait que les serveurs
racine ne soient mis à jour que deux fois par jour complique encore
plus les choses&nbsp;; ainsi il est difficile d'accélérer un
changement fait à l'identité de vos serveurs DNS primaire et
secondaire dans les serveurs racine.</p>
<p>La manière la plus simple de faire la transition est sûrement de
dupliquer son site en entier, ou au moins ses composantes visibles
publiquement, sur la nouvelle IP, déclarer la modification et
attendre que le trafic bascule complètement sur la nouvelle adresse
IP. Cependant, ce n'est probablement pas très faisable.</p>
<p>Ce que vous pouvez faire est de vous arranger avec votre nouveau
FAI (ou avec votre FAI actuel si vous changez juste d'adresses chez
le même FAI) afin qu'il héberge le DNS primaire et le DNS
secondaire pendant le transfert. Ceci devrait être fait au moins un
jour avant le déplacement. Demandez-lui de positionner la TTL
(durée de vie) de cet enregistrement sur quelque chose de
suffisamment petit (par exemple 5 minutes). Les exemples de fichier
DNS montrés plus haut dans cette section ont tous des valeurs TTL
positionnées sur 86400 secondes (1 jour). Si votre TTL est plus
longue que cela, vous devrez faire le changement plus longtemps à
l'avance. En définitive, voici ce que vous devez faire. Si la
configuration actuelle de la TTL de votre domaine est, disons, N
heures, alors ce qui suit doit être réalisé plus que N heures avant
le déplacement&nbsp;:</p>
<ul>
<li>L'enregistrement de votre domaine doit désigner les DNS
primaire et secondaire de votre nouvel ISP dans sa base de données
racine. Comptez au moins un jour entre le moment où vous soumettez
la modification et le moment où cette modification sera prise en
compte dans la base de données.</li>
<li>Les nouveaux DNS primaire et secondaire doivent pointer sur les
IP d'origine de votre site avec une TTL très petite.</li>
</ul>
<p>Remarquez que vous ne pouvez pas accélérer le processus en
réduisant la valeur actuelle de la TTL de votre domaine, à moins
que vous ne l'ayez déjà fait au moins N heures avant le
déplacement.</p>
<p>Maintenant, vous êtes prêt pour le transfert. Migrez vos
machines sur les nouvelles adresses IP. Synchronisez ceci avec une
mise à jour des enregistrements DNS de votre FAI de façon à ce
qu'ils pointent sur les nouvelles adresses. Dans un délai de 5
minutes (la petite TTL que vous avez enregistrée pour le
transfert), le trafic devrait avoir basculé sur le nouveau site.
Vous pouvez maintenant arranger la section autorisée du DNS à votre
goût, vous rendant primaire si c'est ce que vous voulez et
repositionant la TTL sur une valeur raisonnablement grande.</p>
<h2><a name="dns_sans_messagerie"></a> <a name="ss7.2">7.2
Configuration du DNS si vous n'hébergez pas de service de
messagerie</a></h2>
<p>Les configurations décrites dans la section <a href=
"#mise_en_place_DNS">Mettre en place la résolution de noms</a> ont
des enregistrements MX qui pointent sur une machine
«&nbsp;mail.example.com&nbsp;». L'enregistrement MX avec la valeur
de priorité la moins grande signale aux sites distants où envoyer
le courrier électronique. Les autres enregistrements de MX avec des
valeurs de priorité plus élevées sont utilisés comme des échangeurs
de mél de secours. Ces «&nbsp;secours&nbsp;» retiendront les
messages pendant une certaine durée si l'échangeur primaire n'est
pas en mesure, pour une raison quelconque, d'accepter les messages.
Dans les exemples de cette section, j'ai supposé que
fred.example.com sous son alias de mail.example.com, gère la
messagerie pour le domaine. Si vous avez choisi de laisser le FAI
héberger de votre messagerie, vous devrez modifier ces
enregistrements MX de façon à ce qu'ils pointent sur les machines
appropriées du FAI. Demandez à l'assistance technique de votre
fournisseur quels sont les noms des hôtes que vous devez utiliser
pour les enregistrements MX dans les divers fichiers.</p>
<h2><a name="mise_en_place_messagerie"></a> <a name="ss7.3">7.3
Mettre en place la messagerie électronique</a></h2>
<p>Si vous avez choisi d'héberger intégralement la messagerie pour
votre domaine, vous devrez prendre des mesures spéciales pour les
messages entrants sur les hôtes du réseau privé. À moins que vous
ne soyez vigilant, les messages ont de fortes chances de rester en
rade s'ils attendent sur une machine et que le destinataire
correspondant est connecté sur une autre machine. Pour des
questions de sécurité, je recommande que les messages entrants ne
soient pas accessibles depuis les hôtes publiquement visibles (ceci
pouvant aider à dissuader un PHB qui veut que sa station de travail
soit sur une adresse IP réelle et qui s'étonne de se faire planter
sa machine par un ping de la mort deux fois par jour). Sendmail
s'accomode très bien d'un système de distribution de courrier
transparent sur le réseau privé. Si quiconque souhaite fournir ici
des solutions <i>testées</i> pour d'autres démons de messagerie,
j'accueille volontiers toute contribution.</p>
<h3>Une solution utilisant Sendmail</h3>
<p>Afin que les messages délivrés sur un hôte soient accessibles
depuis toutes les machines, la solution la plus simple est
d'exporter le répertoire de spool de la messagerie avec des droits
de lecture/écriture sur l'ensemble du réseau privé. La passerelle
de réseau privé se comportera comme un échangeur de messagerie pour
celui-ci et doit donc avoir les droits de «&nbsp;root&nbsp;» en ce
qui concerne l'écriture sur le disque du répertoire de spool de la
messagerie. Les autres clients peuvent ou non rembarrer
«&nbsp;root&nbsp;», à votre gré. Ma philosophie générale en matière
de sécurité est de ne pas attribuer ces privilèges à moins qu'il
n'y ait une bonne raison de le faire, ainsi j'interdis
l'utilisateur «&nbsp;root&nbsp;» depuis toutes les machines sauf
depuis la passerelle de réseau privé. Ceci a pour effet que root ne
peut lire son courrier que depuis cette machine mais ce n'est pas
vraiment un handicap sérieux. Notez que le répertoire réseau de
spool peut être localisé sur la passerelle de réseau privé
elle-même, exporté par NFS, ou qu'il peut être localisé sur l'un
des serveurs internes, exporté sur l'ensemble du réseau privé. Si
le répertoire de spool réside sur la passerelle de réseau privé, il
n'y a pas intérêt à interdire «&nbsp;root&nbsp;» pour cette
machine. Si le répertoire de spool est sur un autre serveur, notez
que le courrier ne sera pas délivrable si ce serveur, la
passerelle, ou le réseau les reliant sont hors-service.</p>
<p>Pour les machines Windows de votre réseau privé, vous pouvez
soit mettre en place un serveur POP sur le serveur de mail ou bien
utiliser Samba pour exporter le répertoire de spool sur ces
machines. Les machines Windows doivent être configurées pour
envoyer et recevoir les messages sous un nom d'utilisateur Linux
tel que joeuser@example.com, ainsi l'adresse mél de l'hôte est le
nom de domaine uniquement, pas un nom de machine tel que
barney.example.com. Le serveur SMTP sortant doit être localisé sur
la passerelle de réseau privé qui sera chargée de la redirection
des messages et de toute réécriture d'adresse.</p>
<p>Ensuite vous devrez configurer Sendmail pour qu'il redirige les
messages en provenance des machines du réseau privé et qu'il
réécrive les adresses si nécessaire. Récupérez les sources les plus
récents depuis le site web de Sendmail à l'adresse <a href=
"http://www.sendmail.org">http://www.sendmail.org</a>. Compilez les
exécutables et ensuite allez dans le sous-répertoire
<code>cf/domain</code> dans l'arborescence source de Sendmail et
créez le nouveau fichier suivant&nbsp;:
<code>example.com.m4</code>.</p>
<hr>
<pre>
divert(-1)
#
# Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#       The Regents of the University of California.  All rights reserved.
#
# Par l'utilisation de ce fichier, vous acceptez les termes et conditions placés
# dorénavant dans le fichier LICENCE qui peut être trouvé à la racine
# de la distribution de sendmail
#
# 
 
#
# Ce qui suit est un fichier générique de domaine. Vous devriez pouvoir 
# l'utiliser n'importe où. Si vous voulez le personnaliser, copiez-le dans un fichier
# nommé comme votre domaine et faites les modifications; puis copiez les fichiers .mc
# appropriés et changez `DOMAIN(generic)' pour qu'ils renvoient à vos fichiers  
# de domaine modifiés.
#
divert(0)
define(`confFORWARD_PATH', `$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl
FEATURE(redirect)dnl
MASQUERADE_AS(example.com)dnl
FEATURE(masquerade_envelope)dnl
</pre>
<hr>
<p>Ceci définit le domaine example.com. Ensuite vous devez créer
les fichiers <code>sendmail.cf</code> qui seront utilisés sur le
serveur de messagerie (la passerelle de réseau privé), et sur les
autres noeuds du réseau privé.</p>
<p>Créez le fichier suivant dans l'arborescence de Sendmail, sous
<code>cf/cf</code>&nbsp;: <code>example.master.m4</code></p>
<hr>
<pre>
     divert(-1)
#
# Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#       The Regents of the University of California.  All rights reserved.
#
# Par l'utilisation de ce fichier, vous acceptez les termes et conditions placés
# dorénavant dans le fichier LICENCE qui peut être trouvé à la racine
# de la distribution de sendmail 
#
      
#
# Ceci est un fichier prototype pour une configuration qui ne supporte rien 
# à part des connexions SMTP de base sur TCP.
#
# Vous devez changer la macro `OSTYPE' pour spécifier le système d'exploitation
# sur lequel ça va marcher ; cela indiquera la localisation de fichiers de support
# divers pour l'environnement de votre système d'exploitation. Vous DEVEZ
# créer un fichier de domaine dans ../domain et le référencer en ajoutant une 
# macro `DOMAIN' après la macro `OSTYPE'. Je vous recommande de
# commencer  par copier ce fichier sous un autre nom de façon à ce que les mises 
# à jour de sendmail n'écrasent pas vos modifications.
#
 
divert(0)dnl
OSTYPE(linux)dnl
DOMAIN(example.com)dnl
FEATURE(nouucp)
FEATURE(relay_entire_domain)
FEATURE(`virtusertable', `hash /etc/sendmail/virtusertable')dnl
FEATURE(`genericstable', `hash /etc/sendmail/genericstable')dnl
define(`confPRIVACY_FLAGS', ``noexpn,novrfy'')dnl
MAILER(local)
MAILER(smtp)
Cw fred.example.com
Cw example.com
</pre>
<hr>
<p>Dans cet exemple, on a désactivé les commandes
«&nbsp;expn&nbsp;» et «&nbsp;vrfy&nbsp;». Un agresseur pourrait
tester en boucle avec «&nbsp;expn&nbsp;» des alias tels que
«&nbsp;personnel&nbsp;» ou «&nbsp;employes&nbsp;» jusqu'à ce qu'il
trouve un alias qui lui développe plusieurs noms d'utilisateurs. Il
peut alors essayer certains mots de passe médiocres dans le but
d'entrer (en supposant qu'il puisse obtenir une invite de login -
les réglages de sécurité dans la section <a href=
"#securiser_domaine">Sécuriser votre domaine</a> sont définis de
façon à ce qu'aucune invite de login ne soit possible pour les
attaquants de l'extérieur).</p>
<p>L'autre fichier que vous devez créer définira le sendmail.cf
pour les machines esclaves&nbsp;:
<code>example.slave.m4</code>.</p>
<hr>
<pre>
divert(-1)
# 
# Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#       The Regents of the University of California.  All rights reserved.
#
# Par l'utilisation de ce fichier, vous acceptez les termes et conditions placés
# dorénavant dans le fichier LICENCE qui peut être trouvé à la racine
# de la distribution de sendmail 
#
#
 
#
#  Ceci est un prototype pour un « null-client » -- c'est à dire un client qui
#  ne fait rien à part rediriger tout le courrier vers un échangeur de mail. 
#  IL N'EST PAS UTILISABLE EN L'ETAT !!!
#
#  Pour l'utiliser, vous devez utiliser la fonction nullclient avec le nom de 
#  de l'échangeur de mail comme argument. Vous DEVEZ également définir un 
#  `OSTYPE' pour définir la localisation des répertoires de file d'attente et apparentés.
#  En plus, vous POUVEZ sélectionner la fonction nocanonify. Cela entrainera
#  l'envoi d'adresses non qualifiées par la connection SMTP; normalement
#  elles sont qualifiées avec le nom de masquage, qui est par défaut le 
#  nom de la machine de connexion.
#  A part ça, il ne devrait pas contenir d'autre ligne.
#
 
divert(0)dnl
 
OSTYPE(linux)
FEATURE(nullclient, fred.$m)
Cm example.com
</pre>
<hr>
<p>Vous compilez les fichiers sendmail.cf qui vont bien avec la
commande&nbsp;:</p>
<pre>
     make example.master.cf example.slave.cf
</pre>
<p>et puis vous copiez les fichiers sur les machines appropriées
sous le nom de <code>sendmail.cf</code>.</p>
<p>Cette configuration installe la plupart des fichiers de
configuration de Sendmail dans le sous-répertoire
<code>/etc/sendmail</code> et amène <i>sendmail</i> à analyser et à
utiliser deux fichiers spécifiques, <code>virtusertable.db</code>
et <code>genericstable.db</code>. Pour utiliser ces fichiers
spécifiques, créez leurs fichiers source. D'abord,
<code>virtusertable.db</code>&nbsp;:</p>
<hr>
<pre>
     John.Public@example.com                 jpublic
     Jane.Doe@example.com                    jdoe@somemachine.somedomain
     abuse@example.com                       root
     Pointyhaired.Boss@example.com           #phb#@hotmail.com
</pre>
<hr>
<p>Ceci met en relation les adresses de messagerie du courrier
entrant avec de nouvelles destinations. Les messages envoyés à
John.Public@example.com sont délivrés localement sur le compte
Linux jpublic. Les messages pour Jane.Doe@example.com sont
redirigés vers un autre compte de messagerie, éventuellement, dans
un domaine différent. Le courrier pour abuse@example.com est envoyé
à root et ainsi de suite. L'autre fichier est
<code>genericstable.src</code>&nbsp;:</p>
<hr>
<pre>
     jpublic                                 John.Public@example.com
     janedoe                                 Jane.Doe@example.com
     whgiii                                  Pointyhaired.Boss@example.com
</pre>
<hr>
<p>Ce fichier change le nom de l'expéditeur des courriers sortants
provenant de la messagerie locale. Alors qu'il ne peut
manifestement pas avoir d'incidence sur l'adresse de retour des
messages envoyés directement par jdoe@somemachine.somedomain, il
vous permet de réécrire l'adresse des expéditeurs en changeant
leurs noms d'utilisateurs internes selon le «&nbsp;plan d'adressage
mél&nbsp;» que vous avez choisi. En dernier ressort, créez le
fichier <code>Makefile</code> suivant dans
<code>/etc/sendmail</code>&nbsp;:</p>
<hr>
<pre>
     all : genericstable.db virtusertable.db
 
     virtusertable.db : virtusertable.src
             makemap hash virtusertable &lt; virtusertable.src
 
     genericstable.db : genericstable.src
             makemap hash genericstable &lt; genericstable.src
</pre>
<hr>
<p>Exécutez <i>make</i> pour créer les fichiers compilés
interprétables par <i>sendmail</i>, et n'oubliez pas de ré-exécuter
<i>make</i> et de redémarrer <i>sendmail</i> (ou de lui envoyer un
SIGHUP) après toute modification de chacun de ces fichiers
«&nbsp;.src&nbsp;».</p>
<h3>Solutions utilisant d'autres MTA (Agents de transfert de
mail)</h3>
<p>Je n'ai d'expérience que sur Sendmail. Si quiconque souhaite
écrire cette section, contactez-moi svp. Sinon, il est possible que
j'essaye plus tard de donner moi-même des détails sur des MTA tels
que <i>Postfix</i>, <i>Exim</i> ou <i>smail</i>. Je préférerais
vraiment que quelqu'un d'autre, qui utilise ces programmes, écrive
cette section.</p>
<h2><a name="ss7.4">7.4 Mettre en place le serveur web</a></h2>
<p>Pour des raisons de sécurité, vous devriez mettre en place votre
serveur web public sur une machine à l'extérieur du réseau privé et
non sur la passerelle. Si le serveur web a besoin d'accéder à des
bases de données ou à d'autres ressouces entreposées sur le réseau
privé, la situation se complique tant du point de vue du réseau que
du point de vue de la sécurité. Une telle configuration est hors du
champ de ce document.</p>
<p>Les précisions sur l'installation du serveur en lui même peuvent
être trouvés dans la documentation d'apache et dans le WWW-HOWTO de
Linux à l'adresse <a href=
"ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO">ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO</a>
ou à l'adresse <a href=
"http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html">http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html</a>
en version française.</p>
<h2><a name="ss7.5">7.5 Mettre en place le serveur FTP</a></h2>
<p>Une fois encore, votre serveur FTP devrait être localisé sur une
des machines visibles depuis l'extérieur et non sur la passerelle
de réseau privé. Suivez les indications qui sont fournies avec
votre démon FTP. Assurez-vous d'avoir récupéré la version la plus
récente car il existe des failles de sécurité dans les vieilles
versions de beaucoup de serveurs. Si votre site FTP ne nécessite
pas que des utilisateurs anonymes y transfèrent des fichiers,
assurez-vous d'avoir désactivé cette fonction dans le démon. Je
recommande que la «&nbsp;connexion-utilisateur&nbsp;» (non anonyme)
ne soit pas autorisée sur le serveur, ceci impliquant que vos
utilisateurs utilisent scp, la commande de copie à distance du
shell sécurisé, pour toute mise à jour de fichier qu'ils seraient
amenés à faire sur le serveur FTP. Cela donne également aux
utilisateurs de bonnes habitudes de sécurité et protège du problème
de «&nbsp;routeur hostile&nbsp;» décrit dans la section <a href=
"#securiser_domaine">Sécuriser votre domaine</a>.</p>
<h2><a name="mettre_en_place_filtrage"></a> <a name="ss7.6">7.6
Mettre en place le filtrage de paquets</a></h2>
<p>Ce sujet est présenté en détail dans la section <a href=
"#config_pare-feu">Configurer votre Pare-feu</a>.</p>
<h2><a name="securiser_domaine"></a> <a name="s8">8. Sécuriser
votre domaine</a></h2>
<p>Cette section traite de la sécurisation de votre domaine.
L'accent est mis sur l'importance de la transparence de cette
dernière vis à vis des utilisateurs. Si votre sécurité est trop
contraignante et dérange trop les activités de vos utilisateurs,
ceux-ci développeront leurs propres procédures de contournement qui
peuvent nuire à l'ensemble du domaine. Le meilleur moyen d'éviter
ceci est de rendre la sécurité aussi peu contraignante que possible
et d'encourager les utilisateurs à vous contacter en premier lieu
quand ils ont des difficultés qui pourraient être imputables aux
mesures de sécurité du site. Une certaine tolérance est importante.
Je sais, d'expérience personnelle, que si le règlement de sécurité
est trop rigide, les utilisateurs mettront en place leurs propres
tunnels à travers le firewall de façon à pouvoir se loguer depuis
l'extérieur du domaine. Il est préférable que les procédures de
connexion à distance, ou n'importe quoi d'autre que tentent de
faire les utilisateurs soient installées, contrôlées et approuvées
par vous.</p>
<p>Cette section traite de la sécurisation de votre réseau contre
les agressions extérieures et contre un espionnage factuel depuis
l'intérieur. Sécuriser votre site contre une attaque déterminée de
la part d'utilisateurs légitimes à l'intérieur du réseau est une
tâche beaucoup plus difficile et compliquée et reste hors du champ
de ce document.</p>
<p>Un des points de sécurité sur lesquels se base cette section est
la protection contre le «&nbsp;routeur hostile&nbsp;». Le routeur
fourni par votre ISP peut constituer à lui seul un ordinateur
contrôlable à distance dont le mot de passe est détenu par votre
FAI. Il y a eu, dans le passé, des problèmes de sécurité quand les
mots de passe constructeur (ceux qui sont utilisés quand le FAI
oublie le mot de passe qu'il a attribué) ont été connus par des
«&nbsp;pirates&nbsp;». Si possible, vous devriez planifier votre
sécurité en prenant comme hypothèse que le routeur est
potentiellement hostile. C'est à dire qu'il pourrait utiliser
n'importe quelle adresse dans vos plages publique <i>ou privée</i>,
qu'il pourrait rediriger les paquets sortants vers un autre site ou
qu'il pourrait enregistrer tout ce qui lui passe au travers.</p>
<h2><a name="config_pare-feu"></a> <a name="ss8.1">8.1 Configurer
votre pare-feu (firewall)</a></h2>
<p>Cette section traite de la configuration d'un routeur de
filtrage, de masquage et de transport basé sur <i>ipchains</i>.
Vous devriez certainement lire d'abord le IPCHAINS-HOWTO (à
l'adresse <a href=
"ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO">ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO</a>&nbsp;;
<a href=
"http://www.freenix.org/unix/linux/HOWTO/IPCHAINS-HOWTO.html">http://www.freenix.org/unix/linux/HOWTO/IPCHAINS-HOWTO.html</a>
en version française) puis chercher ici des conseils additionnels.
Ce HOWTO décrit les étapes pour configurer un noyau avec support de
masquage (masquerading) et décrit en détail l'utilisation de
l'exécutable. Vous devriez activer le pare-feu sur toutes les
machines ayant une IP exposée.</p>
<p>Vérifiez vos scripts de démarrage afin de vous assurer que leur
enchaînement est comme suit sur la passerelle de réseau
privé&nbsp;:</p>
<ol>
<li>la carte Ethernet est initialisée</li>
<li>les règles de pare-feu sont passées en revue par ipchains</li>
<li>le transport est activé</li>
<li>les démons des services réseau sont démarrés</li>
</ol>
<p>Ainsi, à titre d'exemple, sur un système basé sur la Slackware,
la configuration du pare-feu devrait intervenir entre l'exécution
du <code>rc.inet1</code> et du <code>rc.inet2</code>. En outre, si
un quelconque problème apparaît au cours des étapes de démarrage du
pare-feu, un avertissement devrait être affiché et la carte réseau
externe désactivée avant que les services réseau ne soient
lancés.</p>
<p>Un problème courant avec les pare-feu basés sur ipchains est de
s'assurer que les règles sont correctement positionnées selon que
les paquets arrivent sur l'interface de loopback, ou depuis l'une
des deux interfaces, interne ou externe. Les paquets d'origine
locale peuvent être bloqués par le pare-feu. Trop souvent, ceci est
réglé par une espèce de débogage bricolé rapidement où les règles
du pare-feu sont manipulées jusqu'à ce que l'application semble
fonctionner à nouveau correctement sur le pare-feu.
Malheureusement, ceci peut parfois aboutir à un dispositif qui a
des trous de sécurité involontaires. Avec ipchains, il est possible
d'écrire un script de firewall qui peut être facilement débogué et
peut éviter beaucoup de problèmes. Voici un script d'exemple
<code>/sbin/firewall.sh</code>&nbsp;:</p>
<hr>
<pre>
#! /bin/sh
#
# Nouveau script de firewalling utilisant IP chains. Crée un routeur filtrant 
# avec masquage de réseau
#
 
# définition de quelques variables
 
IPCHAINS=/sbin/ipchains
 
LOCALNET="192.168.1.0/24"       # le réseau privé
ETHINSIDE="192.168.1.1"         # IP privée de fred.example.com #
ETHOUTSIDE="10.1.1.9"           # IP publique de fred.example.com #
LOOPBACK="127.0.0.1/8"
ANYWHERE="0/0"
OUTSIDEIF=eth1                  # interface privée de fred.example.com
 
FORWARD_PROCENTRY=/proc/sys/net/ipv4/ip_forward
 
#
# Ces deux commandes retourneront des codes d'erreur si les règles 
# existent déjà (ce qui se produit si vous exécutez le script 
# de pare-feu plus d'une fois). On met ces commandes avant « set -e »
# comme ça, dans ce cas le script n'est pas interrompu. 
 
$IPCHAINS -N outside
$IPCHAINS -N portmap
 
set -e                  # Abandonne immédiatement si des erreurs se produisent 
                        # lors de l'installation des règles.
 
#
# Arrête la redirection de ports et initialise les tables
 
echo "0" &gt; ${FORWARD_PROCENTRY}
 
$IPCHAINS -F forward
$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F outside
$IPCHAINS -F portmap
 
#
# Masque les paquets en provenance de notre réseau local 
# à destination du monde extérieur. Ne masque pas les 
# paquets locaux à destination locale.
 
$IPCHAINS -A forward -s $LOCALNET -d $LOCALNET -j ACCEPT
$IPCHAINS -A forward -s $ETHOUTSIDE -d $ANYWHERE -j ACCEPT
$IPCHAINS -A forward -s $LOCALNET -d $ANYWHERE -j MASQ
 
#
# Positionne les signaux de priorité. Délais minimum 
# de connexion pour www, telnet, ftp et ssh (paquets sortants 
# uniquement).
 
$IPCHAINS -A output -p tcp -d $ANYWHERE www -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE telnet -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ftp -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ssh -t 0x01 0x10
 
#
# n'importe quel paquet venant de notre classe C locale doit 
# être accepté comme le sont les paquets provenant de l'interface 
# de loopback  et l'interface externe de fred
 
$IPCHAINS -A input -s $LOCALNET -j ACCEPT
$IPCHAINS -A input -s $LOOPBACK -j ACCEPT
$IPCHAINS -A input -s $ETHOUTSIDE -j ACCEPT
 
#
# On va créer un jeu de règles pour les paquets provenant du grand, 
# méchant monde extérieur, et puis y attacher toutes les interfaces 
# externes. Ces règles seront appelées « outside ».
#
# On crée également une chaîne « portmap ». Les sockets utilisées 
# par les démons référencés par le portmapper RPC ne sont pas 
# fixes, il est donc un peu difficile de leur attribuer des 
# règles de filtrage. La chaîne portmap est configurée dans un 
# script à part.
 
#
# Paquets envoyés depuis n'importe quelle interface extérieure 
# à la chaîne « outside ». Ceci inclut l'interface $OUTSIDEIF 
# et toute interface ppp utilisée pour se connecter (ou fournir 
# une connexion).
 
$IPCHAINS -A input -i ${OUTSIDEIF} -j outside
$IPCHAINS -A input -i ppp+ -j outside
 
##################################################
#
#  installe les règles de la chaîne « outside »  #
#    
##################################################
 
#
# Personne de l'extérieur ne devrait pouvoir se faire 
# passer comme venant de l'intérieur ou du loopback.
 
$IPCHAINS -A outside -s $LOCALNET -j DENY
$IPCHAINS -A outside -s $LOOPBACK -j DENY
 
#
# Aucun des paquets routés vers notre réseau local 
# ne peut venir de l'extérieur car l'extérieur 
# n'est pas censé connaître nos adresses IP privées.
 
$IPCHAINS -A outside -d $LOCALNET -j DENY
 
#
# Bloque les connexions entrantes sur les ports X. Bloque 6000 à 6010.
 
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 6000:6010 -j DENY
 
#
# Bloque les ports NFS 111 et 2049.
 
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
 
#
# Bloque les paquets xdm venant de l'extérieur, port UDP 177.
 
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 177 -j DENY
 
#
# Bloque le port 653 YP/NIS .
 
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 653 -j DENY
 
#
# On ne va pas s'embêter avec des logins sur le port TCP 80, le port www.
 
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 80 -j DENY
 
#
# Accepte des connexions données et contrôle FTP.
 
$IPCHAINS -A outside -p TCP -s $ANYWHERE 20:21 -d $ANYWHERE 1024: -j ACCEPT
 
#
# Accepte les paquets ssh.
 
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE ssh -j ACCEPT
 
#
# Accepte les paquets DNS depuis l'extérieur.
 
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
 
#
# Accepte SMTP depuis partout.
 
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 25 -j ACCEPT
 
#
# Accepte les paquets NTP.
 
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 123 -j ACCEPT
 
#
# N'accepte pas les paquets d'indentification, on ne les utilise pas.
 
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 113 -j DENY
 
#
# Désactive et journalise tous les autres paquets entrants, 
# TCP ou UDP, sur les ports privilégiés.
 
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE :1023 -y -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE :1023 -j DENY
 
#
# Contrôle basé sur les règles de portmapper.
 
$IPCHAINS -A outside -j portmap
 
##############################################
#
#  Fin des règles de la chaîne « outside »   #
#
##############################################
 
#
# Bloque les paquets rwho sortants.
 
$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 513 -d $ANYWHERE -j DENY
 
#
# Empèche les paquets netbios de s'échapper.
 
$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 137 -d $ANYWHERE -j DENY
 
#
# Active le routage.
 
echo "1" &gt; ${FORWARD_PROCENTRY}
</pre>
<hr>
<p>Remarquez que le pare-feu peut être utilisé non seulement pour
les paquets entrants mais aussi pour les paquets sortants qui
pourraient dévoiler des informations sur votre réseau privé tels
que des paquets «&nbsp;rwho&nbsp;» ou «&nbsp;netbios&nbsp;».</p>
<p>Comme noté plus haut, les règles du portmapper sont légèrement
différentes car les démons portmap s'abonnent eux-mêmes au
portmapper et sont renseignés sur les ports à écouter. Les ports
utilisés par un démon quelconque peuvent changer si vous modifiez
les services RPC utilisés ou si vous changez leur ordre de
démarrage. Le script suivant,
<code>/sbin/firewall.portmap.sh</code>, génère les règles pour le
démon portmap.</p>
<hr>
<pre>
#! /bin/sh
#
ANYWHERE=0/0
 
IPCHAINS=/sbin/ipchains
 
$IPCHAINS -F portmap
 
# Règles pour empêcher l'accès aux services portmappés aux personnes de l'extérieur.
#
/usr/bin/rpcinfo -p | tail +2 | \
        { while read program vers proto port remainder
          do
             prot=`echo $proto | tr "a-z" "A-Z"`
             $IPCHAINS -l -A portmap -p $prot -s $ANYWHERE -d $ANYWHERE $port -j DENY || exit 1
          done
             }
</pre>
<hr>
<p>Nous n'avons pas à nous soucier du fait que les paquets entrants
sont des paquets «&nbsp;légitimes&nbsp;» en provenance du réseau
privé ou non, la chaîne portmap n'est vérifiée que quand les
paquets proviennent de l'extérieur.</p>
<p>Cette configuration de pare-feu note la plupart des paquets
suspects par l'intermédiaire de klogd avec la priorité kern.info.
Elle notera les essais de connexion normaux aussi bien que tous les
scans furtifs connus.</p>
<p>Maintenant on assemble le tout. On aimerait s'assurer qu'il
n'existe pas de petite fenêtre de vulnérabilité au démarrage du
système, en conséquence on configure la séquence de démarrage comme
suit&nbsp;:</p>
<hr>
<pre>
#! /bin/sh
#
# Démarrer le réseau de façon sécurisée
#
#
/etc/rc.d/rc.inet1              # configure les interfaces réseau
                                # et active le routage.
/sbin/firewall.sh || { echo "la configuration du pare-feu a échoué"
                       /sbin/ifconfig eth1 down }
 
/sbin/ipchains -I outside 1 -j DENY     # interdit tous les paquets entrants
 
/etc/rc.d/rc.inet2              # démarre les démons réseau
 
sleep 5                         # les laisse se stabiliser
 
# sécurise les service portmappés
/sbin/firewall.portmap.sh || { echo "la configuration du pare-feu de portmap a échoué"
                               /sbin/ifconfig eth1 down }
 
/sbin/ipchains -D outside 1       # autorise les paquets entrants
</pre>
<hr>
<p>Ceci suppose que eth1 est l'interface ayant l'adresse IP
visible. Si la moindre erreur a lieu lors de l'installation d'une
des règles d'ipchains, un avertissement est produit et cette
interface est désactivée. La chaine «&nbsp;outside&nbsp;» est
positionnée de manière à refuser tous les paquets avant que les
démons de service réseau ne soient démarrés, parce que les règles
de pare-feu ne sont pas encore en place pour les services
portmappés. Une fois que ces services sont protégés par le
pare-feu, la chaîne «&nbsp;outside&nbsp;» est rendue à son
comportement normal.</p>
<h2><a name="config_ssh"></a> <a name="ss8.2">8.2 Configurer
OpenSSH ou SSH1</a></h2>
<p>à l'heure où j'écris, Open SSH, aussi bien que SSH1, offre
désormais des possibilités de configuration permettant d'intégrer
<i>scp</i>, <i>ssh</i> et <i>slogin</i> comme des exécutables sous
les noms <i>rcp</i>, <i>rsh</i> et <i>rlogin</i> avec un retour
transparent, dans les programmes clients ssh, aux <i>rsh</i>,
<i>rcp</i> ou <i>rlogin</i> d'origine quand le site distant
n'exécute pas <i>sshd</i>. Faire en sorte que l'invocation de
<i>rsh</i> exécute à sa place le client <i>ssh</i> est, à mon avis,
important pour conserver une sécurité facile à utiliser et pour en
décharger les utilisateurs. Les scripts de tout le monde, les
configurations de <i>rdist</i>, etc. continueront à fonctionner
sans modification si le site distant exécute <i>sshd</i>, mais les
données seront envoyées chiffrées avec une forte certification de
l'hôte. La réciproque n'est pas toujours vraie. Tout spécialement
si la machine distante n'exécute pas sshd, le programme <i>rsh</i>
enverra un message à l'écran, avertissant que la connexion n'est
pas chiffrée. Ce message provoque une erreur avec <i>rdist</i> et
probablement avec d'autres programmes. Il ne peut être supprimé par
des options en ligne de commande ou de compilation. Pour
<i>rdist</i>, une solution est d'appeler le programme avec <code>-p
/usr/lib/rsh/rsh</code>.</p>
<p>Récupérez ssh1 depuis le site de ssh (à&nbsp;: <a href=
"http://www.ssh.org">http://www.ssh.org</a>), ou OpenSSH depuis son
site (à&nbsp;: <a href=
"http://www.openssh.org">http://www.openssh.org</a>), et
compilez-le pour remplacer les «&nbsp;programmes en r&nbsp;»
(<i>rsh</i>, <i>rlogin</i> et <i>rcp</i>) non chiffrés. D'abord,
copiez ces trois fichiers dans <code>/usr/lib/rsh</code>, puis
configurez le paquet ssh avec&nbsp;:</p>
<pre>
./configure --with-rsh=/usr/lib/rsh/rsh --program-transform-name='s/^s/r/' --prefix=/usr
</pre>
<p>Installez les exécutables et configurez-les en fonction des
directives. Sur la passerelle de réseau privé, assurez-vous que la
configuration de sshd comprend bien les entrées
suivantes&nbsp;:</p>
<pre>
ListenAddress 192.168.1.1       # l'adresse interne de fred
IgnoreRhosts no
X11Forwarding yes
X11DisplayOffset 10
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
</pre>
<p>Vous serez amené à effectuer des réglages supplémentaires dans
le fichier <code>/etc/sshd_config</code>, mais essayez de ne pas
changer ces champs. Une fois que vous avez réglé toutes les entrées
du fichier sur les valeurs qui vous conviennent, copiez le fichier
vers un nouveau fichier, <code>/etc/sshd_config.ext</code>, pour le
réseau externe. Changez deux entrées dans le nouveau fichier&nbsp;:
la valeur de «&nbsp;ListenAdress&nbsp;» doit être remplacée par
l'adresse IP de la passerelle de réseau privé (10.1.1.9 dans notre
exemple de fred.example.com) et
«&nbsp;PasswordAuthentication&nbsp;» doit être positionné sur
«&nbsp;no&nbsp;» dans <code>/etc/sshd_config.ext</code>. Dans vos
scripts de démarrage des services réseau, faites démarrer sshd deux
fois, une fois avec</p>
<pre>
/usr/sbin/sshd
</pre>
<p>et une fois avec</p>
<pre>
 /usr/sbin/sshd -f /etc/sshd_config.ext
</pre>
<p>Ceci lancera deux démons sshd. Celui opérant sur l'interface
interne autorisera les connexions avec mot de passe, mais
l'interface externe exigera la validation d'une clé RSA avant que
quiconque puisse se loguer.</p>
<p>Ensuite, désactivez les services telnet et shell dans le fichier
de configuration de inetd (notez que la configuration proposée dans
la section <a href="#config_pare-feu">Configurer votre pare-feu</a>
empêche déjà les accès depuis l'extérieur, mais il est préférable
de se défendre en profondeur, ne vous en remettez pas au fait que
tout fonctionne correctement).</p>
<p>Les personnes qui veulent pouvoir se connecter depuis leur
domicile ou depuis un lieu de déplacement auront besoin une clé
RSA. Assurez-vous qu'elles savent comment procéder de façon à ce
qu'elles ne gaspillent pas leur énergie à essayer de mettre en
place un autre moyen de se connecter comme, par exemple, exécuter
un telnetd sur un port sans privilège sur la machine pare-feu.</p>
<p>Une clé RSA est générée par la commande suivante&nbsp;:</p>
<pre>
ssh-keygen -b 1024 -f new_rsa_key
</pre>
<p>Vous serez invité à entrer une phrase-clé (passphrase). Celle-ci
ne doit <i>pas</i> être vide. Une personne ayant un accès au
fichier <code>new_rsa_key</code> et connaissant la phrase-clé a
tout ce qu'il lui faut pour réussir un défi d'authentification RSA.
La phrase-clé peut être un mot de passe «&nbsp;introuvable&nbsp;»
ou une phrase longue, mais choisissez quelque chose de pas banal.
Le fichier <code>new_rsa_key</code> peut être copié sur une
disquette ou sur un portable et, en association avec la phrase-clé,
peut être utilisé pour se connecter sous les comptes paramétrés
pour accorder l'accès à cette clé RSA précise.</p>
<p>Pour configurer un compte de façon à ce qu'il soit accessible
par une clé RSA, créez simplement un répertoire
<code>$HOME/.ssh</code> pour cet utilisateur sur la passerelle de
réseau privé (c'est à dire la machine qui recevra la demande de
connexion), et copiez le fichier <code>new_rsa_key.pub</code> qui a
été créé par la commande «&nbsp;ssh-keygen&nbsp;» dans le fichier
<code>$HOME/.ssh/authorized_keys</code>. Pour des détails sur les
autres options que vous pouvez ajouter à la clé, telles qu'obliger
la demande de connexion à provenir d'une certaine adresse IP ou
d'un certain nom d'hôte, ou bien permettre à la clé de n'autoriser
l'invocation à distance que de certaines commandes seulement (par
exemple une clé RSA qui ne fait que commander le début d'une
sauvegarde ou l'envoi par mail à l'extérieur du site d'un rapport
d'état), reportez-vous à la section «&nbsp;AUTHORIZED_KEYS FILE
FORMAT&nbsp;» dans la page de manuel de sshd.</p>
<p>Il reste une seule chose à faire pour rendre le mécanisme de
chiffrement RSA aussi simple que possible pour les utilisateurs. Si
l'utilisateur est obligé d'entrer la phrase-clé plus d'une fois ou
deux au cours de sa session, il va vraisemblablement finir par être
gêné et par prendre en main les questions de sécurité. Sous Linux,
faites en sorte que son shell de login soit invoqué sous
<i>ssh-agent</i>. Par exemple si les portables de société utilisés
en déplacement exécutent <i>xdm</i> et basculent les utilisateurs
sous une session X, allez dans le fichier
<code>/var/X11R6/lib/xdm/Xsession_0</code> et modifiez les lignes
qui lancent le démarrage et qui sont probablement du
type&nbsp;:</p>
<pre>
exec "$startup"
</pre>
<p>par des lignes du type&nbsp;:</p>
<pre>
exec ssh-agent "$startup"
</pre>
<p>Dans mon paramétrage de xdm il y a trois lignes dans ce fichier
qui ont dû être modifiées. Maintenant, quand l'utilisateur ouvre
une session sur le portable, il saisit la commande</p>
<pre>
ssh-add new_rsa_key
</pre>
<p>sous n'importe quel prompt, il saisit la phrase-clé quand il y
est invité et toutes les fenêtres auront accès sans phrase-clé au
compte sur la passerelle de réseau privé jusqu'à ce que
l'utilisateur déconnecte la session X sur le portable.</p>
<p>Exécutez sshd sur toutes les machines de votre réseau privé,
autant que sur vos hôtes exposés. Pour les autres machines que la
passerelle, l'entrée ListenAdress dans le fichier
<code>/etc/sshd_config</code> peut-être positionnée sur
«&nbsp;0.0.0.0&nbsp;». Vous devez mettre en place les clés des
hôtes avec la commande&nbsp;:</p>
<pre>
ssh-keygen -b 1024 -f /etc/ssh_host_key -N ""
</pre>
<p>puis exécuter <i>make-ssh-known-hosts</i> et distribuer le
fichier <code>/etc/ssh_know_hosts</code> sur toutes les machines du
réseau privé.</p>
<p>Désactivez le telnet entrant et les «&nbsp;services en r&nbsp;»
non chiffrés. Ne supprimez pas l'exécutable <i>telnet</i>, il est
utile pour d'autres choses que de simples connexions telnet sur le
port 23. Vous pouvez autoriser l'identification par mot de passe
sur le réseau privé et la désactiver sur les machines exposées, en
imposant une clé RSA pour la connexion sur les hôtes exposés.</p>
<p>Il est pratique pour les utilisateurs que les hôtes du réseau se
répertorient les uns les autres dans le fichier
<code>/etc/hosts.equiv</code>. Les démons sshd prendront ceci en
compte et permettront aux personnes de se connecter à distance ou
d'exécuter des shells à distance entre machines sans mot de passe
ou phrase-clé. À chacune des connexions, les machines vérifieront
leurs identités respectives avec des clés RSA au niveau
machine.</p>
<p>Une difficulté apparaît quand un utilisateur connecté sur une
machine du réseau privé veut se connecter sur une machine ayant une
adresse IP publique. Vous ne pouvez pas utiliser
<code>/etc/hosts.equiv</code> ou <code>$HOME/.shosts</code> pour
permettre une identification sans mot de passe parce que
l'utilisateur est sur une machine dont l'adresse IP ne peut être
déterminée - elle semblera venir du pare-feu, mais les clés-machine
ne fonctionneront pas. Il y a deux solutions à cela. D'abord, si
vous voulez vraiment utiliser les méthodes
<code>/etc/hosts.equiv</code> ou <code>$HOME/.shosts</code>,
l'utilisateur devra se connecter à la passerelle de réseau privé
(fred.example.com dans notre exemple actuel) et ensuite se
connecter sur la machine exposée depuis cet endroit. L'autre
technique consiste à utiliser l'authentification RSA qui fonctionne
toujours indépendamment des fantaisies du mécanisme de résolution
et d'adresses IP occasionnées par votre configuration.</p>
<h2><a name="ss8.3">8.3 Configurer X</a></h2>
<p>La quête perpétuelle de l'utilisateur pour prouver qu'il
privilégie la facilité d'utilisation par rapport à la sécurité, a
rendu commun l'usage de la commande</p>
<pre>
xhost +
</pre>
<p>dans ses scripts d'initialisation de X. Ceci permet l'accès au
serveur X à n'importe qui dans le monde. Maintenant, n'importe quel
intrus peut remplacer votre fond d'écran par quelque chose
d'embarassant juste au moment où votre chef fait visiter votre
bureau à sa mère. Cet intrus peut également tranquillement
surveiller tout ce que vous tapez au clavier et capturer le contenu
de votre écran sur sa machine. Inutile de dire que ceci ne sied pas
très bien aux mots de passe que vous utilisez pour vous connecter
sur d'autres sites ou à d'autres documents sensibles affichés à
l'écran. Le protocole xhost lui même a des limitations inhérentes
au fait qu'il n'est pas possible d'accorder la permission
d'utiliser l'affichage sur une «&nbsp;base utilisateur&nbsp;» mais
seulement sur une «&nbsp;base machine&nbsp;».</p>
<p>Optez pour l'identification <i>xauth</i>. Si vous avez
<i>xdm</i>, vous exécutez déjà probablement l'identification
<i>xauth</i> mais <i>xhost</i> fonctionne toujours et peut
continuer à être utilisé par les gens pour exécuter des processus X
entre machines. Une fois encore, le but est de rendre la sécurité
suffisamment facile à utiliser de manière à ce que les utilisateurs
ne soient plus tentés d'utiliser la commande <i>xhost</i>.</p>
<p>Le paramétrage de sshd décrit dans la section <a href=
"#config_ssh">Configurer SSH1</a>, avec l'indicateur
«&nbsp;X11Forwarding&nbsp;» positionné, est actuellement plus
simple d'utilisation que la technique <i>xhos</i>t. Une fois que
vous vous êtes connecté sur votre terminal, vous pouvez simplement
vous «&nbsp;rloguer&nbsp;» sur une machine distante et exécuter
<i>netscape</i>, <i>xv</i> ou ou ce que vous voulez sans avoir à
positionner la variable $DISPLAY ou à accorder des permissions
explicites. Au cours du login <i>ssh</i>, le système est configuré
d'une manière transparente pour l'utilisateur final, et même, tous
les paquets sont chiffrés avant de partir sur le réseau.</p>
<p>Si vous n'avez pas la possibilité d'utiliser le transfert X11
sshd pour une raison ou pour une autre, vous devrez utiliser
<i>xauth</i> quand vous voudrez autoriser les autres machines à se
connecter sur votre serveur X. Documentez ceci pour vos
utilisateurs ou bien créez des scripts shell spécialisés pour les
aider. La commande adéquate pour permettre une identification,
«&nbsp;jpublic&nbsp;» sur la machine «&nbsp;barney&nbsp;» de façon
à avoir accès au serveur est&nbsp;:</p>
<pre>
/usr/X11/bin/xauth extract - $DISPLAY | rsh -l jpublic barney /usr/X11/bin/xauth merge -
</pre>
<p>Cette séquence n'est pas nécessaire pour autoriser les
connexions X depuis les machines qui partagent un répertoire commun
de montage NFS. La clé xauth sera immédiatement disponible aux
utilisateurs de toutes les machines qui montent le même répertoire
racine.</p>
<p>Je serais tenté d'effacer purement et simplement <i>xhost</i> de
toutes les machines. Si ceci cause des problèmes pour quelques
programmes, vous saurez au moins que ces programmes avaient une
sécurité mal conçue. Il est suffisamment aisé d'écrire un
script-shell qui utilise la séquence <i>xauth</i> décrite plus haut
comme solution de remplacement pour <i>xhost</i>.</p>
<p>Notez que, si <i>rsh</i> n'est pas le programme de chiffrement
de ssh, la clé xauth est envoyée sous forme de texte. Quiconque
s'empare du texte de la clé peut accéder à votre serveur, ainsi
vous ne gagnez pas beaucoup de sécurisation si vous n'utilisez pas
ssh pour ces transactions. Notez également que si les répertoires
home des utilisateurs sont exportés via NFS (Network File System)
la clé xauth est disponible en clair pour n'importe quelle personne
en mesure d'espionner ces paquets NFS, indépendamment du fait que
vous exécutez ssh sur vos systèmes.</p>
<h2><a name="ss8.4">8.4 Configurer le partage de fichiers</a></h2>
<p>Avec la messagerie arrivant sur une machine centralisée, les
procédures de lecture et d'expédition depuis n'importe quel hôte
décrites ici sont très pratiques, mais des précautions doivent être
prises contre le furetage de la part d'utilisateurs locaux qui
s'ennuient. NFS sans implémentation de AUTH_DES manque foncièrement
de sécurité. NFS s'en remet à la machine cliente pour certifier
l'accès, il n'y a pas de vérification de mot de passe sur le
serveur pour s'assurer que le client est autorisé à accéder à tel
fichier privé d'un utilisateur particulier. Une machine Windows
peut être configurée pour lire les volumes exportés par NFS sous
n'importe quel identifiant numérique en outrepassant complètement
les permissions de fichiers UNIX. En conséquence, les exports NFS
ne devraient être mis en place que sur les machines qui sont
toujours sous Linux (ou UNIX), sous votre contrôle direct, et
jamais sur celles qui ont un boot multiple avec Windows. Si vous
voulez exporter le répertoire de spool de votre messagerie, ou
n'importe quel autre répertoire, vers des machines qui peuvent être
à l'occasion utilisées sous Windows, exportez-les avec Samba en
mettant le mode d'identification sur «&nbsp;security=USER&nbsp;».
Le fait de connecter les machines sur votre réseau à l'aide d'un
commutateur plutôt qu'un hub sera également bénéfique et donnera
peu d'intérêt à la mise en place de renifleurs sur les machines
Windows. Cependant, et en dernier lieu, il est très difficile de
sécuriser un partage de fichier à travers les réseaux au moment de
son écriture.</p>
<p>Pourquoi vous inquiéter si vous ne pouvez réellement sécuriser
les disques réseau&nbsp;? C'est avant tout un moyen de rendre
l'ensemble de la sécurisation crédible. Si vous laissez une feuille
de papier avec des informations confidentielles sur votre bureau et
que quelqu'un la lit, il pourra arguer du fait qu'il n'avait pas
réalisé la nature du document, sa curiosité naturelle venant juste
de l'emporter quand il l'a vu posée là. Si la feuille de papier est
dans un classeur ou dans un tiroir du bureau, c'est une histoire
totalement différente. L'objet des mesures de sécurité en interne
est surtout de s'assurer que personne ne peut accidentellement
compromettre la sécurité générale.</p>
<h2><a name="s9">9. Remerciements</a></h2>
<p>Ce document a été écrit comme documentation interne pour le
projet DYNACAN, intégré au au projet de développement continu sous
le contrôle du Développement des ressources humaines Canada.</p>
<p>Ce document a considérablement bénéficié des suggestions de</p>
<ul>
<li>Rod Smith (rodsmith@rodsbooks.com), qui a suggéré que je
fournisse des détails sur la manière d'enregistrer un nom de
domaine, sur la configuration avec des adresses IP dynamiques et
qui m'a orienté sur les divers services d'hébergement d'IP
dynamiques et sur Granite Canyon.</li>
<li>Greg Leblanc (gleblanc@my-deja.com) pour des suggestions utiles
pour améliorer la lisibilité du document.</li>
<li>Sami Yousif (syousif@iname.com).</li>
<li>Marc-André Dumas (m_a_dumas@hotmail.com), qui m'a suggéré la
section concernant la transposition du domaine sur de nouvelles
adresses IP.</li>
<li>Osamu Aoki (aoki@pacbell.net).</li>
<li>Joao Ribeiro &lt;(url
url="mailto:sena@decoy.ath.cx"name="sena@decoy.ath.cx"&gt;).</li>
</ul>
<h2><a name="s10">10. Glossaire des termes utilisés</a></h2>
<p>Voici une liste de la signification de certains des mots ou
acronymes utilisés dans le document.</p>
<dl>
<dt><b><a name="adresse_ip"></a> Adresse IP</b></dt>
<dd>
<p>L'adresse d'une certaine interface réseau. Sous le standard
actuel, nommé ipv4, cette adresse consiste en une série de 4
valeurs codées sur 8 bits généralement écrites en base 10 et
séparés par des points. La communication entre ordinateurs sur
internet est basée sur l'envoi de paquets d'information entre
adresses IP.</p>
</dd>
<dt><b>Adresse IP dynamique</b></dt>
<dd>
<p>Adresse IP qui est attribuée périodiquement ou sur la base d'une
session. Aucune garantie n'est donnée sur le fait que l'adresse IP
restera la même. Une adresse IP dynamique n'est susceptible de
changer que quand votre connexion réseau tombe et se reconnecte, ou
bien périodiquement lors d'une négociation DHCP. Certains services
basés sur la session tels que <i>telnet</i> ou <i>ssh</i>
s'arrêteront si l'adresse IP de l'une ou l'autre des deux machines
connectées change pendant la session.</p>
</dd>
<dt><b>Adresse IP statique</b></dt>
<dd>
<p>Une adresse IP qui vous a été attribuée ou louée de manière
permanente. Sauf annulation de la convention qui vous attribue
cette adresse IP, elle sera toujours disponible pour votre
utilisation, et aucune autre machine sur internet n'est autorisée à
utiliser cette adresse. S'oppose à Adresse IP dynamique.</p>
</dd>
<dt><b>DHCP</b></dt>
<dd>
<p>Dynamic Host Configuration Protocol. Un standard, défini dans la
RFC 1531, pour que des ordinateurs sur réseau TCP/IP puissent
obtenir de serveurs des informations telles que l'adresse IP qu'ils
doivent utiliser, le masque de réseau, la passerelle, etc. Plutôt
que ses informations soient paramétrées par un administrateur, la
machine les demande simplement au serveur quand elle se connecte au
réseau.</p>
</dd>
<dt><b>DNS</b></dt>
<dd>
<p>Domain name service. Un standard pour convertir les noms de
domaine en adresses IP ou vice-versa, en recherchant l'information
dans des bases de données centrales.</p>
</dd>
<dt><b>DSL</b></dt>
<dd>
<p>Digital Subscriber Line. Une connexion réseau relativement
rapide, habituellement fournie sur un câblage téléphonique
spécialisé.</p>
</dd>
<dt><b><a name="FAI"></a> FAI</b></dt>
<dd>
<p>Fournisseur d'accès à internet. La société qui vous fournit la
connexion à internet, y compris la connexion physique,
l'hébergement de services, et l'attribution d'adresses IP qu'elle
contrôle.</p>
</dd>
<dt><b>Fournisseur d'accès Internet</b></dt>
<dd>
<p>voir <a href="#FAI">FAI</a></p>
</dd>
<dt><b>FTP</b></dt>
<dd>
<p>File Transfert Protocol. Un protocole pour envoyer des fichiers
entre machines à travers internet.</p>
</dd>
<dt><b>ftpd</b></dt>
<dd>
<p>Le démon (serveur) chargé de fournir le service FTP sur un hôte.
Il répond aux requêtes faites par un client distant.</p>
</dd>
<dt><b>IP</b></dt>
<dd>
<p>voir <a href="#adresse_ip">adresse IP</a></p>
</dd>
<dt><b>ISP</b></dt>
<dd>
<p>Internet Service Provider, équivalent anglais pour <a href=
"#FAI">FAI</a></p>
</dd>
<dt><b><a name="masquage"></a> Masquage (ou camouflage)</b></dt>
<dd>
<p>Un type de filtrage dans lequel les paquets émanant d'une
machine vers le monde extérieur ont leur en-tête réécrit de façon à
ce qu'ils semblent provenir d'une machine intermédiaire. La machine
intermédiaire transmet alors les réponses à la machine d'origine.
Le résultat, en termes de réseau, est qu'un réseau entier de
machines peut sembler n'utiliser qu'une seule adresse IP, celle de
la machine qui assure le masquage, en ce qui concerne les
connexions extérieures.</p>
</dd>
<dt><b>Masquerading</b></dt>
<dd>
<p>voir <a href="#masquage">masquage</a></p>
</dd>
<dt><b>named</b></dt>
<dd>
<p>Le serveur de noms. C'est le démon qui répond aux requêtes DNS.
Il est distribué dans le paquet BIND.</p>
</dd>
<dt><b>Network Time Protocol</b></dt>
<dd>
<p>voir <a href="#NTP">NTP</a></p>
</dd>
<dt><b><a name="NTP"></a> NTP</b></dt>
<dd>
<p>Network Time Protocol. Un standard pour synchroniser votre
horloge système avec «&nbsp;l'heure officielle&nbsp;», défini comme
la référence de beaucoup d'horloges de précision à travers le
monde.</p>
</dd>
<dt><b>OS</b></dt>
<dd>
<p>Operating System. voir <a href="#SE">SE</a></p>
</dd>
<dt><b>PHB</b></dt>
<dd>
<p>Pointy Haired Boss (voir&nbsp;: <a href=
"http://www.unitedmedia.com/comics/dilbert/about/html/boss.html">http://www.unitedmedia.com/comics/dilbert/about/html/boss.html</a>
ou <a href=
"http://www.cplus.fr/html/samedicomedie/dilbert/personnages.html#3">
http://www.cplus.fr/html/samedicomedie/dilbert/personnages.html#3</a>).
Un personnage de Scott Adams, dans la série Dilbert.</p>
</dd>
<dt><b>Provider</b></dt>
<dd>
<p>voir <a href="#FAI">FAI</a></p>
</dd>
<dt><b>Requête DNS directe</b></dt>
<dd>
<p>(forward DNS) Une requête DNS qui convertit un nom de domaine en
une adresse IP.</p>
</dd>
<dt><b>Requête DNS inversé</b></dt>
<dd>
<p>(reverse DNS) Une requête DNS qui convertit une adresse IP en un
nom de domaine.</p>
</dd>
<dt><b>Routeur</b></dt>
<dd>
<p>Une machine spécialisée qui met à exécution les règles
concernant l'endroit où envoyer les paquets sur la base de leur
adresse IP, les ponts entre vos machines Ethernet et n'importe quel
média de communication qui vous connecte avec votre FAI.</p>
</dd>
<dt><b>Script CGI</b></dt>
<dd>
<p>Common Gateway Interface. C'est un programme qui est exécuté à
la demande pour générer le contenu d'une page web. Si une page web
doit faire autre chose que d'envoyer des informations (textes et
graphiques) fixes au navigateur, vous aurez probablement besoin
d'un programme quelconque de génération d'affichage dynamique tel
qu'un script CGI. Les applications peuvent être des forums de
dicussion, des formulaires interactifs, des cartes de crédit
e-commerce, etc.</p>
</dd>
<dt><b><a name="SE"></a> SE</b></dt>
<dd>
<p>Système d'exploitation. Linux, Windows, FreeBSD, BeOS, HP-UX,
MacOS, etc.</p>
</dd>
<dt><b>ssh</b></dt>
<dd>
<p>Le shell sécurisé. Une substitution chiffrée pour <i>rlogin</i>,
<i>telnet</i>, <i>ftp</i> et autres programmes. Protège contre
l'usurpation d'adresse, l'attaque de l'intercepteur, et le
reniflage de paquets.</p>
</dd>
</dl>
</body>
</html>