/usr/share/doc/HOWTO/pl-html/Firewall-HOWTO.pl.html is in doc-linux-pl-html 2002.06.14-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<META HTTP-EQUIV="content-type" content="text/html; charset=iso-8859-2">
<TITLE>Firewalle i proxy serwery</TITLE>
</HEAD>
<BODY>
<H1>Firewalle i proxy serwery<BR></H1>
<H2>Mark Grennan,
<A HREF="mailto:markg@netplus.net">markg@netplus.net</A><BR>
v0.4, 8 listopad 1996<BR>
<B>Wersja polska: Ziemek Borowski
<A HREF="mailto:ziembor@ziembor.waw.pl">ziembor@ziembor.waw.pl</A></B>
v0.1 8 lipiec 1997 </H2>
<P><HR>
<EM>Dokument ten powsta³ w celu uczenia podstaw systemów firewalli
oraz dostarczenia niektórych szczegó³ów w zakresie ustawania
(konfigurowania) filtruj±cych i posredniczacych firwalli na Linuxie. Oryginalna wersja tego dokumentu znajduje siê pod
adresem:
<A HREF="http://okcforum.org/~markg/Firewall-HOWTO.html">http://okcforum.org/~markg/Firewall-HOWTO.html</A>
za¶ polskie t³umaczenie:
<A HREF="http://www.ziembor.waw.pl/~ziembor/JTZ/Firewall-HOWTO.pl.html">http://www.ziembor.waw.pl/~ziembor/JTZ/Firewall-HOWTO.pl.html</A>
<B>Niniejsza wersja opisuje stan z 1997 roku. Je¶li nadal u¿ywasz j±der
z serii 2.0 (nie 2.2 lub 2.4) to jest to dokument dla Ciebie. Nastêpna
wersja tego dokumentu opisuje ew. poza ipfwadm tak¿e ipchains
(dostêpne z
j±drami 2.2) -- zawiera tyle b³êdów, ¿e nale¿a³oby je napisaæ od nowa.
Je¶li szukasz informacji na temat budowania firewalli pod linuksem
odsy³am raczej do t³umaczeñ dokumentacji IPtables wykonanych przez
£ukasza Bromirskiego http://mr0vka.eu.org/.</B></EM>
<HR>
<H2><A NAME="s1">1. Wprowadzenie</A></H2>
<P>Dokument ten Firewall-HOWTO zosta³ napisany przez Davida Ruddera
<A HREF="mailto:drig@execpc.com">mailto:drig@execpc.com</A>.
Chcia³bym Mu podziêkowaæ za zezwolenie na uaktualnienie jego pracy.
<P>Firewalle zyska³y ostatnio wielk± s³awê jako defintywne
rozwi±zanie w dziedzinie bezpieczeñstwa Internetu. Wiêkszo¶æ tej
s³awy jest zas³u¿ona, jednak czê¶æ wynika z nieporozumienia. To JTZ
ma na celu przegl±d: czym s± firewalle, jak je konfigurowaæ, czym
s± serwery proxy i jak je konfigurowaæ oraz aplikacje
(zastosowania) tej technologii poza zakresem bezpieczeñstwa.
<P>
<H2>1.1 Informacja zwrotna, uwagi.</H2>
<P>Wszelkie uwagi bêd± mile widziane.
<B> Proszê: DONO¦CIE O WSZELKICH
NIE¦CIS£O¦CIACH W TYM DOKUMENCIE </B>.
Jestem cz³owiekiem, i jestem
omylny. Je¶li znajdziesz jakie¶ popraw je (w moim najwy¿szym
interesie). Bêdê próbowa³ odpowiedzieæ na wszystkie listy, ale
jestem zajêtym cz³owiekiem, tak wiêc nie obra¿aj siê proszê je¶li
nie odpowiem.
<P><EM>Mój adres: <B>
<A HREF="markg@netplus.net">markg@netplus.net</A> </B></EM>
<P>
<H2>1.2 Deklaracje</H2>
<P><B> NIE ODPOWIADAM ZA JAKIEKOLWIEK ZNISZCZENIA WYNIKAJ¡CE ZE
STOSOWANIA TEGO DOKUMENTU </B> Dokument ten jest pomy¶lany jako
wprowadzenie do technologii firewalli i serwerów proxy.
Nie jestem, i nie zamierzam sobie ro¶ciæ pretensji do bycia ekspertem
w sprawach bezpieczeñstwa. Jestem po prostu cz³owiekiem który
przeczyta³ co nieco, i pasjonuje siê komputerami bardziej ni¿ inni.
Proszê, pisz±c ten tekst chcê pomóc ludziom zaznajomiæ siê z tym
tematem, i nie jestem gotów dawaæ g³owy za dok³adno¶æ podawanych
przeze mnie danych.
<P>
<H2>1.3 Copyright</H2>
<P>Je¶li nie jest powiedziane inaczej, prawa autorskie
dokumenty z serii <EM> Linux
Jak To Zrobiæ </EM>
nale¿± do ka¿dego z autorów. Mog± byæ powielane i rozpowszechniane w
w ca³o¶ci w czê¶ciach, w formie ,,papierowej'' i elektronicznej
dopóki wszêdzie (w ka¿dej z czê¶ci) zachowana jest informacja o
prawach
i autorstwie. Komercyjna redystrybucja jest dozwolona i wskazana;
jednak¿e, autor powinien byæ poinformowany o tym fakcie.
<P>Wszystkie t³umaczenia, poprawki jêzykowe, i prace w³±czaj±ce
musz± zawieraæ niniejsz± notê o prawach autorskich.
<P>Je¶li masz jakie¶ zapytania, proszê o kontakt:
Mark Grennan
<A HREF="mailto:markg@netplus.net">mailto:markg@netplus.net</A>.
<P>
<H2>1.4 Moje pobudki do tej pracy.</H2>
<P>Pomimo wielu dyskusji w grupach comp.os.linux.* (w ci±gu ostatniego
roku) na temat firewalli wydaje mi siê trudnym znalezienie
informacji których potrzebowa³em do ustawienia i skonfigurowania
firewalla. Oryginalna wersja tego HOWto by³a pomocna, ale
nieaktualna. Mam nadziejê, ¿e ta poprawiona wersja
,,Firewall HOWto'' autorstwa Davida Ruddera dostarczy wszystkim
informacji jakiej potrzebuj± do stworzenia dzia³aj±cych ,,¶cian
ognia'' w ci±gu godzin, nie tygodni.
<P>Poza tym uwa¿am ¿e powinienem zwróciæ mój d³ug spo³eczno¶ci
Linuxowej.
<P>
<H2>1.5 TODO (do zrobienia)</H2>
<P>
<UL>
<LI> Instrukcje na temat ustawieñ klientów</LI>
<LI> Znalezienie dobrych serwerów proxych dla us³ug
bazuj±cych na UDP dzia³aj±cych na Linuxie.</LI>
</UL>
<P>
<H2>1.6 Zobacz tak¿e:</H2>
<P>
<UL>
<LI>
<A HREF="http://www.jtz.org.pl/Html/NET-3-HOWTO.pl.html">NET-3 HOWTO</A></LI>
<LI>
<A HREF="http://www.linux.com.pl/LDP/HOWTO/">The Multiple Ethernet Mini HOWTO</A></LI>
<LI>
<A HREF="">Networking with Linux</A></LI>
<LI>
<A HREF="http://www.jtz.org.pl/Html/PPP-HOWTO.pl.html">The PPP HOWTO</A></LI>
<LI>
<A HREF="http://www.ora.com/">TCP/IP Network Administrator's Guide</A> by O'Reilly and
Associates</LI>
<LI>The Documentation for the TIS Firewall Toolkit</LI>
</UL>
<P>Wêze³ pajêczyny nale¿±cy do
<A HREF="http://www.tis.com/">Trusted Information System's (TIS) </A> posiada wspania³a
kolekcjê dokumentacji dotycz±cej firewalli i pokrewnych tematów.
<P>Poza tym pracujê na projektem dotycz±cym bezpieczeñstwa:
,,Bezpieczny Linux''. W miejscu tym
<A HREF="">zgromadzi³em</A> wszystkie informacje, dokumentacje i programy
potrzebne do stworzenia bezpiecznego Linuxa. Napisz do mnie je¶li
chcesz otrzymaæ wiêcej informacji.
<P>
<H2><A NAME="s2">2. Understanding Firewalls</A></H2>
<P> Firewall - ,,¶ciana ogniowa'' jest terminem wziêtym z konstrukcji
samochodu. W samochodach firewalle fizycznynie
oddzielaj± silnik od pasa¿erów. To znaczy, ¿e chroni± one
pasa¿erów w wypadku gdy silnik zapali siê ca³y czas dostarczaj±c
kontroli nad nim.
<P>Komputerowe firewalle s± urz±dzeniami, które chroni± sieci
prywatne od czê¶ci publicznej (jakiej jak Internet).
<P> Komputer bêd±cy ,,¶cian± ognia'' od tej chwili nazywany
,,firewallem'' mo¿e (musi) byæ obecny tak w sieci chronionej jak i w
Internecie. Chroniona sieæ nie mo¿e byæ osi±galna z Internetu,
podobnie jak Internet nie mo¿e byæ osi±galny z chronionej sieci.
<P>Dla niektórych dosiêgniêcie Internetu z izolowanej sieci jest
mo¿liwe
jedynie poprzez zalogowanie siê na firewallu (telnetem) i penetracja
Sieci stamt±d.
<P>Najprostsz± form± firewalla jest podwójnie
zadomowiony system (tj. system z podwójnym po³±czeniem sieciowym).
Je¶li mo¿esz ZAUFAÆ WSZYSTKIM swoim u¿ytkownikom,
mo¿esz prosto skonfigurowaæ
Linuxa (wy³±czaj±c przy kompilacji j±dra forwarding / gatewaying)
Mog± oni logowaæ siê na tym systemie i u¿ywaæ aplikacji sieciowych
takich jak telnet, FTP, czytaæ pocztê i innych jakich dostarczasz.
<P>Z takim ustawieniem, tylko jeden komputer z twojej sieci widzi
resztê ¶wiata poza firewallem. Pozosta³e systemy w twojej chronionej
sieci nie potrzebuj± nawet ustawienia domy¶lnego routingu.
<P>
<P>Aby powy¿szy firewall dzia³a³ <B>MUSISZ UFAÆ WSZYSTKIM SWOIM U¯YTKOWNIKOM </B> Nie jest to zalecane
rozwi±zanie.
<P>
<H2>2.1 Wady firewalli</H2>
<P>Problemem filtruj±cych firewalli jest to, ¿e ograniczaj± dostêp do
twojej sieci z Internetu. Tylko us³ugi na filtrowanie których
zezwoli³e¶ s± dostêpne. Na serwerach proxych u¿ytkownicy mog±
autoryzowaæ siê na firewallu i dopiero wtedy maj± (z systemu
wewn±trz sieci prywatnej) dostêp do Internetu.
<P>Poza tym, nowe typy klientów sieciowych i serwerów przybywaj± prawie
codziennie. Musisz wtedy wynale¼æ nowy sposób zezwolenia na
kontrolowany ich dostêp do twojej sieci, zanim bêd± u¿yte.
<P>
<H2>2.2 Typy firewalli</H2>
<P>Istniej± dwa typy firewalli:
<P>
<OL>
<LI> firewalle filtruj±ce IP - blokuj± ca³y ruch, ale
przepuszczaj± dopuszczony.</LI>
<LI> serwery proxy - serwery po³±czeniowe - wykonuj± po³±czenie
sieciowe za ciebie.</LI>
</OL>
<P>
<H3>Filtuj±ce firwalle</H3>
<P>Firewalle filtruj±ce dzia³aj± na poziomie pakietów IP. S±
zaprojektowane do kontroli przep³ywu bazuj±c na adresie ¼ród³owym,
docelowym, porcie i typie pakietu (zawartych w ka¿dym z pakietów).
<P>Ten typ firewalli jest bardzo bezpieczny, ale traci wiele typów
zapisu. Mo¿e zablokowaæ ludziom z dostêp z sieci prywatnej, ale nie
powie, kto dosta³ siê do twojego systemu publicznego, ani kto
wyszed³
z sieci lokalnej do Internetu.
<P>Filtruj±ce firewalle s± bezwzglêdnymi filtrami. Nawet je¶li chcesz daæ
komu¶ z zewn±trz dostêp do twoich serwerów ,,prywatnych'' nie jeste¶
w stanie bez dania tego dostêpu wszystkim (t³um. jak rozumiem spod
tego adresu)
<P>Linux posiada opcjê filtrowania pakietów w j±drach powy¿ej 1.3.x.
<P>
<H3>Serwery proxy</H3>
<P>Serwery proxy pozwalaj± na niebezpo¶redni dostêp do Internetu, przez
firewall. Najlepszym przyk³adem jak to pracuje jest osoba
telnetuj±ca siê do systemu i stamt±d wykonuj±ca nastêpne po³±czenie.
Tylko ¿e w wypadku serwerów proxy proces ten nastêpuje
automatycznie. Gdy ³±czysz siê z proxy serwerem za pomoc±
oprogramowania klienckiego startuje on swojego klienta i dostarcza
ci danych których zarz±dza³e¶.
<P>Poniewa¿ serwery proxy podwajaj± ka¿de po³±czenie, mo¿liwe jest
zapisywanie ka¿dego z nich.
<P>Wspania³± rzecz± w serwerach proxy jest to, ¿e s± w pe³ni
bezpieczne,
gdy s± prawid³owo ustawione. Nie pozwalaj± nikomu przej¶æ. Nie
dokonuj± bezpo¶redniego routingu.
<P>
<H2><A NAME="s3">3. Ustawianie firewalla</A></H2>
<H2>3.1 Wymagania sprzêtowe.</H2>
<P>Naszym przyk³adem nich bêdzie komputer i486-DX66 z 16 Mb RAMu oraz
500Mb partycj± Linuxow±. System ten posiada dwie karty sieciowe,
jedn± po³±czon± z nasz± sieci± prywatn±, a drug± do sieci lokalnej
nazywanej stref± zdemilitaryzowan± (DMZ). DMZ posiada router
po³±czony do Internetu.
<P>Jest to ca³kiem przyjemny standard dla biznesu. Powiniene¶ u¿yæ
jednej karty sieciowej oraz modemu z PPP do intenetu.
<P>Firewall powinien posiadaæ dwa adresy IP.
<P>Znam wielu ludzi posiadaj±cych ma³e LANy w domu z dwoma lub trzema
komputerami. Mo¿esz rozpatrzyæ nastêpuj±cy model: w³o¿yæ wszystkie
modemy do komputera z Linuxem (np. star± i386) i po³±czyæ wszystkie
do Internetu ³±czem komutowanym. Z takim ustawieniem, gdy tylko jedna
osoba ci±gnie dane mo¿e u¿yæ wszystkich modemów (a wiêc i dzia³aæ
2-3 krotnie szybciej ; -).
<P>
<P>
<H2><A NAME="s4">4. Oprogramowanie dla firewalli</A></H2>
<H2>4.1 Dostêpne pakiety</H2>
<P>Je¶li wszystkim czego potrzebujesz jest filtruj±cy firewall
potrzebujesz jedynie Linuxa i podstawowych pakietów sieciowych.
Jednym z pakietów który mo¿e nie zawieraæ siê w twojej dystrybucji
jest IP Firewall Administration tool (przyp. t³um. w RedHacie 4.0 i
Debianie 1.2.* jest)
(IPFWADM) z <B>
<A HREF="http://www.xos.nl/linux/ipfwadm/">http://www.xos.nl/linux/ipfwadm/</A></B>
<P>
<P>Je¶li chcesz postawiæ serwer proxy potrzebujesz jednego z ni¿ej
wymienionych pakietów:
<OL>
<LI>SOCKS</LI>
<LI>TIS Firewall Toolkit (FWTK)</LI>
</OL>
<P>
<H2>4.2 TIS Firewall Toolkit kontra SOCKS</H2>
<P>Trusted Information System (<B>
<A HREF="http://www.tis.com">http://www.tis.com</A></B>)
jest fragmentem kolekcji programów zaprojektowanych dla firewalli.
Program ten udostêpnia podobne rzeczy jak SOCK, ale jest zbudowany
na innych zasadach. Tam gdzie Socks posiada jeden program
przeprowadzaj±cy wszystkie transakcje s internetem, TIS dostarcza
jednego programu dla ka¿dego z narzêdzi których chcesz u¿yæ w
firrewallu.
<P>Dla pokazania kontrastu u¿yjmy przyk³adów WWW i dostêpu za pomoc±
telnetu. U¿ywaj±c SOCKS, ustawiasz jeden plik konfiguracyjny i
jednego demona. U¿ywaj±c tego pliku tak telnet jak i WWW s±
dostêpne, podobnie jak inne us³ugi których nie zakaza³e¶.
<P>
<P> W pakiecie TIS ustawiasz jednego demona dla (osobno) WWW i
Telnetu
z osobnymi plikami konfiguracyjnymi. Po zrobieniu tego inne us³ugi
internetowe s± zakazane dopóki ich explicite nie ustawisz. Je¶li
demon dla specyficznych us³ug jest niedostêpny (tak jak talk),
istniej± ,,plug-in-y'' dla demona, ale nie tak elastyczne i ³atwe w
konfiguracji jak inne narzêdzia.
<P>
<P> Ró¿nica wygl±da na niewielk±, jest jednak istotna.
SOCKS pozwala
Ci byæ spokojnym.
Przy kiepsko ustawionym SOCKS serwerze kto¶ z
wewn±trz mo¿e uzyskaæ wiêkszy dostêp do Internetu ni¿ by³o
pocz±tkowo planowane. Z pakietem TIS ludzie wewn±trz sieci maj±
jedynie taki dostêp na jaki zezwoli³ administrator.
<P>SOCKS s± ³atwiejszy do konfiguracji, ³atwiejszy do kompilacji i
pozwala na wiêksz± elastyczno¶æ. TIS jest bardziej bezpieczny, jesli
chcesz ustawiaæ u¿ytkowników wewn±trz chronionej sieci. Oba
dostarczaj± ca³kowitego bezpieczeñstwa z zewn±trz.
<P>
<P> Opiszê proces instalacji obydwu.
<H2><A NAME="s5">5. Przygotowanie Linuxa</A></H2>
<H2>5.1 Kompilacja j±dra.</H2>
<P>Zacznij od ¶wie¿ej instalacji twojej dystrybucji Linuxowej (ja
u¿y³em RedHata 3.0.3 (Picasso) i poni¿sze przyk³ady bazuj± na tej
dystrybucji). Im mniej oprogramowania zainstalujesz tym mniej bêdzie
w nim dziur, tylnych wej¶æ i / lub b³êdów wprowadzaj±cych do twojego
systemu problem bezpieczeñstwa, wiêc zainstaluj jedynie minimalny
zestaw aplikacji.
<P>U¿yj stabilnego j±dra. Ja u¿y³em 2.0.14.
Oto jest dokumentacja podstawowych ustawieñ:
<P>Bêdziesz potrzebowa³ rekompilowaæ j±dro sytemu z odpowiednimi
opcjami. (patrz Kernel-HOWto, Ethernet-HOWto oraz NET-2 HOWto je¶li
nie zrobi³e¶ tego wcze¶niej).
Oto s± sieciowe ustawienia które pozna³em wykonuj±c komendê <CODE> make
config</CODE>
<P>
<OL>
<LI>Under General setup
<OL>
<LI>Turn Networking Support ON</LI>
</OL>
</LI>
<LI>Under Networking Options
<OL>
<LI>Turn Network firewalls ON</LI>
<LI>Turn TCP/IP Networking ON</LI>
<LI>Turn IP forwarding/gatewaying OFF (UNLESS you wish to use IP
filtering)</LI>
<LI>Turn IP Firewalling ON</LI>
<LI>Turn IP firewall packet loggin ON (this is not required but
it is a good idea)</LI>
<LI>Turn IP: masquerading OFF (I am not covering this subject
here.)</LI>
<LI>Turn IP: accounting ON</LI>
<LI>Turn IP: tunneling OFF</LI>
<LI>Turn IP: aliasing OFF</LI>
<LI>Turn IP: PC/TCP compatibility mode OFF</LI>
<LI>Turn IP: Reverse ARP OFF</LI>
<LI>Turn Drop source routed frames ON</LI>
</OL>
</LI>
<LI>Under Network device support
<OL>
<LI>Turn Network device support ON</LI>
<LI>Turn Dummy net driver support ON</LI>
<LI>Turn Ethernet (10 or 100Mbit) ON</LI>
<LI>Select your network card</LI>
</OL>
</LI>
</OL>
<P>Teraz mo¿esz dokonaæ rekompilacji i reinstalacji j±dra oraz
zrestartowaæ system. Twoja karta/y sieciowa/e powinny pojawiæ siê w
trakcie procedury startowej. Jesli tak siê nie dzieje sprawd¼ w
innych JTZ, i próbuj dopóki nie bêd± dzia³aæ.
<P>
<H2>5.2 Ustawienie dwóch kart sieciowych</H2>
<P>Je¶li masz dwie kary sieciowe w swoim komputerze w wiêkszo¶ci
przypadków potrzebujesz dodaæ twierdzenie w pliku
<CODE>/etc/lilo.conf</CODE> opisuj±ce ich IRQ i adresy. W moim wypadku
wygl±da to tak:
<PRE>
append= " ether=12,0x300,eth0 ether=15,0x340,eth1 "
</PRE>
<P>
<H2>5.3 Ustawienie adresów sieciowych</H2>
<P>Jest to naprawdê interesuj±ca czê¶æ. Teraz jest czas na podjêcie
kilku decyzji. Dopóki nie chcemy daæ dostêpu komputerom z Internetu
do ¿adnej z czê¶ci naszej sieci lokalnej nie musimy u¿ywaæ
prawdziwych adresów. Istniej± numery wydzielone z internetowych do
ustawienia odrêbnych sieci prywatnych
(przyp. t³umacza: klasa A 10.0.0.0-10.255.255.255, klasy B, i
klasy C: 192.168.0.0.0-192.166.255.255)
Poniewa¿ ka¿dy potrzebuje wiêcej adresów i poniewa¿ adres nie mog±
siê powtarzaæ w Internecie jest to dobry wybór.
<P>Wybrali¶my jedn± z tych klas: 192.168.2.xxx, i u¿yjemy jej w naszym
przyk³adzie.
<P>
<P>Twój serwer proxy bêdzie cz³onkiem obu sieci i bêdzie przekazywa³
dane do i z sieci prywatnej.
<P>
<PRE>
199.1.2.10 __________ 192.168.2.1 192.168.2.2
_ __ _ \ | | / ____/__________
| \/ \/ | \| Firewall |/ | Stacja |
/ Internet \--------| |------------| Robocza |
\_/\_/\_/\_/ |__________| |_______________|
</PRE>
<P>Je¶li u¿ywasz filtruj±cego firewalla mo¿esz u¿ywaæ tych numerów
stosuj±c
<A HREF="">IP masquearading</A>
Firewall bêdzie przesy³a³ pakiety i t³umaczy³ numery IP na
,,PRAWDZIWE'' adresy w Internecie.
<P>Musisz przydzieliæ prawdziwy adres IP karcie sieciowej widocznej z
Internetu (na zewn±trz). I przydzieliæ adres 192.168.2.1 karcie
Ethernetowej wewn±trz. To bêdzie adres IP twojego gatewaya/proxy.
Mo¿esz przydzieliæ pozosta³ym maszynom ze swojej sieci numery z
zakresu
192.168.2.2-192.168.2.254.
<P>
<P> Odk±d u¿ywam RedHat Linux
<P>do ustawienia sieci przy starcie dodajê plik <CODE> ifcfg-eth1</CODE>
w katalogu <CODE>/etc/sysconfig/network-scripts/</CODE>. Jest on czytany
w trakcie startu systemu i ustawiania sieci i tablic routingu.
<P>Mój <CODE>ifcfg-eth1</CODE> wygl±da nastêpuj±co:
<P>
<PRE>
#!/bin/sh
#>>>Device type: ethernet
#>>>Variable declarations:
DEVICE=eth1
IPADDR=192.168.2.1
NETMASK=255.255.255.0
NETWORK=192.168.2.0
BROADCAST=192.168.2.255
GATEWAY=199.1.2.10
ONBOOT=yes
#>>>End variable declarations
</PRE>
Mo¿esz tak¿e u¿yæ tego skryptu do automatycznego po³±czenia
modemowego do twojego IPS. Spójrz na skrypt <CODE>ipup-pop</CODE>
<P>Je¶li u¿ywasz modemu do ³±czenia siê z sieci± twój zewnêtrzny adres
bêdzie
przydzielony w trakcie po³±czenia.
<P>
<H2>5.4 Testowanie twojej sieci</H2>
<P>Zacznij od sprawdzenia <CODE> ifconfig </CODE> i trasowania (routingu)
je¶li masz dwie karty wynik polecenia <CODE>ifconfig</CODE> powinien
wygl±daæ
nastêpuj±co:
<P>
<PRE>
#ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.0 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:1620 errors:0 dropped:0 overruns:0
TX packets:1620 errors:0 dropped:0 overruns:0
eth0 Link encap:10Mbps Ethernet HWaddr 00:00:09:85:AC:55
inet addr:199.1.2.10 Bcast:199.1.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Interrupt:12 Base address:0x310
eth1 Link encap:10Mbps Ethernet HWaddr 00:00:09:80:1E:D7
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
Interrupt:15 Base address:0x350
</PRE>
<P>a twoja tablica trasowania mniej wiêcej tak:
<P>
<PRE>
#route -n
Kernel routing table
Destination Gateway Genmask Flags MSS Window Use Iface
199.1.2.0 * 255.255.255.0 U 1500 0 15 eth0
192.168.2.0 * 255.255.255.0 U 1500 0 0 eth1
127.0.0.0 * 255.0.0.0 U 3584 0 2 lo
default 199.1.2.10 * UG 1500 0 72 eth0
</PRE>
<P><B>Uwaga:</B> 199.1.2.0 jest numerem interface po internetowej
stronie
firewalla za¶ 192.168.2.0 jest wewn±trz.
<P>Teraz spróbuj pingn±æ siê do Internetu z firewalla. Ja zwyk³em u¿ywaæ
nic.dnn.mil jako punktu testowego (w Polsce doradza³bym
<CODE>bilbo.nask.org.pl</CODE> 148.81.16.51). Jest to wci±¿ dobry test,
ale nie dostarcza tylu informacji ile by siê chcia³o.
<P>Je¶li nie rusza za pierwszym razem spróbuj zapukaæ do innych
komputerów
poza swoj± sieci± lokaln±. Je¶li nie dzia³a to znaczy ¿e twoje
po³±czenie PPP
jest ¼le ustawione. Przeczytaj jeszcze raz Net-2 HOWto i spróbuj
jeszcze raz.
<P>Nastêpnie pingnij siê z firewalla do komputera wewn±trz chronionej
sieci.
Ka¿dy komputer powinien móc sondowaæ inny. Je¶li nie spójrz jeszcze
raz
do Net-2 HOWto i popraw ustawienia w swojej sieci.
<P>Teraz spróbuj pingn±æ zewnêtrzny adres z wewnêtrznej czê¶ci
chronionej sieci.
<P>(Notka: to nie jest ¿aden z numerów IP zaczynaj±cych siê od:
192.168.2.xxx.)
Je¶li jest to mo¿liwe, to znaczy ¿e nie wy³±czy³e¶ przesy³ania IP w
konfiguracji j±dra.
Upewnij siê, ¿e tego chcesz. Je¶li zostawisz tê opcjê w³±czon±,
musisz zapoznaæ siê z czê¶ci± tego dokumentu opisuj±c± filtrowanie
pakietów
IP.
<P>Teraz spróbuj sondowaæ internet zza swojego firewalla.
U¿yj tego samego adresu co poprzednio (np. bilbo.nask.org.pl).
Znowu, je¶li wy³±czy³e¶ IP Forwarding nie powinno dzia³aæ. Albo
powinno,
je¶li w³±czy³e¶.
<P>Je¶li masz ustawiony IP Forwarding i u¿ywasz ,,PRAWDZIWYCH''
(nie 192.168.2.*) adresów IP i nie mo¿esz wyj¶æ na zewn±trz, ale
mo¿esz siê dostaæ do internetowej strony swego firewalla
sprawd¼ czy nastêpny router przepuszcza pakiety z twojej sieci
lokalnej
(twój dostawca us³ug internetowych powinien co¶ o tym wiedzieæ).
<P>
<P>Je¶li przydzieli³e¶ swojej sieci adresy 192.168.2.*
pakiety i tak nie bêd± filtrowane. Je¶li przechodz± mimo wszystko
i masz
<CODE>IP masquerading</CODE> w³±czone ten test te¿ zosta³ zdany.
<P>Masz teraz podstawow± konfiguracjê systemu.
<P>
<H2>5.5 Zabezpieczanie firewalla.</H2>
<P>Firewall nie spe³nia swojego zadania je¶li zostawia otwarte okno
dla ataków
przez nieu¿ywane us³ugi. ,,¬li ch³opcy'' mog± zdobyæ twierdzê i
zmodyfikowaæ j± dla swoich potrzeb.
<P>Zacznij wy³±czaæ niepotrzebne us³ugi. Spójrz na
<CODE>/etc/inetd.conf</CODE>.
Plik ten kontroluje co¶ co jest nazywane ,,super serwerem''.
Kontroluje uruchamianie us³ug na ¿±danie.
<P>Kompletnie wy³±cz:
netstat, systat, tftp, bootp oraz finger. Aby wy³±czyæ us³ugê
wystarczy postawiæ znak # (tzw. hash) jako pierwszy znak w
linii.
kiedy to zrobisz wy¶lij sygna³ HUP do procesu inetd
pisz±c: <B> " kill -HUP < pid > " </B>,
gdzie < pid > jest numerem procesu inetd.
Spowoduje to powtórne przeczytanie przez inetd pliku konfiguracyjnego
<P>(inetd.conf) i restart.
<P>Sprawd¼ teraz czy jeste¶ w stanie dostaæ siê do portu obs³uguj±cego
netstat
<CODE> telnet localhost 15</CODE>
Je¶li otrzymasz wynik z netstata nie zrestartowa³e¶ inetd
prawid³owo.
<P>
<H2><A NAME="s6">6. Konfigurowanie filtrowania IP (IPFWADM)</A></H2>
<P>By zacz±æ musisz w³±czyæ przesy³anie pakietów IP w swoim j±drze
i twój system powinien odsy³aæ wszystko co mu siê prze¶le. Twoja
tablica trasowania powinna byæ ustawiona i powiniene¶ mi¶ dostêp
tak wewn±trz jak do zewnêtrznej Sieci.
<P>Ale budujemy firwalla tak wiêc trzeba ograniczyæ wszystkim dostêp
do niego.
<P>W moim systemie stworzy³em parê skryptów ustawiaj±cych zasady
odsy³ania pakietów i polityki dostêpu. Wywo³ujê je z w skryptach
z <CODE> /etc/rc.d </CODE>
w czasie konfiguracji.
<P>Domy¶lnie <CODE>IP Forwarding</CODE> w j±drze systemu odsy³a wszystko.
Dlatego twoje skrypty startowe firewalla powinny rozpoczynaæ swoja
pracê od
zakazania dostêpu dla wszystkich i zerwania wszelkich po³±czeñ
dozwolonych w
poprzednim uruchomieniu ipfw.
Skrypt ten wykorzystuje pewien trick.
<P>
<PRE>
#
# Ustawianie rozliczania i odsy³ania pakietów IP
#
# Forwarding
#
# Domy¶lnie wszystkie us³ugi s± zakazane.
ipfwadm -F -p deny
# Zerwij wszystkie po³±czenia
ipfwadm -F -f
ipfwadm -I -f
ipfwadm -O -f
</PRE>
Teraz mamy doskona³y firewall. Nic nie przechodzi. Bez
w±tpliwo¶ci
pewna cze¶æ us³ug powinna byæ przesy³ana (i tego dotyczy nastêpny
przyk³ad).
<P>
<PRE>
# przesy³anie poczty do twojego MTA
ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10
25
# przesy³anie po³±czeñ pocztowych do innych MTA
ipfwadm -F -a accept -b -P tcp -S 196.1.2.10 25 -D 0.0.0.0/0
1024:65535
# przesy³anie WWW do twojego serwera
/sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D
196.1.2.11 80
# przesy³anie WWW do serwerów zewnêtrznych
/sbin/ipfwadm -F -a accept -b -P tcp -S 196.1.2.* 80 -D 0.0.0.0/0
1024:65535
# przesy³anie ruchu DNS
/sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D
196.1.2.0/24
</PRE>
<P>Mo¿esz byc zaintersowany w rozliczaniu ruchu przechodz±cego przez
twój
firewall. Poni¿szy skrypt liczy ka¿dy z pakietów. Powiniene¶ dodaæ
liniê
albo liczyæ ruch tylko dla jednego systemu.
<P>
<PRE>
# Zerwanie wszystkich po³±czeñ
ipfwadm -A -f
# Rozliczanie
/sbin/ipfwadm -A -f
/sbin/ipfwadm -A out -i -S 196.1.2.0/24 -D 0.0.0.0/0
/sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 196.1.2.0/24
/sbin/ipfwadm -A in -i -S 196.1.2.0/24 -D 0.0.0.0/0
/sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 196.1.2.0/24
</PRE>
Je¶li potrzebowa³e¶ firewalla filtruj±cego mo¿esz skoñczyæ lekturê.
Mi³ego konfigurowania. ; -)
<P>
<H2><A NAME="s7">7. Instalowania serwera proxy - TIS</A></H2>
<P>
<P>
<H2>7.1 Pobranie oprogramowania</H2>
<P>
<P>TIS FWTK jest dostêpny pod adresem: <B>
<A HREF="ftp://ftp.tis.com/">ftp://ftp.tis.com/</A></B>.
<P>Nie pope³nij tego b³êdu co ja. Kiedy dostaniesz siê na serwer TIS
<B> PRZECZYTAJ ,,README''</B>
Pakiet TIS fwtk jest w ukrytym katalogu na ich serwerze.
<P>TIS wymaga byæ <B>wys³a³ email do fwtk-request@tis.com</B>
zawieraj±cego tylko s³owo <B>SEND</B> w ,,ciele''
wiadomo¶ci aby poznaæ nazwê tego ukrytego katalogu (nie jest
potrzebny temat
dla tego listu).
Ich system wy¶le Ci wiadomo¶æ z nazw± katalogu w ci±gu 12 godzin.
<P>Piszê o wersji 2.0 (beta) TIS FWTK. Wersja ta kompiluje siê dobrze
(z pewnymi
wyj±tkami) i wygl±da ¿e wszystko pracuje (u mnie). Gdy zostanie
opublikowana wersja pe³na uaktualniê to HowTo.
<P>Aby zainstalowaæ FWTK stwórz katalog <CODE> fwtk-2.0</CODE>
w <CODE>/usr/src</CODE>. Przenie¶ tak kopiê (fwtk-2.0.tar.gz)
odpakuj j± (tar zxf fwtk-2.0.tar.gz).
<P>FWTK nie po¶redniczy w przekazywaniu SSL (bezpieczne dokumenty w
WWW)
ale posiada dodatek napisany przez Jean-Christophe Touvet. Jest on
dostêpny pod
adresem <B>
<A HREF="ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z">ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z</A></B>. Touvet nie ¶wiadczy wsparcia technicznego dla tego kodu.
<P>U¿ywam zmodyfikowanej wersji: w³±czy³em modu³ dostêpu do
bezpiecznych
serwerów news Netscape napisany przez Eric Wedel
<A HREF="ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z">ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z</A>.
<P>
<P>W naszych przyk³adach bêdê u¿ywa³ wersji Wedel'a.
<P>Aby go zainstalowaæ po prostu strwó¿ katalog <CODE> ssl-gw</CODE> w
katalogu
<CODE>/usr/src/fwtk-2.0</CODE> i wsad¼ tam odpowiednie pliki.
Kiedy instalowa³em tê bramê potrzebne by³y drobne zmiany zanim mog³em
skompilowaæ
resztê zestawu.
<P>Pierwsza zmiana nast±pi³a w pliku <CODE> ssl-gw.c </CODE>.
Nie potrafi³ w³±czyæ jednego z plików include.
<P>
<PRE>
#if defined(__linux)
#include <sys/ioctl.h>
#endif
</PRE>
Druga zmiana polega³a na stworzeniu pliku <CODE>Makefile</CODE>.
Skopiowa³em jeden z innej ,,bramy'' i zast±pi³em nazwê tego modu³u
nazw± <CODE>ssl-gw</CODE>.
<P>
<H2>7.2 Kompilacja TIS FWTK</H2>
<P>Wersja 2.0 FWTK kompiluje siê ³atwiej ni¿ poprzednie. Wci±¿ jednak
jest kilka
rzeczy które powinny byæ zmienione zanim wersja beta bêdzie siê
kompilowaæ bez
przeszkód. Pozostaje mieæ nadziejê, ¿e do tak siê stanie w pe³nej
wersji.
<P>Aby to poprawiæ zacznij zmiany od katalogu
<CODE>/usr/src/fwtk/fwtk</CODE>
i skopiuj plik <CODE> Makefile.config.linux </CODE> na
<CODE> Makefile.config</CODE>.
<P><B>Nie uruchamiaj FIXMAKE</B>.
Instrukcja mówi by¶ to zrobi³. Je¶li chcesz zniszczyæ Makefile
we wszystkich podkatalogach...
<P>Wykona³em poprawkê do <CODE>fixmake</CODE> Problem polega³ na tym,
¿e <CODE>fixmake</CODE> dodawa³ '.' i '' do w³±czanych do
<CODE>Makefile</CODE>
linii.
<P>
<PRE>
sed 's/^include[ ]*\([^ ].*\)/include \1/' $name .proto > $name
</PRE>
<P>Nastêpnie bêdziemy musieli wyedytowaæ <CODE>Makeconfig.file</CODE>.
Potrzebne bêd± dwie zmiany.
<P>Autor programu ustawi³ ¼ród³a programu w swoim <CODE>$HOME/</CODE>.
My kompilujemy w <CODE>/usr/src</CODE> i powinni¶my zmieniæ zmienn±
FWTKSRCDIR.
<P>
<PRE>
FWTKSRCDIR=/usr/src/fwtk/fwtk
</PRE>
<P>Po drugie, przynajmniej niektóre Linuxy u¿ywaj± bazy danych w
formacie
<CODE>gdbm</CODE>. W <CODE> Makefile.config</CODE> jest u¿ywana <CODE>dbm</CODE>
Zapewne bêdziesz musia³ to zmieniæ.
Ja w RedHacie 3.0.3 musia³em.
<P>
<PRE>
DBMLIB=-lgdbm
</PRE>
Ostania poprawka jest w katalogu x-gw. B³±d w wersji beta jest w
pliku
<CODE>socket.c</CODE>. Poprawka polega na usuniêciu tych linii.
<P>
<PRE>
#ifdef SCM_RIGHTS /* 4.3BSD Reno and later */
+ sizeof(un_name->sun_len) + 1
#endif
</PRE>
Je¶li doda³e¶ <CODE>ssl-gw</CODE> do swojego katalogu ¼róde³ trzeba
jeszcze dodaæ
do listy katalogów w Makefile.
<P>
<PRE>
DIRS= smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw
x-gw ssl-gw
</PRE>
<P>Teraz uruchom <B>make</B>.
<P>
<P>
<H2>7.3 Instalacja TIS FWTK</H2>
<P>Uruchom <CODE>make install</CODE>.
Standardowo katalogiem instalacyjnym jest <CODE>/usr/local/etc</CODE>.
Mo¿esz to zmieniæ (ja tego nie zrobi³em) na bardziej bezpieczny
katalog.
Ja zmieni³em prawa dostêpu do niego na <CODE> chmod 700 </CODE>.
<P>Na koniec pozosta³a nam konfiguracja firewalla.
<P>
<H2>7.4 Konfiguracja firewalla TIS FWTK</H2>
<P>Teraz naprawdê rozpoczynamy. Musisz nauczyæ system wywo³ywania tych
nowych
us³ug i stworzyæ tablice do ich kontroli.
<P>Nie próbujê przepisywaæ tutaj dokumentacji do TIS FWTK. Chcê pokazaæ
takie ustawienia jakie u mnie dzia³a³y i wyja¶niæ problemy jakie
spotka³em.
<P>Istniej± trzy pliki kontroluj±ce firewalla.
<P>
<P>
<UL>
<LI>/etc/services
<UL>
<LI>mówi±cy systemowi jaki port obs³uguje jak± us³ugê.</LI>
</UL>
</LI>
</UL>
<UL>
<LI>/etc/inetd.conf
<UL>
<LI>mówi±cy serwerowi inetd jaki program wywo³aæ gdy kto¶ bêdzie siê
dobija³ do zadanego portu.</LI>
</UL>
</LI>
</UL>
<UL>
<LI>/usr/local/etc/netperm-table
<UL>
<LI>mówi±cy FWTK kto jest dopuszczony a kogo winno siê odrzucaæ
przy danej us³udze.</LI>
</UL>
</LI>
</UL>
<P>Aby uzyskaæ poprawne funkcjonowanie FWTK powiniene¶ wyedytowaæ te
pliki
poczynaj±c od góry. Edycja jedynie <CODE>services</CODE> bez inetd.conf
i
netperm-table ustawionych prawid³owo uczyni twój system
niedostêpnym.
<P>
<P>
<H3>Plik netperm-table</H3>
<P>Plik ten odpowiada za kontrolê kto ma dostêp do us³ug nadzorowanych
przez TIS
FWTK. Powiniene¶ my¶leæ o ruch z obu stron firewalla. Ludzie z
zewn±trz twojej
sieci powinni zidentyfikowaæ siê przed otrzymaniem dostêpu, ale
ludzie
z wewn±trz mog± zostaæ dopuszczeni od razu.
<P>Aby ludzie moli siê zidentyfikowaæ firewall u¿ywa programu o nazwie
<B>authsrv</B>
do trzymania bazy danych o u¿ytkownikach i ich has³ach.
Sekcja dotycz±ca autentyfikacji w netperm-table pozwala kontrolowaæ
gdzie jest trzymana baza danych i kto ma do niej dostêp.
<P>Mia³em trochê k³opotów z blokowaniem dostêpu do us³ug. We¼ pod
uwagê ¿e linia
któr± pokazujê u¿ywa '*' do dawania dostêpu dla ka¿dego do tej
us³ugi.
Prawid³owe ustawienie tej linii jest nastêpuj±ce:
'' <CODE>authsrv: premit-hosts localhost</CODE> je¶li chcesz zachowaæ
j± pracuj±c±.
<P>
<PRE>
#
# tablica konfiguracji serwera proxy
#
# Autentyfikacja: regu³y serwera i klienta
authsrv: database /usr/local/etc/fw-authdb
authsrv: permit-hosts *
authsrv: badsleep 1200
authsrv: nobogus true
# Aplikacje klienckie u¿ywaj±ce serwera autentyfikacji
*: authserver 127.0.0.1 114
</PRE>
<P>Aby zaincjalizowaæ bazê danych wykonaj <CODE>su</CODE> do root`a i
uruchom
<B>./authsrv</B> w katalogu <CODE> /var/local/etc </CODE>
by stworzyæ rekord opisuj±cy administratora systemu.
<P>Oto jest przyk³adowa sesja.
<P>Przeczytaj dokumentacjê FWTK, by dowiedzieæ siê jak dodaæ
u¿ytkowników i
grupy.
<P>
<P>
<PRE>
#
# authsrv
authsrv# list
authsrv# adduser admin " Auth DB admin "
ok - user added initially disabled
authsrv# ena admin
enabled
authsrv# proto admin pass
changed
authsrv# pass admin " plugh "
Password changed.
authsrv# superwiz admin
set wizard
authsrv# list
Report for users in database
user group longname ok? proto last
------ ------ ------------------ ----- ------ -----
admin Auth DB admin ena passw never
authsrv# display admin
Report for user admin (Auth DB admin)
Authentication protocol: password
Flags: WIZARD
authsrv# ^D
EOT
#
</PRE>
Kontrola przez bramê telnetu (tn-gw) polega na prostym przes³aniu
i jest to pierwsza któr± powiniene¶ ustawiæ.
<P>W moim przyk³adzie pozwoli³em komputerom z wnêtrza sieci prywatnej
na dostêp bez autentyfikacji (permit-hosts 19961.2.* -passok).
<P>Ale inni u¿ytkownicy powinni wprowadziæ swoj± nazwê u¿ytkownika i
has³o.
(permit-hosts * -auth)
<P>Poza tym pozwoli³em jednemu innemu systemowi (196.1.2.202) na
dostêp
do firewalla bezpo¶rednio, bez przechodzenia przez procedury na
nim.
Sprawiaj± to dwie linie z <CODE>inetacl-in.telnetd</CODE>
<P>Wyja¶niê ich dzia³anie potem.
<P>Powiniene¶ zachowaæ krótki czas timeoutu.
<P>
<PRE>
# regu³y dostêpu telnetu do firewalla:
tn-gw: denial-msg /usr/local/etc/tn-deny.txt
tn-gw: welcome-msg /usr/local/etc/tn-welcome.txt
tn-gw: help-msg /usr/local/etc/tn-help.txt
tn-gw: timeout 90
tn-gw: permit-hosts 196.1.2.* -passok -xok
tn-gw: permit-hosts * -auth
# Tylko administrator mo¿e wykonaæ telnet na port 24 firewalla.
netacl-in.telnetd: permit-hosts 196.1.2.202 -exec
/usr/sbin/in.telnetd
</PRE>
I to samo z r-command.
<P>
<PRE>
# regu³y dostêpu rlogin do firewalla
rlogin-gw: denial-msg /usr/local/etc/rlogin-deny.txt
rlogin-gw: welcome-msg /usr/local/etc/rlogin-welcome.txt
rlogin-gw: help-msg /usr/local/etc/rlogin-help.txt
rlogin-gw: timeout 90
rlogin-gw: permit-hosts 196.1.2.* -passok -xok
rlogin-gw: permit-hosts * -auth -xok
# Tylko administrator mo¿e wykonaæ telnet na port 24 firewalla.
netacl-rlogind: permit-hosts 196.1.2.202 -exec /usr/libexec/rlogind
-a
</PRE>
<P>Nie powiniene¶ dawaæ nikomu bezpo¶redniego dostêpu do firewalla,
w³±czaj±c w to dostêp prze FTP (tak pobieranie jak i wk³adanie).
<P>Jeszcze raz, linie zawieraj±ce permit-hosts pozwalaj± ka¿demu w
chronionej
na wolny dostêp do Internetu, za¶ wszyscy inni musz± siê
autentyfikowaæ.
W³±czy³em zapisywanie ka¿dego pliku pobranego i wys³anego do mojej
konfiguracji.
<P>(-log { retr stor })
<P>Timeouty FTP daj± ci kontrolê nad tym jak d³ugo bêd± utrzymywane
,,z³e'' po³±czenia i jak d³ugo bêd± utrzymywane po³±czenia bez
¿adnej
aktywno¶ci.
<P>
<PRE>
# regu³y dostêpu ftp do firewalla
ftp-gw: denial-msg /usr/local/etc/ftp-deny.txt
ftp-gw: welcome-msg /usr/local/etc/ftp-welcome.txt
ftp-gw: help-msg /usr/local/etc/ftp-help.txt
ftp-gw: timeout 300
ftp-gw: permit-hosts 196.1.2.* -log { retr stor }
ftp-gw: permit-hosts * -authall -log { retr stor }
</PRE>
WWW, Gopher i bazuj±ce na przegl±darkach FTP jest kontrolowane
przez
http-gw. Pierwsze dwie linie tworz± katalog gdzie bêd± sk³adowane
pliki i dokumenty z FTP i WWW. Przy czym s± one w³asno¶ci± root`a
i
s± sk³adowane w katalogu dostêpnym tylko dla niego.
<P>Po³±czenia WWW powinny byæ bardzo krótki. W ten sposób mo¿na
kontrolowaæ jak
d³ugo u¿ytkownicy bêd± utrzymywaæ b³êdne po³±czenia.
<P>
<PRE>
# regu³y dostêpu dla WWW i Gophera
http-gw: userid root
http-gw: directory /jail
http-gw: timeout 90
http-gw: default-httpd www.afs.net
http-gw: hosts 196.1.2.* -log { read write ftp }
http-gw: deny-hosts *
</PRE>
<P><CODE>ssl-gw</CODE> ustawia siê tak samo ja i inne bramy. B±d¼ z ni±
ostro¿ny.
W tym przyk³adzie pozwalam wszystkim z sieci chronionej na ³±czenie
siê
z ka¿dym z serwerów na zewn±trz z wyj±tkiem adresów 127.0.0.*
i 192.1.1.*
oraz (wtedy) na otwieranie portów 443 do 563 u¿ywanych jako znane
porty
dla SSL.
<P>
<PRE>
# zasady dla bramy ssl:
ssl-gw: timeout 300
ssl-gw: hosts 196.1.2.* -dest { !127.0.0.* !192.1.1.*
*:443:563 }
ssl-gw: deny-hosts *
</PRE>
<P>Poni¿ej znajduje siê przyk³ad jak u¿yæ <CODE>plug-gw</CODE> aby pozwoliæ
na
po³±czenie do serwera news. W tym przyk³adzie zezwalam ka¿demu z
sieci
lokalnej na dostêp do tylko jednego systemu i tylko na porcie
zajêtym przez
news.
<P>W drugiej linii pozwalam serwerowi news przes³aæ dane z powrotem do
chronionej
sieci.
<P>Poniewa¿ wiêkszo¶æ klientów spodziewa siê, ¿e pozostaje pod³±czenie
w czasie
gdy u¿ytkownik czyta wiadomo¶ci timeout dla news powinien byæ
d³ugi.
<P>
<PRE>
# brama dla modu³u plug-gw i NetNews
plug-gw: timeout 3600
plug-gw: port nntp 196.1.2.* -plug-to 199.5.175.22 -port nntp
plug-gw: port nntp 199.5.175.22 -plug-to 196.1.2.* -port nntp
</PRE>
<P>Brama dla fingera jest prosta. Ka¿dy z chronionej sieci powinien siê
za³ogowaæ i wtedy pozwalamy mu na u¿ycie fingera na firewallu.
Pozostali nie po prostu dostaj± wiadomo¶æ.
<P>
<PRE>
# uruchomienie us³ugi finger
netacl-fingerd: permit-hosts 196.1.2.* -exec /usr/libexec/fingerd
netacl-fingerd: permit-hosts * -exec /bin/cat
/usr/local/etc/finger.txt
</PRE>
<P>Nie mam ustawionych us³ug dla poczty elektronicznej i X-Windows
wiêc nie dajê przyk³adów. Je¶li kto¶ ma dzia³aj±cy przyk³ad, proszê
o
przys³anie mi.
<P>
<P>
<H3>Plik inetd.conf</H3>
<P>Oto jest kompletny plik <CODE> /etc/inetd.conf </CODE>.
Wszystkie niepotrzebne us³ugi zosta³y wykomentowane.
W³±czy³em pe³ny plik aby pokazaæ co wy³±czyæ i jak ustawiæ now±
us³ugê
w ¶cianie ognia.
{od t³umacza: nie przek³adam typowych dla tego pliku linii}
<P>
<PRE>
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
# brama FTP w ¶cianie ognia
ftp-gw stream tcp nowait.400 root /usr/local/etc/ftp-gw ftp-gw
# brama Telnetu w ¶cianie ognia
telnet stream tcp nowait root /usr/local/etc/tn-gw
/usr/local/etc/tn-gw
# local telnet services
telnet-a stream tcp nowait root /usr/local/etc/netacl in.telnetd
# brama Gophera w ¶cianie ognia
gopher stream tcp nowait.400 root /usr/local/etc/http-gw
/usr/local/etc/http-gw
# brama WWW w ¶cianie ognia
http stream tcp nowait.400 root /usr/local/etc/http-gw
/usr/local/etc/http-gw
# SSL w ¶cianie ognia
ssl-gw stream tcp nowait root /usr/local/etc/ssl-gw ssl-gw
# NetNews firewall proxy (using plug-gw)
nntp stream tcp nowait root /usr/local/etc/plug-gw plug-gw nntp
#nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd
# SMTP (email) w ¶cianie ognia
#smtp stream tcp nowait root /usr/local/etc/smap smap
#
# Shell, login, exec and talk are BSD protocols.
#
#shell stream tcp nowait root /usr/sbin/tcpd in.rshd
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#talk dgram udp wait root /usr/sbin/tcpd in.talkd
#ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd
#
# Pop and imap mail services et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
#imap stream tcp nowait root /usr/sbin/tcpd imapd
#
# The Internet UUCP service.
#
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
-l
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as " boot servers. "
Do not uncomment
# this unless you *need* it.
#
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to
disable
# some or all of these services to improve security.
#
# cfinger is for GNU finger, which is currently not in use in RHS
Linux
#
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f
inet
#
# Time service is used for clock syncronization.
#
#time stream tcp nowait root /usr/sbin/tcpd in.timed
#time dgram udp wait root /usr/sbin/tcpd in.timed
#
# Authentication
#
auth stream tcp wait root /usr/sbin/tcpd in.identd -w -t120
authsrv stream tcp nowait root /usr/local/etc/authsrv authsrv
#
# End of inetd.conf
</PRE>
<P>
<H3>Plik /etc/services</H3>
<P>Tutaj siê wszystko zaczyna. Gdy klient ³±czy siê ze ¶cian± ognia
dzieje siê to na tzw. dobrze znanym porcie (ni¿szym od
1024).
Na przyk³ad telnet ³±czy siê na porcie 23. Serwer <CODE> inetd</CODE>
s³yszy pro¶bê o po³±czenie, i szuka nazwy tej us³ugi w
<CODE>/etc/services</CODE>. Pó¼niej wzywa programy wyznaczony dla tej
us³ugi
w <CODE> /etc/inedt.conf</CODE>
<P>Niektóre z us³ug nie s± normalnie tworzone przez wywo³anie w
<CODE>/etc/serwices</CODE>.
Mo¿na przydzielaæ niektóre porty jak chcemy, Na przyk³ad ja
przydzia³em us³udze ,,telnet administratora'' (telnet-a) port 24.
Ty mo¿esz przydzieliæ tê us³ugê na portowi 2323, je¶li chcesz.
Dla administratora (CIEBIE) bezpo¶rednie po³±czenie ze ¶cian± ognia
na porcie 24 nie 23 no¿e byæ potrzebne, je¶li masz ustawion± swoj±
chronionej sieci.
<P>
<P>
<PRE>
telnet-a 24/tcp
ftp-gw 21/tcp # this named changed
auth 113/tcp ident # User Verification
ssl-gw 443/tcp
</PRE>
<P>
<P>
<H2><A NAME="s8">8. Serwer proxy SOCKS</A></H2>
<H2>8.1 Konfigurowanie serwera Proxy</H2>
<P>SOCKS proxy server dostêpny jest z adresu:
<A HREF="ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz">ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz</A>.
Zawiera przyk³adowy plik konfiguracyjny w katalogu nazwanym:
" socks-conf " . Zdekompresuj i untaruj te pliki
w dowolnym katalogu i postêpuj wed³ug instrukcji.
Mia³em kilka problemów kiedy kompilowa³em go. Upewnij siê, ¿e twój
<CODE>Makefile </CODE> jest prawid³owy.
<P>Jedn± z wa¿niejszych rzeczy jest pamiêtanie o konieczno¶ci dodania
serwera proxy do <CODE>/etc/inetd.conf</CODE>.
Aby móc odpowiedzieæ na ¿±dania musisz dopisaæ nastêpuj±c± liniê:
<P>
<PRE>
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
</PRE>
<P>
<H2>8.2 Konfiguracja serwera proxy</H2>
<P>Program SOCKS potrzebuje dwóch oddzielnych plików
konfiguracyjnych. Jeden z
nich mówi tym komu udzieliæ dostêpu a drugi w jaki sposób przekazywaæ
¿±dania
do w³a¶ciwego serwera proxy. Plik decyduj±cy o dostêpie
powinien
znajdowaæ siê na serwerze. Plik dotycz±cy przekazywania dostêpu
(routingu)
powinien znajdowaæ siê na ka¿dej z maszyn Unixowych. W wypadku DOSa i
czê¶ciowo MaCów komputery powinny mieæ swój w³asny routing.
<P>
<H3>Plik dostêpu.Access File</H3>
<P>W wersji 4.2 Beta SOCSKsów plik dostêpu nazywa siê
" sockd.conf " .
powinien zawieraæ dwie linie: zezwolenia i zakazu. Ka¿da z linii
posiada trzy
pozycje:
<P>
<UL>
<LI>identyfikator (permit/deny)</LI>
<LI>adres IP</LI>
<LI>modyfikator adresu</LI>
</UL>
Identyfikator to <CODE>permit</CODE> lub <CODE> deny</CODE>
Powiniene¶ u¿yæ obu: ka¿dy we w³a¶ciwej linii.
Adres IP powinien zawieraæ czterobajtowy adres w typowej dal IP
notacji.
np. 192.168.2.0.
Modyfikator adresu tak¿e jest normalnym IP i pracuje jak maska.
Rozwiniêcie tego adresu da 32 bity (1 albo zero).
Na przyk³ad, w tej linii:
<P>
<PRE>
permit 192.168.2.23 255.255.255.255
</PRE>
zezwalam na dostêp maszynom w których adres pasuje co do bitu z
zadanym:
pasuje tu tylko 192.168.2.23
<P>
<PRE>
permit 192.168.2.0 255.255.255.0
</PRE>
zezwala na dostêp maszynom z gdyby od 192.168.2.0 do 192.168.2.255,
w
formie ca³ej klasy C.
<P>Nie powiniene¶ mieæ nastêpuj±cej linii:
<P>
<PRE>
permit 192.168.2.0 0.0.0.0
</PRE>
daj±cej dostêp dla wszystkich adresów.
<P>Tak wiêc pierwsza linia daje zezwolenie dla tych adresów którym
chcesz go daæ,
a druga zakazuje reszcie.
Aby zezwoliæ na dostêp wszystkim z klasy 192.168.2.xxx potrzeba
linii:
<P>
<PRE>
permit 192.168.2.0 255.255.255.0
deny 0.0.0.0 0.0.0.0
</PRE>
Zwróæ uwagê na pierwsze " 0.0.0.0 " w linii zakazu.
Z mask± 0.0.0.0 taki adres nie istnieje. Wszystkie zera
zosta³y tam wprowadzone bo s± ³atwe do zapisu.
<P>Dopuszczalne jest umieszczenie wiêkszej ilo¶ci jeden zapisów w
ka¿dej
z linii.
Konkretni u¿ytkownicy mog± ponadto otrzymaæ lub traciæ prawo
dostêpu.
jest to wykonywane przy pomocy autentyfikacji przy pomocy
<CODE>ident</CODE>. Nie wszystkie systemu u¿ywaj± <CODE>ident</CODE>,
w³±czaj±c w to
<CODE> Trumpet Winsock </CODE>, dlatego te¿ nie w³±czam tu przyk³adów.
Dokumentacja do SOCKS jest ca³kiem dobra w tej kwestii.
<P>
<H3>Tablica trasowania</H3>
<P>Tablica routingu w SOCS jest niestety nazywana
<CODE>socks.conf</CODE>.
<P>Tablica routingu mówi klientom SOCKS kiedy u¿ywaæ socks a kiedy
nie.
Na przyk³ad, w twojej sieci 192.168.2.3 nie potrzebuje u¿ywania
socks do
po³±czenia z 192.168.2.1. Po prostu ³±czy siê bezpo¶rednio, po
Ethernecie.
Definiuje siê automatycznie 127.0.0.1 jako loopback. Oczywiste jest,
¿e nie potrzebujesz rozmawiaæ przez ¶cianê ogniow± z samym sob±...
<P>S± trzy typy rekordów:
<P>
<UL>
<LI>deny</LI>
<LI>direct</LI>
<LI>sockd</LI>
</UL>
<P><CODE>Deny</CODE> mówi SOCKS kiedy ma odmówiæ ¿±daniu. Rekord ten ma
takie
same trzy pola jak <CODE>sockd.conf</CODE>: identyfikator, adres i
maska.
Ogólnie, dopóki jest to modyfikowane przez <CODE>sockd.conf</CODE>,
maska w pliku dostêpu jest ustawiona na 0.0.0.0. Je¶li chcesz
pozwoliæ
na dzwonienie do siebie mo¿esz to zrobiæ tutaj.
<P>Rekord <CODE>direct</CODE> mówi które do których adresów nie u¿ywaæ
SOCKS.
Te adresy bêd± dorêczone bez serwera proxy.
<P>Jeszcze raz, mamy trzy pola: identyfikator, adres i maska.
<P>
<PRE>
direct 192.168.2.0 255.255.255.0
</PRE>
W ten sposób kierujesz bezpo¶rednio ca³y ruch w chronionej sieci.
<P>Rekord z <CODE>sockd</CODE>
mówi komputerowi które z hostów s± serwerem SOCKS
<P>Sk³adnia jest nastêpuj±ca:
<PRE>
sockd @=<serverlist> <IP address> <modifier>
</PRE>
Zwróæ uwagê na fragment: @= .
Pozwala on na wprowadzenie listy serwerów proxy.
W naszym przyk³adzie u¿ywamy
tylko jednego. Ale mo¿esz mieæ wiele w celu zwiêkszenia
przepustowo¶ci
i obni¿enia mo¿liwo¶ci awarii.
<P>Pola adresu IP i maski dzia³aj± jak w innych przyk³adach.
Specyfikujesz adres i zakres jego obowi±zywania.
<P>
<H3>DNS zza firewalla Ustawienie us³ugi DNS zza firewalla jest prostymzadaniem. Potrzeba jedynie ustawienia DNS na maszynie z firewallem.I inne maszyny za firewallem bêd± go u¿ywa³y.</H3>
<H2>8.3 Wspó³praca z serwerami proxy</H2>
<H3>Unix</H3>
<P>Aby twoje aplikacje dzia³a³y z serwerami proxy
potrzebujesz je zsockisy... ( " sockified " ).
Bêdziesz potrzebowa³ dwóch ró¿nych telnetów (jeden do komunikacji
bezpo¶redniej drugi przez serwer proxy). SOCKS przychodz± z
instrukcj± jak zSOCKifikowaæ program, i z paroma programami
przygotowanymi na tê mod³ê. Je¶li u¿ywasz zSOCKIfowanej wersji
gdziekolwiek bezpo¶rednio SOCKS automatycznie prze³±czy ciê na
w³a¶ciw±
wersjê. Z tego powodu trzeba zmieniæ nazwy wszystkich programów w
naszej
chronionej sieci i zst±piæ je wersjami
zSOCKisowanymi. <CODE>Finger</CODE> stanie
siê <CODE>finger.orig</CODE>, <CODE>telnet</CODE> stanie siê
<CODE>telnet.orig</CODE> i
tak dalej.
Musisz powiedzieæ SOCKS o ka¿dym w pliku <CODE>include/socks.h</CODE>.
<P>
<P>
<P>Dobre programy s± w stanie dostarczaæ tablic trasowania i
zsocksifikowaæ
siê same. Jednym z nich jest Netscape Navigator. Mo¿esz u¿ywaæ
serwerów
proxy przez wprowadzenie adresu serwera (192.168.2.1 w naszym
wypadku)
w polu SOCKs w Menu Proxies. Ka¿da aplikacja potrzebuje przynajmniej
minimalnej informacji o tym co jest serwerem proxy.
<P>
<H3>MS Windows i Trumpet Winsock</H3>
<P>Trumpet Winsock przychodzi z wbudowanymi mo¿liwo¶ciami wspó³pracy z
serwerem proxy. W
<CODE> setup </CODE> menu wprowad¼ adres serwera, i adresy
komputerów dostêpnych bezpo¶rednio. Program przekieruje na serwer
wszystkie pakiety maj±ce wyj¶æ na zewn±trz.
<P>
<P>
<H3>Ustawienie serwera po¶rednicz±cego do pracy z pakietami UDP.</H3>
<P>Pakiet SOCKS pracuje jedynie z pakietami TCP, pomijaj±c UDP.
Powoduje to trochê mniejsz± jego u¿yteczno¶æ. Wiele u¿ytecznych
programów, takich jak na przyk³ad <CODE>talk</CODE> i <CODE>Archie</CODE>
u¿ywa UDP. Jest jednak pakiet
który mo¿e byæ u¿yty jako serwer proxy dla UDP: UDPrelay
stworzony
przez Toma Fitzgeralda
<A HREF="fitz@wang.com">fitz@wang.com</A>. Niestety w chwili
pisania tego tekstu nie jest on zgodny z Linuxem.
<P>
<P>
<H2>8.4 Wady serwerów proxych</H2>
<P>Serwer proxy, jak pokaza³em powy¿ej jest
<CODE>narzêdziem bezpieczeñstwa</CODE>.
U¿ywanie go zwiêksza dostêpno¶æ do Internetu z ograniczon± liczb±
adresów
wi±¿e siê jednak z wieloma niedogodno¶ciami. Serwer proxy
pozwala
na wiêksz± dostêpno¶æ internetu z sieci chronionej, ale pozostawia
wnêtrze
ca³kowicie niedostêpne z zewn±trz. Oznacza to brak mo¿liwo¶ci
uruchomienia
wewn±trz sieci rozmaitych serwerów, <CODE>talk</CODE> i archie, oraz
bezpo¶redniego wysy³ania listów do chronionej sieci.
Poni¿sze uchybienia wygl±daj± nieznacz±ca, ale sposób my¶lenia
przebiega nastêpuj±co:
<P>
<UL>
<LI> Otrzyma³e¶ informacjê o b³êdach w twojej chronionej sieci.
Jeste¶ w domu, i decydujesz siê sprawdziæ to. Ale nie mo¿esz. Nie
jeste¶ w stanie dostaæ siê do ¿adnego z komputerów poniewa¿ znajduj±
siê za ¶cian± ogniow±.
</LI>
<LI>Twoja córka posz³a do college`u. Chcia³by¶ wys³aæ jej list. Chcesz z
ni± porozmawiaæ o pewnych prywatnych sprawach, i wola³by¶ raczej by
twoja poczta by³a kierowana bezpo¶rednio na twój komputer. Ufasz
swojemu administratorowi, ale to jednak prywatna poczta.
</LI>
<LI>Niemo¿liwo¶æ u¿ycia us³ug dzia³aj±cych z UDP jest wielk± wad±
serwerów proxych. Choæ mam nadziejê, ¿e ju¿ nied³ugo.</LI>
</UL>
<P>Przypadek FTP pokazuje jeszcze jeden problem z serwerami
proxymi. Kiedy pobieram pliki lub wydajê komendê <CODE>ls</CODE>,
serwer FTP otwiera gniazdo (,,socket'') na maszynie klienckiej
i wysy³a o tym informacjê. Serwer proxy nie pozwala na to, tak
wiêc FTP nie dzia³a w sposób prawid³owy.
<P>
<P>Poza tym serwery po¶rednicz±ce dzia³aj± powoli.
Z powodu wiêkszej wydajno¶ci wiêkszo¶æ innych metod dostêpu do Internetu
bêdzie szybsza.
<P>Je¶li masz przydzielony adres IP, i nie martwisz siê o bezpieczeñstwo,
nie u¿ywaj ¶cian ogniowych i/lub serwerów proxych.
Je¶li nie masz nr. IP, i tak¿e nie martwisz siê o bezpieczeñstwo
swojej sieci, mo¿esz u¿yæ jednego z ,,emulatorów IP'' takich jak
<CODE>Term</CODE>, <CODE>Slirp</CODE> lub <CODE>TIA</CODE>. Term jest dostêpny z
<A HREF="ftp://sunsite.unc.edu/">ftp://sunsite.unc.edu/</A>, Slirp z
<A HREF="ftp://blitzen.canberra.edu.au/pub/slirp">ftp://blitzen.canberra.edu.au/pub/slirp</A>, za¶ TIA z
<A HREF="http://markertplace.com/">http://markertplace.com/</A>.
Pakiety te pracuj± szybciej, pozwalaj± na szybsze po³±czenia i na
wiêkszy dostêp z sieci wewnêtrznej do internetu.
Serwery po¶rednicz±ce s± dobre dla tych który maj± du¿e sieci
z komputerami maj±cymi mieæ dostêp ,,w locie'' do internetu
z jednorazowym ustawieniem, i minimalnym wk³adem pracy potem.
<P>
<H2><A NAME="s9">9. Konfiguracja zaawansowana.</A></H2>
<P>Przedstawi³em jedn± konfiguracjê, któr± wypróbowa³em przez stworzeniem
tego dokumentu. Przy czym ten zarys powinien wystarczyæ dla wiêkszo¶ci
ludzi. My¶lê ¿e poni¿szy opis zaawansowanych konfiguracji mo¿e
rozwiaæ pozosta³e w±tpliwo¶ci. Je¶li oprócz tego masz jeszcze jakie¶
pytania poza tym co opisa³em, albo ciê to po prostu interesuj± ciê
szczegó³y zwi±zane ze firewallami i serwerami proxy
mo¿esz przeczytaæ poni¿szy fragment.
<P>
<P>
<H2>9.1 Wielkie sieci wymagaj± po³o¿enia nacisku na bezpieczeñstwo</H2>
<P>Powiedzmy, na przyk³ad, ¿e jeste¶ szefem milicji obywatelskiej i chcesz
,,usieciowæ'' swoj± siedzibê. Masz piêædziesi±t komputerów i 32 nr IP
(5 bitów). Potrzebujesz mo¿liwo¶ci dania ró¿nych poziomów dostêpu do
sieci poniewa¿ powierzasz swoim wspó³pracownikom ró¿ne zadania. Poza tym
bêdziesz potrzebowa³ izolacji okre¶lonych miejsc w sieci od reszty.
<P>Poziomy dostêpu:
<P>
<OL>
<LI>Poziom zewnêtrzny - ukazywany wszystkim, tutaj werbujesz i zdobywasz
nowych ochotników.
</LI>
<LI><B>Troop</B>
poziom ten przeznaczony jest dla ludzi którzy otrzymali dostêp z
poziomu zewnêtrznego. Tutaj jest miejsce gdzie uczysz o rz±dzie dusz i
jak zrobiæ bombê.
</LI>
<LI><B>Mercenary</B>
Tutaj jest miejsce gdzie <EM>naprawdê</EM> planujesz chroniæ.
Tutaj sk³adujesz wszelkie informacje o tym jak rz±dy trzeciego
¶wiata zamierzaj± podbiæ ¶wiat, twoje plany dla Newt Gingich, Oklahoma
City, sk³adujesz tajne informacje.</LI>
</OL>
<P>
<H3>Konfiguracja sieci</H3>
<P>Numery IP s± ustawione w nastêpuj±cy sposób:
<P>
<P>
<UL>
<LI>1 numer to 192.168.2.255, bêd±cy adresem rozg³oszeniowym
nie u¿ywanym</LI>
<LI>23 z 32 adresów IP jest przydzielonych dla maszyn dostêpnych w
Internecie.</LI>
<LI>1 dodatkowy adres IP zosta³ przydzielony Linuxowi</LI>
<LI>1 dodatkowy adres IP zosta³ przydzielony innemu linuxowi</LI>
<LI>2 numery IP zosta³y przydzielone routerowi</LI>
<LI>4 pozosta³e pozostaj± od³±czone ale otrzymuj± nazwy domenowe: paul, ringo,
john, george .</LI>
<LI>chroniona sieæ ma numer 192.168.2.xxx</LI>
</UL>
<P>Teraz budujemy dwie izolowane sieci, ka¿da w innym pokoju. S± one
trasowane przez ekranowany ethernet i s± kompletnie niewidoczne z
innych pomieszczeñ. Na szczê¶cie ekranowany Ethernet zachowuje siê
tak samo jak zwyczajny ethernet.
<P>
<P>Ka¿da z tych sieci jest po³±czona do jednej ze stacji linuxowych na
dodatkowych adresach IP.
<P>S± to serwery plików po³±czone do obu chronionych sieci. Jest tak,
poniewa¿ planujemy daæ dostêp tak dla sieci Troops ja i wy¿szej.
<P>Serwer plików nosi numery 192.168.2.17 dla sieci Troop i
192.168.2.23 dla sieci Mercenary.
Maj± ró¿ne adresy poniewa¿ maj± dwie ró¿ne karty sieciowe.
network. <CODE>IP Forwarding</CODE> jest wy³±czony.
<P><CODE>IP Forwarding</CODE> na obu stacjach linuxowych tak¿e jest wy³±czony.
Router nie powinien przesy³aæ pakietów przeznaczonych dla sieci
192.168.2.xxx dopóki mu tego wprost nie powiemy, tak wiêc dostêp do
internetu pozostaje wy³±czony. Wy³±czenie przesy³ania IP ma na celu
zablokowanie po³±czeñ z sieci Troop do sieci Mercenary na odwrót.
<P>Serwer NFS mo¿e ponadto oferowaæ ró¿ne pliki dla ró¿nych sieci.
<P>To ³atwe przy drobnych operacjach z symbolicznymi
odniesieniami mo¿na zrobiæ w ten sposób ¿e wspólne pliki s± dzielone
przez wszystkich. U¿ycie tego typu ustawieñ i ró¿nych kart sieciowych
umo¿liwia Ci zastosowanie jednego serwera plików dla trzech sieci.
<P>
<H3>Serwer proxy</H3>
<P>Teraz, dopóki wszystkie trzy poziomu bêd± mo¿liwe do pracy w ramach
wyznaczonych zadañ bêd± potrzebowa³y dostêpu do sieci.
Zewnêtrzna sieæ jest po³±czona bezpo¶rednio z internetem, tak wiêc nie
ma tu zastosowania dla serwera po¶rednicz±cego. Sieci Mercenary i Troop
znajduj± siê za ¶cian± ogniow± wiêc potrzebny im serwer proxy.
Konfiguracja obu jest bardzo podobna. Oba maj± takie same adresu IP.
Jedyna ró¿nica polega na nieco innych parametrach.
<P>
<OL>
<LI>Nie ka¿dy mo¿e u¿yæ serwera plików dla dostêpu do Interntu.
Wystawia to go na wirusy i inne brzydkie rzeczu.
</LI>
<LI>Nie chcemy zezwoliæ sieci Troop na dostêp do WWW. Przechodz± szkolenie
I jaki kolwiek przep³y informacji móg³by zniszczyæ jego efekty.
</LI>
</OL>
<P>Tak wiêc w pliku <CODE>sockd.conf</CODE> w linuxie w sieci Troop znajdzie
siê nastêpuj±ca linia.
<P>
<PRE>
deny 192.168.2.17 255.255.255.255
</PRE>
a w stacji przeznaczonej dla Mercenary:
<P>
<PRE>
deny 192.168.2.23 255.255.255.255
</PRE>
Teraz w stacji linuxowej sieci Troop wpisujemy:
<P>
<PRE>
deny 0.0.0.0 0.0.0.0 eq 80
</PRE>
Ten tekst mówi ¿e zabraniamy dostêpu wszystkich maszynom
próbuj±cym siê dostaæ do portu równego (eq) 80 (http).
Nadal pozwala siê na dostêp do wszystkich us³ug z wyj±tkiem WWW.
<P>Teraz oba pliki powinny zawieraæ linie:
<P>
<PRE>
permit 192.168.2.0 255.255.255.0
</PRE>
by zezwoliæ wszystkim komputerom z sieci 192.168.2.xxx na u¿ycie
tego serwera po¶rednicz±cego zamiast tego który zosta³ zakazany (np.
serwer plików i dostêp do WWW z sieci Troop).
<P>
<P>W sieci Troop w pliku <CODE>sockd.conf</CODE> powinien wygl±daæ w ten
sposób:
<P>
<PRE>
deny 192.168.2.17 255.255.255.255
deny 0.0.0.0 0.0.0.0 eq 80
permit 192.168.2.0 255.255.255.0
</PRE>
<P>a w sieci Mercenary mniej wiêcej tak:
<P>
<PRE>
deny 192.168.2.23 255.255.255.255
permit 192.168.2.0 255.255.255.0
</PRE>
<P>To powinno zakoñczyæ konfiguracjê wszystkiego. Ka¿da z sieci jest
izolowana, z prawid³owymi ustawieniami interakcji. Ka¿dy powinien byæ
szczê¶liwy.
<P>Dalej... Podbij ¶wiat...
<H2><A NAME="s10">10. Od t³umacza.</A></H2>
<P>Zdajê sobie sprawê ile w tym tekscie jest potkniêæ jêzykowych, przeinaczeñ.
Je¶li które¶ ciê dra¿ni± prze¶lij mi swoje uwagi.
Aha, jeszcze jedno. Wyra¿enia <CODE>firewall</CODE> i <CODE>¶ciana ogniowa</CODE>
oraz <CODE>proxy</CODE> i <CODE>serwer po¶rednicz±cy </CODE> traktujê
(przynajmniej na razie) zamiennie. (choc ju¿ wiêkszo¶æ polskich
odpowiedników (na ¿yczenie publiczno¶ci) usun±³em.
<P>Celowo pozostawiam tekst bez zwyczajowego (c) t³umacza ;-)
<P>
</BODY>
</HTML>
|