This file is indexed.

/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= &quot; ether=12,0x300,eth0 ether=15,0x340,eth1 &quot; 
</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> &quot; kill -HUP  &lt; pid &gt;  &quot; </B>,
gdzie  &lt; pid &gt;  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    &lt;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  &quot; Auth DB admin &quot; 
  ok - user added initially disabled
  authsrv# ena admin
  enabled
  authsrv# proto admin pass
  changed
  authsrv# pass admin  &quot; plugh &quot; 
  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  &quot; boot servers. &quot; 
 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:
&quot; socks-conf &quot; . 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ê
&quot; sockd.conf &quot; .
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  &quot; 0.0.0.0 &quot;  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 @=&lt;serverlist> &lt;IP address> &lt;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... ( &quot; sockified &quot; ).
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>