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
|
<!doctype linuxdoc system>
<!-- LyX 1.1 created this file. For more info see http://www.lyx.org/ -->
<article>
<title>Installation de votre nouveau domaine Mini-HOWTO</title>
<author>
Christopher Neufeld <tt><neufeld@linuxcare.com></tt><newline>
Traduction française par Geneviève Gracian <tt><ggracian@free.fr></tt> le 7 février 2001
</author>
<date>version 0.12 du 17 octobre 2000</date>
<abstract>
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é.
</abstract>
<toc>
<sect> <heading>Notes</heading>
<sect1> <heading>Mise en garde</heading>
<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>
<sect1> <heading>Nouvelles versions de ce document</heading>
<p>La version la plus récente de ce document peut être trouvée à : <htmlurl url="http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/" name="http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/">.
</p>
<sect1> <heading>Copyright</heading>
<p>Copyright (c) Christopher Neufeld. Ce document peut être distribué selon les termes et conditions énoncés dans la licence LDP à l'adresse <htmlurl url="http://www.linuxdoc.org/COPYRIGHT.html" name="http://www.linuxdoc.org/COPYRIGHT.html">.
</p>
<sect> <heading>Introduction</heading>
<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 <ref id="IP_dynamique" name="Utiliser une IP dynamique" >.
</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 <bf>example.com</bf>. 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>
<sect> <heading>Définir la topologie de votre réseau</heading>
<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>
<p>
<verb>
+--------------+
| | +---------------+
| 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 |
+------------+ +------------------+
</verb>
</p><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 :<htmlurl
url="http://www.ietf.org/rfc/rfc1918.txt"
name="http://www.ietf.org/rfc/rfc1918.txt"> ; <htmlurl url="http://abcdrfc.free.fr/rfc-vf/rfc1918.html" name="http://abcdrfc.free.fr/rfc-vf/rfc1918.html"> 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>
<p>
<itemize>
<item>
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.
<item>
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.
<item>
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.
<item>
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.
<item>
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.
</itemize>
</p><p>
Les désavantages potentiels de ce type de configuration sont les suivants
:
</p>
<p>
<itemize>
<item>
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.
<item>
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é.
<item>
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.
</itemize>
</p><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>
<sect>
Vous procurer votre connexion
<sect1>
Choisir votre fournisseur d'accès
<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 <it>traceroute</it> 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 <it>traceroute</it> 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>
<sect1>
Faire les préparatifs pour l'installation matérielle
<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>
<sect1>
Tester la connexion
<p>
Une fois que votre machine de test est reliée au matériel du provider,
assurez-vous que vous pouvez faire un <it>ping</it> sur une machine au delà du FAI.
Si ce n'est pas possible, un <it>traceroute</it> 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>
<sect1>
Utiliser une IP dynamique<label id="IP_dynamique" >
<p>
Les avantages d'une connexion d'entreprise avec une plage d'adresses IP
statiques et l'hébergement de divers services entranent 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 <htmlurl url="http://www.technopagan.org/dynamic" name="http://www.technopagan.org/dynamic">). 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 <htmlurl url="http://www.dhs.org" name="http://www.dhs.org">). 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 <ref id="services_heberges" name="Décider des services que vous hébergerez" >. 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 <it>named</it> 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 <it>slogin</it> 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>
<sect>
Enregistrer un nom de domaine
<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 <htmlurl url="http://www.icann.org/udrp/udrp-policy-24oct99.htm" name="http://www.icann.org/udrp/udrp-policy24oct99.htm"> (en français : <htmlurl url="http://www.juriscom.net/pro/2/ndm20001011.htm" name="http://www.juriscom.net/pro/2/ndm20001011.htm">).
</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 <htmlurl
url="http://www.icann.org/registrars/accredited-list.html" name="http://www.icann.org/registrars/accredited-list.html">. 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 <htmlurl url="http://www.iana.org/cctld.html" name="http://www.iana.org/cctld.html">.
</p>
<sect>
Décider des services que vous hébergerez<label id="services_heberges" >
<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>
<p>
<itemize>
<item>
DNS primaire (le service DNS principal pour votre domaine). Voyez la section
<ref id="dns_primaire" name="DNS primaire" >
<item>
Messagerie électronique. Reportez-vous à la section <ref id="messagerie_electronique" name="Messagerie électronique" >
<item>
Hébergement de site web. Reportez-vous à la section <ref id="hebergement_web" name="Hébergement de site web" >
<item>
Hébergement de site FTP. Reportez-vous à la section <ref id="hebergement_ftp" name="Hébergement de site FTP" >
<item>
Filtrage de paquets. Reportez-vous à la section <ref id="filtrage_de_paquets" name="Filtrage de paquets" >
</itemize>
</p><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 matrise 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>
<sect1>
DNS primaire<label id="dns_primaire" >
<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 <htmlurl url="http://www.networksolutions.com" name="http://www.networksolutions.com">).
</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 <htmlurl url="http://www.granitecanyon.com" name="http://www.granitecanyon.com">), 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 <ref id="mise_en_place_DNS" name="Mettre en place la résolution de noms" > 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>
<sect1>
Messagerie électronique<label id="messagerie_electronique" >
<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>
<p>
<itemize>
<item>
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.
<item>
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.
<item>
Vous avez un nombre d'adresses limité, et vous pouvez être amené à payer
un supplément si vous dépassez cette limite.
<item>
Pour créer de nouvelles adresses, vous devez passer par le FAI.
</itemize>
</p><p>
Ce dont il faut se rappeler si vous gérez vous-même la messagerie :
</p>
<p>
<itemize>
<item>
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.
<item>
Vous avez un nombre illimité de comptes de messagerie, que vous pouvez
créer et supprimer vous-même.
<item>
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.
</itemize>
</p><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 <ref id="mise_en_place_messagerie" name="Mettre en place la messagerie électronique" >
</p>
<p>
Si vous décidez de ne pas héberger la messagerie pour votre domaine, reportez-vous
à la section <ref id="dns_sans_messagerie" name="Configuration du DNS si vous n'hébergez pas le service de messagerie" >.
</p>
<sect1>
Hébergement du site web<label id="hebergement_web" >
<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>
<p>
<itemize>
<item>
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.
<item>
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.
<item>
Il peut s'avérer difficile d'installer des CGI personnalisées ou des progiciels
commerciaux sur votre serveur web.
<item>
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.
</itemize>
</p><p>
Ce dont il faut se rappeler si choisissez d'héberger votre propre serveur
web.
</p>
<p>
<itemize>
<item>Vous avez plus de matrise sur le serveur. Vous pouvez façonner votre sécurité de manière plus adaptée à votre utilisation.</item>
<item>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.</item>
<item>Votre stratégie de sauvegarde est probablement moins complète que celle de votre FAI.</item>
</itemize>
</p>
<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 <htmlurl url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO" name="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO"> ou <htmlurl url="http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html" name="http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html"> 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>
<sect1>
<heading>Hébergement du site FTP<label id="hebergement_ftp" ></heading>
<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 <it>wu-ftpd</it>, je recommande les options de configuration suivantes :</p>
<p>
<itemize>
<item>--disable-upload (à moins que n'ayez besoin du téléchargement anonyme)</item>
<item>--enable-anononly (incite vos utilisateurs locaux à utiliser scp pour le transfert de fichier entre les machines)</item>
<item>--enable-paranoid (désactive toute fonctionnalité de la version courante qui peut être sujette à caution)</item>
</itemize>
</p>
<sect1>
<heading>Filtrage de paquets<label id="filtrage_de_paquets" ></heading>
<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 <ref id="mettre_en_place_filtrage" name="Mettre en place le filtrage de paquets" >.
</p>
<sect>
<heading>Configurer les services hébergés</heading>
<sect1>
Mettre en place la résolution de noms<label id="mise_en_place_DNS" >
<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>
<sect2>
résolution DNS sur le réseau privé, le FAI gère le domaine<label id="DNS_prive_FAI_gere_domaine" >
<p>
(remarque : si vous avez choisi de ne pas mettre en place un réseau privé,
allez à la section <ref id="reseau_entierement_expose" name="Réseau entièrement exposé, hébergé par le FAI" >)
</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 <htmlurl url="http://www.isc.org/products/BIND/" name="http://www.isc.org/products/BIND/">). Ensuite vous devez configurer
les démons. Créez le fichier <tt>/etc/named.conf</tt> suivant :
</p>
<p>
<code>
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";
};
</code>
</p><p>
Remarquez que nous nous sommes déclarés matres 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 <it>pas</it> 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 <it>doivent</it> utiliser le serveur de noms du
FAI, pas le serveur de nom privé sur dns.example.com.
</p>
<p>
Les différents fichiers sous <tt>/var/named</tt> doivent maintenant être créés.
</p>
<p>
Le fichier <tt>root.hint</tt> est tel que décrit dans la documentation de BIND ou
dans le DNS-HOWTO (à l'adresse <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/DNS-HOWTO"
name="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/DNS-HOWTO"> ; <htmlurl
url="http://www.freenix.org/unix/linux/HOWTO/DNS-HOWTO.html"
name="http://www.freenix.org/unix/linux/HOWTO/DNS-HOWTO.html">). À l'heure où j'écris, Ce qui suit est un fichier root.hint
valide.
</p>
<p>
<code>
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
</code>
</p><p>
Le fichier <tt>pz/127.0.0.0</tt> est comme suit :
</p>
<p>
<code>
@ 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.
</code>
</p><p>
Le fichier <tt>pz/1.168.192</tt> est comme suit :
</p>
<p>
<code>
$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.
</code>
</p><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 <tt>pz/example.com</tt> est comme suit :
</p>
<p>
<code>
$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
</code>
</p><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 <tt>/etc/named.conf</tt> appelle une explication
:
</p>
<p>
<verb>
listen-on { 192.168.1.1 };
</verb>
</p><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>
<sect2>
pas de résolution DNS sur le réseau privé, le FAI gère le domaine
<p>
(note : si vous avez décidé de ne pas mettre en oeuvre de réseau privé,
reportez-vous à la section <ref id="reseau_entierement_expose" name="Réseau pleinement exposé, hébergé par le FAI" >)
</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 <tt>/etc/hosts</tt> 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 <ref id="DNS_prive_FAI_gere_domaine" name="le DNS est sur le réseau privé, le FAI gère le domaine" >, 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>
<sect2>
vous êtes l'autorité DNS primaire pour le domaine
<p>
Bien que vous puissiez mettre en oeuvre la résolution <it>named</it> 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 <it>named</it> 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 <it>named</it> avec
des configurations différentes.
</p>
<p>
D'abord, configurez le serveur de noms du domaine privé comme décrit dans
la section <ref id="DNS_prive_FAI_gere_domaine" name="résolution DNS sur le réseau privé, le FAI gère le domaine" >, 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 <htmlurl url="http://www.ietf.org/rfc/rfc2317.txt" name="http://www.ietf.orf/rfc/rfc2317.txt">). 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>
<p>
<code>
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.
</code>
</p><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 <it>named</it>, 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 <tt>/etc/named.ext.conf</tt>
pour les requêtes sur l'interface externe. Dans notre exemple, il pourrait
être comme suit :
</p>
<p>
<code>
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";
};
</code>
</p><p>
Les fichiers <tt>root.hint</tt> et <tt>pz/127.0.0</tt>, tous les deux sous<tt> /var/named</tt>, sont
partagés par les démons actifs. Le fichier <tt>/ext/8.1.1.10</tt> est comme suit :
</p>
<p>
<code>
$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.
</code>
</p><p>
Le fichier <tt>ext/example.com</tt> contient ce qui suit :
</p>
<p>
<code>
$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
</code>
</p><p>
Démarrez les deux démons sur votre passerelle de réseau privé. Mettez ce
qui suit dans vos scripts d'initialisation :
</p>
<p>
<verb>
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.conf
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.ext.conf
</verb>
</p><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 <it>named</it>, l'agresseur
sera limité aux actions permises à un utilisateur sans privilège. Le répertoire
<tt>/var/named</tt> 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>
<sect2>
réseau pleinement exposé, hébergé par le FAI<label id="reseau_entierement_expose" >
<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>
<p>
<code>
search example.com
nameserver <premier hôte DNS>
nameserver <deuxième hôte DNS>
</code>
</p><p>
Les machines Windows sont configurées de la même manière dans les boites
de dialogue de configuration du réseau.
</p>
<sect2>
préparer le DNS avant de déplacer votre domaine
<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>
<p>
<itemize>
<item>
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.
<item>
Les nouveaux DNS primaire et secondaire doivent pointer sur les IP d'origine
de votre site avec une TTL très petite.
</itemize>
</p><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>
<sect1>
Configuration du DNS si vous n'hébergez pas de service de messagerie<label id="dns_sans_messagerie" >
<p>
Les configurations décrites dans la section <ref id="mise_en_place_DNS" name="Mettre en place la résolution de noms" > 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>
<sect1>
Mettre en place la messagerie électronique<label id="mise_en_place_messagerie" >
<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
<it>testées</it> pour d'autres démons de messagerie, j'accueille volontiers toute contribution.
</p>
<sect2>
Une solution utilisant Sendmail
<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 <htmlurl url="http://www.sendmail.org" name="http://www.sendmail.org">. Compilez les exécutables et ensuite allez dans le sous-répertoire
<tt>cf/domain</tt> dans l'arborescence source de Sendmail et créez le nouveau fichier
suivant : <tt>example.com.m4</tt>.
</p>
<p>
<code>
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
</code>
</p><p>
Ceci définit le domaine example.com. Ensuite vous devez créer les fichiers
<tt>sendmail.cf</tt> 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 <tt>cf/cf</tt> :
<tt>example.master.m4</tt>
</p>
<p>
<code>
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
</code>
</p><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 <ref id="securiser_domaine" name="Sécuriser votre domaine" > 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 : <tt>example.slave.m4</tt>.
</p>
<p>
<code>
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
</code>
</p><p>
Vous compilez les fichiers sendmail.cf qui vont bien avec la commande :
</p>
<p>
<verb>
make example.master.cf example.slave.cf
</verb>
</p><p>
et puis vous copiez les fichiers sur les machines appropriées sous le nom
de <tt>sendmail.cf</tt>.
</p>
<p>
Cette configuration installe la plupart des fichiers de configuration de
Sendmail dans le sous-répertoire <tt>/etc/sendmail</tt> et amène <it>sendmail</it> à analyser
et à utiliser deux fichiers spécifiques, <tt>virtusertable.db</tt> et <tt>genericstable.db</tt>.
Pour utiliser ces fichiers spécifiques, créez leurs fichiers source. D'abord,
<tt>virtusertable.db</tt> :
</p>
<p>
<code>
John.Public@example.com jpublic
Jane.Doe@example.com jdoe@somemachine.somedomain
abuse@example.com root
Pointyhaired.Boss@example.com #phb#@hotmail.com
</code>
</p><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 <tt>genericstable.src</tt> :
</p>
<p>
<code>
jpublic John.Public@example.com
janedoe Jane.Doe@example.com
whgiii Pointyhaired.Boss@example.com
</code>
</p><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 <tt>Makefile</tt> suivant dans <tt>/etc/sendmail</tt> :
</p>
<p>
<code>
all : genericstable.db virtusertable.db
virtusertable.db : virtusertable.src
makemap hash virtusertable < virtusertable.src
genericstable.db : genericstable.src
makemap hash genericstable < genericstable.src
</code>
</p><p>
Exécutez <it>make</it> pour créer les fichiers compilés interprétables par <it>sendmail</it>,
et n'oubliez pas de ré-exécuter <it>make</it> et de redémarrer <it>sendmail</it> (ou de lui envoyer
un SIGHUP) après toute modification de chacun de ces fichiers « .src ».
</p>
<sect2>
Solutions utilisant d'autres MTA (Agents de transfert de mail)
<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 <it>Postfix</it>, <it>Exim</it> ou <it>smail</it>. Je
préférerais vraiment que quelqu'un d'autre, qui utilise ces programmes, écrive
cette section.
</p>
<sect1>
Mettre en place le serveur web
<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 <htmlurl url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO" name="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO"> ou
à l'adresse <htmlurl url="http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html" name="http://www.freenix.org/unix/linux/HOWTO/WWW-HOWTO.html"> en version française.
</p>
<sect1>
Mettre en place le serveur FTP
<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 <ref id="securiser_domaine" name="Sécuriser votre domaine" >.
</p>
<sect1>
Mettre en place le filtrage de paquets<label id="mettre_en_place_filtrage" >
<p>
Ce sujet est présenté en détail dans la section <ref id="config_pare-feu" name="Configurer votre Pare-feu" >.
</p>
<sect>
Sécuriser votre domaine<label id="securiser_domaine" >
<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 <it>ou privée</it>, qu'il pourrait rediriger
les paquets sortants vers un autre site ou qu'il pourrait enregistrer tout
ce qui lui passe au travers.
</p>
<sect1>
Configurer votre pare-feu (firewall)<label id="config_pare-feu" >
<p>
Cette section traite de la configuration d'un routeur de filtrage, de masquage
et de transport basé sur <it>ipchains</it>. Vous devriez certainement lire d'abord le
IPCHAINS-HOWTO (à l'adresse <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO"
name="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO"> ; <htmlurl url="http://www.freenix.org/unix/linux/HOWTO/IPCHAINS-HOWTO.html" name="http://www.freenix.org/unix/linux/HOWTO/IPCHAINS-HOWTO.html"> 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 enchanement
est comme suit sur la passerelle de réseau privé :
</p>
<p>
<enum>
<item>
la carte Ethernet est initialisée
<item>
les règles de pare-feu sont passées en revue par ipchains
<item>
le transport est activé
<item>
les démons des services réseau sont démarrés
</enum>
</p><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 <tt>rc.inet1</tt> et du <tt>rc.inet2</tt>.
En outre, si un quelconque problème apparat 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
<tt>/sbin/firewall.sh</tt> :
</p>
<p>
<code>
#! /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 chane « 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 chane portmap est configurée dans un
# script à part.
#
# Paquets envoyés depuis n'importe quelle interface extérieure
# à la chane « 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 chane « 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é connatre 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 chane « 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}
</code>
</p>
<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, <tt>/sbin/firewall.portmap.sh</tt>, génère les règles pour le démon portmap.
</p>
<p>
<code>
#! /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
}
</code>
</p>
<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 chane 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>
<p>
<code>
#! /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
</code>
</p>
<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 chane « outside » est rendue à son comportement normal.
</p>
<sect1> <heading>Configurer OpenSSH ou SSH1<label id="config_ssh" ></heading>
<p>à l'heure où j'écris, Open SSH, aussi bien que SSH1, offre désormais des possibilités de configuration permettant d'intégrer <it>scp</it>, <it>ssh</it> et <it>slogin</it> comme des exécutables sous les noms <it>rcp</it>, <it>rsh</it> et <it>rlogin</it> avec un retour transparent, dans les programmes clients ssh, aux <it>rsh</it>, <it>rcp</it> ou <it>rlogin</it> d'origine quand le site distant n'exécute pas <it>sshd</it>. Faire en sorte que l'invocation de <it>rsh</it> exécute à sa place le client <it>ssh</it> 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 <it>rdist</it>, etc. continueront à fonctionner sans modification si le site distant exécute <it>sshd</it>, 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 <it>rsh</it> enverra un message à l'écran, avertissant que la connexion n'est pas chiffrée. Ce message provoque une erreur avec <it>rdist</it> et probablement avec d'autres programmes. Il ne peut être supprimé par des options en ligne de commande ou de compilation. Pour <it>rdist</it>, une solution est d'appeler le programme avec <tt>-p /usr/lib/rsh/rsh</tt>.
</p>
<p>Récupérez ssh1 depuis le site de ssh (à :<htmlurl url="http://www.ssh.org" name="http://www.ssh.org">), ou OpenSSH depuis son site (à :<htmlurl url="http://www.openssh.org" name="http://www.openssh.org">), et compilez-le pour remplacer les « programmes en r » (<it>rsh</it>, <it>rlogin</it> et <it>rcp</it>) non chiffrés. D'abord, copiez ces trois fichiers dans <tt>/usr/lib/rsh</tt>, puis configurez le paquet ssh avec :
</p>
<p>
<verb>
./configure --with-rsh=/usr/lib/rsh/rsh --program-transform-name='s/^s/r/' --prefix=/usr
</verb>
</p>
<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>
<p>
<verb>
ListenAddress 192.168.1.1 # l'adresse interne de fred
IgnoreRhosts no
X11Forwarding yes
X11DisplayOffset 10
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
</verb>
</p><p>
Vous serez amené à effectuer des réglages supplémentaires dans le fichier
<tt>/etc/sshd_config</tt>, 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,<tt> /etc/sshd_config.ext</tt>, 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 <tt>/etc/sshd_config.ext</tt>. Dans vos scripts de démarrage
des services réseau, faites démarrer sshd deux fois, une fois avec
</p>
<p>
<verb>
/usr/sbin/sshd
</verb>
</p><p>
et une fois avec
</p>
<p>
<verb>
/usr/sbin/sshd -f /etc/sshd_config.ext
</verb>
</p><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 <ref id="config_pare-feu" name="Configurer votre pare-feu" > 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>
<p>
<verb>
ssh-keygen -b 1024 -f new_rsa_key
</verb>
</p><p>
Vous serez invité à entrer une phrase-clé (passphrase). Celle-ci ne doit
<it>pas</it> être vide. Une personne ayant un accès au fichier <tt>new_rsa_key</tt> 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 <tt>new_rsa_key</tt> 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 <tt>$HOME/.ssh</tt> 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 <tt>new_rsa_key.pub</tt> qui a été créé par la commande
« ssh-keygen » dans le fichier <tt>$HOME/.ssh/authorized_keys</tt>. 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 <it>ssh-agent</it>. Par exemple si les portables de société utilisés en déplacement
exécutent <it>xdm</it> et basculent les utilisateurs sous une session X, allez dans
le fichier <tt>/var/X11R6/lib/xdm/Xsession_0</tt> et modifiez les lignes qui lancent
le démarrage et qui sont probablement du type :
</p>
<p>
<verb>
exec "$startup"
</verb>
</p><p>
par des lignes du type :
</p>
<p>
<verb>
exec ssh-agent "$startup"
</verb>
</p><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>
<p>
<verb>
ssh-add new_rsa_key
</verb>
</p><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 <tt>/etc/sshd_config</tt> peut-être positionnée sur « 0.0.0.0 ».
Vous devez mettre en place les clés des hôtes avec la commande :
</p>
<p>
<verb>
ssh-keygen -b 1024 -f /etc/ssh_host_key -N ""
</verb>
</p><p>
puis exécuter <it>make-ssh-known-hosts</it> et distribuer le fichier <tt>/etc/ssh_know_hosts</tt>
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 <it>telnet</it>, 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 <tt>/etc/hosts.equiv</tt>. 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é apparat 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 <tt>/etc/hosts.equiv</tt> ou <tt>$HOME/.shosts</tt> 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 <tt>/etc/hosts.equiv</tt> ou
<tt>$HOME/.shosts</tt>, 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>
<sect1>
Configurer X
<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>
<p>
<verb>
xhost +
</verb>
</p><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 <it>xauth</it>. Si vous avez <it>xdm</it>, vous exécutez déjà
probablement l'identification <it>xauth</it> mais <it>xhost</it> 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
<it>xhost</it>.
</p>
<p>
Le paramétrage de sshd décrit dans la section <ref id="config_ssh" name="Configurer SSH1" >, avec l'indicateur « X11Forwarding »
positionné, est actuellement plus simple d'utilisation que la technique <it>xhos</it>t.
Une fois que vous vous êtes connecté sur votre terminal, vous pouvez simplement
vous « rloguer » sur une machine distante et exécuter <it>netscape</it>, <it>xv</it> ou ou ce que
vous voulez sans avoir à positionner la variable $DISPLAY ou à accorder
des permissions explicites. Au cours du login <it>ssh</it>, 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 <it>xauth</it> 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>
<p>
<verb>
/usr/X11/bin/xauth extract - $DISPLAY | rsh -l jpublic barney /usr/X11/bin/xauth merge -
</verb>
</p>
<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 <it>xhost</it> 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 <it>xauth</it> décrite plus haut comme solution de remplacement pour <it>xhost</it>.
</p>
<p>Notez que, si <it>rsh</it> 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>
<sect1> <heading>Configurer le partage de fichiers</heading>
<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>
<sect> <heading>Remerciements</heading>
<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>
<p>
<itemize>
<item>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.
<item>Greg Leblanc (gleblanc@my-deja.com) pour des suggestions utiles pour améliorer la lisibilité du document.
<item>Sami Yousif (syousif@iname.com).
<item>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.
<item>Osamu Aoki (aoki@pacbell.net).
<item>Joao Ribeiro <(url url="mailto:sena@decoy.ath.cx"name="sena@decoy.ath.cx">).
</itemize>
</p>
<sect> <heading>Glossaire des termes utilisés</heading>
<p>Voici une liste de la signification de certains des mots ou acronymes utilisés dans le document.
</p>
<p>
<descrip>
<tag><label id="adresse_ip" >Adresse IP</tag>
<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>
<tag>Adresse IP dynamique</tag>
<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 <it>telnet</it> ou <it>ssh</it> s'arrêteront si l'adresse IP de l'une ou l'autre des deux machines connectées change pendant la session.</p>
<tag>Adresse IP statique</tag>
<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>
<tag>DHCP</tag>
<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>
<tag>DNS</tag>
<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>
<tag>DSL</tag>
<p>Digital Subscriber Line. Une connexion réseau relativement rapide, habituellement fournie sur un câblage téléphonique spécialisé.</p>
<tag><label id="FAI" >FAI</tag>
<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>
<tag>Fournisseur d'accès Internet</tag>
<p>voir <ref id="FAI" name="FAI"></p>
<tag>FTP</tag>
<p>File Transfert Protocol. Un protocole pour envoyer des fichiers entre machines à travers internet.</p>
<tag>ftpd</tag>
<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>
<tag>IP</tag>
<p>voir <ref id="adresse_ip" name="adresse IP" ></p>
<tag>ISP</tag>
<p>Internet Service Provider, équivalent anglais pour <ref id="FAI" name="FAI" ></p>
<tag><label id="masquage" >Masquage (ou camouflage)</tag>
<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>
<tag>Masquerading</tag>
<p>voir <ref id="masquage" name="masquage" ></p>
<tag>named</tag>
<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>
<tag>Network Time Protocol</tag>
<p>voir <ref id="NTP" name="NTP" ></p>
<tag><label id="NTP" >NTP</tag>
<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>
<tag>OS</tag>
<p>Operating System. voir <ref id="SE" name="SE" ></p>
<tag>PHB</tag>
<p>Pointy Haired Boss (voir : <htmlurl url="http://www.unitedmedia.com/comics/dilbert/about/html/boss.html" name="http://www.unitedmedia.com/comics/dilbert/about/html/boss.html"> ou <htmlurl url="http://www.cplus.fr/html/samedicomedie/dilbert/personnages.html#3" name="http://www.cplus.fr/html/samedicomedie/dilbert/personnages.html#3">). Un personnage de Scott Adams, dans la série Dilbert.</p>
<tag>Provider</tag>
<p>voir <ref id="FAI" name="FAI" ></p>
<tag>Requête DNS directe</tag>
<p>(forward DNS) Une requête DNS qui convertit un nom de domaine en une adresse IP.</p>
<tag>Requête DNS inversé</tag>
<p>(reverse DNS) Une requête DNS qui convertit une adresse IP en un nom de domaine.</p>
<tag>Routeur</tag>
<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>
<tag>Script CGI</tag>
<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>
<tag><label id="SE" >SE</tag>
<p>Système d'exploitation. Linux, Windows, FreeBSD, BeOS, HP-UX, MacOS, etc.</p>
<tag>ssh</tag>
<p>Le shell sécurisé. Une substitution chiffrée pour <it>rlogin</it>, <it>telnet</it>, <it>ftp</it> et autres programmes. Protège contre l'usurpation d'adresse, l'attaque de l'intercepteur, et le reniflage de paquets.</p>
</descrip>
</p>
</article>
|