/usr/share/doc/HOWTO/fr-html/Domain.html is in doc-linux-fr-html 2013.01-2.
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 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 25 March 2009), see www.w3.org">
<meta name="GENERATOR" content="LinuxDoc-Tools 0.9.69">
<title>Installation de votre nouveau domaine Mini-HOWTO</title>
</head>
<body>
<h1>Installation de votre nouveau domaine Mini-HOWTO</h1>
<h2>Christopher Neufeld
<code><neufeld@linuxcare.com></code><br>
Traduction française par Geneviève Gracian
<code><ggracian@free.fr></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 à : <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 ; 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 « fortuites ». 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
« dial-up » 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
« simplets », 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
« hôtes exposés ». Ceci conduit
à la topologie suivante (exemple) :</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 : <a href=
"http://www.ietf.org/rfc/rfc1918.txt">http://www.ietf.org/rfc/rfc1918.txt</a> ;
<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 ; 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 ; 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 :</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 ; 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
« Linux-Masquerading ». 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 :</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
« pas », 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 ; informez donc votre
« responsable de la maintenance
immobilière » 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 « pas »
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
« pas » est réussi, cela peut
signifier que le routeur n'est pas correctement configuré
pour communiquer avec le FAI. Si plusieurs
« pas » 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
« example.dynip.com » ou bien
« example.dynhost.com », 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 : 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 « boite de
dépôt » 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 « boite de
dépôt », 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
« cyber-squatters ». 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
« Politique pour une résolution des conflits sur
les noms de domaines » à 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 : <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
« .com », « .net » et
« .org ». 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 « .fr »,
« .ca », « .de »,
« .uk », 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
« full-service » 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 :</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 ; 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 ; 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 « Network
solutions » (à 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 ; 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 :</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 :</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 :</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 ; 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 :</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 « voisinnage réseau »
à 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 : 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 :</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 « resolver » 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> ;
<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 :</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 :</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
« pointé » 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 :</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 <IP de la machine de mail de l'ISP>.
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 « options » de
<code>/etc/named.conf</code> appelle une explication :</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 : 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 ; 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é
« view » 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 « resolver » 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 :</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 :</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 :</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 :</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 <machine mail du FAI>.
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 :</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
« dnsuser » et le groupe sans
privilège correspondant « dnsgroup ».
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
« dnsuser ».</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
« véritable » 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 :</p>
<hr>
<pre>
search example.com
nameserver <premier hôte DNS>
nameserver <deuxième hôte DNS>
</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 ; 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 :</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
« mail.example.com ». 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
« secours » 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
« root » en ce qui concerne l'écriture
sur le disque du répertoire de spool de la messagerie. Les
autres clients peuvent ou non rembarrer
« root », à 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
« root » 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
« root » 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 :
<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> : <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
« expn » et « vrfy ».
Un agresseur pourrait tester en boucle avec
« expn » des alias tels que
« personnel » ou
« employes » 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 :
<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 :</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> :</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> :</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
« plan d'adressage mél » que vous avez
choisi. En dernier ressort, créez le fichier
<code>Makefile</code> suivant dans
<code>/etc/sendmail</code> :</p>
<hr>
<pre>
all : genericstable.db virtusertable.db
virtusertable.db : virtusertable.src
makemap hash virtusertable < virtusertable.src
genericstable.db : genericstable.src
makemap hash genericstable < 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
« .src ».</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 « connexion-utilisateur »
(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 « routeur
hostile » 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 « routeur
hostile ». 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
« pirates ». 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> ;
<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é :</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> :</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" > ${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" > ${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
« rwho » ou
« netbios ».</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
« légitimes » 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 :</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
« outside » 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 « outside » 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
(à : <a href=
"http://www.ssh.org">http://www.ssh.org</a>), ou OpenSSH depuis son
site (à : <a href=
"http://www.openssh.org">http://www.openssh.org</a>), et
compilez-le pour remplacer les « programmes en
r » (<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 :</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 :</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 : la
valeur de « ListenAdress » 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
« PasswordAuthentication » doit être
positionné sur « no » 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 :</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
« introuvable » 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
« ssh-keygen » 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 « AUTHORIZED_KEYS FILE
FORMAT » 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 :</p>
<pre>
exec "$startup"
</pre>
<p>par des lignes du type :</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 « 0.0.0.0 ». Vous devez mettre en place
les clés des hôtes avec la commande :</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 « services
en r » 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 « base utilisateur » mais
seulement sur une « base machine ».</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
« X11Forwarding » 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
« rloguer » 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,
« jpublic » sur la machine
« barney » de façon à avoir
accès au serveur est :</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
« security=USER ». 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 ?
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 <(url
url="mailto:sena@decoy.ath.cx"name="sena@decoy.ath.cx">).</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 « l'heure
officielle », 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 : <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>
|