File: 05_services.po

package info (click to toggle)
harden-doc 3.19%2Bnmu1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, bullseye, sid
  • size: 15,332 kB
  • sloc: xml: 11,790; sh: 52; makefile: 16
file content (1318 lines) | stat: -rw-r--r-- 86,108 bytes parent folder | download | duplicates (4)
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
msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2018-03-19 00:26+0100\n"
"PO-Revision-Date: 2018-03-19 00:26+0100\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"Language: en-US \n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Publican v4.3.2\n"

msgid "Securing services running on your system"
msgstr ""

msgid "Services can be secured in a running system in two ways:"
msgstr ""

msgid "Making them only accessible at the access points (interfaces) they need to be in."
msgstr ""

msgid "Configuring them properly so that they can only be used by legitimate users in an authorized manner."
msgstr ""

msgid "Restricting services so that they can only be accessed from a given place can be done by restricting access to them at the kernel (i.e. firewall) level, configure them to listen only on a given interface (some services might not provide this feature) or using some other methods, for example the Linux vserver patch (for 2.4.16) can be used to force processes to use only one interface."
msgstr ""

msgid "Regarding the services running from <command>inetd</command> (<command>telnet</command>, <command>ftp</command>, <command>finger</command>, <command>pop3</command>...) it is worth noting that <command>inetd</command> can be configured so that services only listen on a given interface (using <literal>service@ip</literal> syntax) but that's an undocumented feature. One of its substitutes, the <command>xinetd</command> meta-daemon includes a <literal>bind</literal> option just for this matter. See <citerefentry><refentrytitle>ixnetd.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page."
msgstr ""

msgid ""
"\n"
"service nntp\n"
"{\n"
"        socket_type     = stream\n"
"        protocol        = tcp\n"
"        wait            = no\n"
"        user            = news\n"
"        group           = news\n"
"        server          = /usr/bin/env\n"
"        server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin\n"
"+/usr/sbin/snntpd logger -p news.info\n"
"        bind            = 127.0.0.1\n"
"} "
msgstr ""

msgid "The following sections detail how specific individual services can be configured properly depending on their intended use."
msgstr ""

msgid "Securing ssh"
msgstr ""

msgid "If you are still running telnet instead of ssh, you should take a break from this manual and change this. Ssh should be used for all remote logins instead of telnet. In an age where it is easy to sniff Internet traffic and get clear-text passwords, you should use only protocols which use cryptography. So, perform an <literal>apt-get install ssh</literal> on your system now."
msgstr ""

msgid "Encourage all the users on your system to use ssh instead of telnet, or even better, uninstall telnet/telnetd. In addition you should avoid logging into the system using ssh as root and use alternative methods to become root instead, like <command>su</command> or <command>sudo</command>. Finally, the <filename>sshd_config</filename> file, in <filename>/etc/ssh</filename>, should be modified to increase security as well:"
msgstr ""

msgid "<literal>ListenAddress 192.168.0.1</literal> Have ssh listen only on a given interface, just in case you have more than one (and do not want ssh available on it) or in the future add a new network card (and don't want ssh connections from it)."
msgstr ""

msgid "<literal>PermitRootLogin no</literal> Try not to permit Root Login wherever possible. If anyone wants to become root via ssh, now two logins are needed and the root password cannot be brute forced via SSH."
msgstr ""

msgid "<literal>Port 666</literal> or <literal>ListenAddress 192.168.0.1:666</literal> Change the listen port, so the intruder cannot be completely sure whether a sshd daemon runs (be forewarned, this is security by obscurity)."
msgstr ""

msgid "<literal>PermitEmptyPasswords no</literal> Empty passwords make a mockery of system security."
msgstr ""

msgid "<literal>AllowUsers alex ref me@somewhere</literal> Allow only certain users to have access via ssh to this machine. <literal>user@host</literal> can also be used to restrict a given user from accessing only at a given host."
msgstr ""

msgid "<literal>AllowGroups wheel admin</literal> Allow only certain group members to have access via ssh to this machine. AllowGroups and AllowUsers have equivalent directives for denying access to a machine. Not surprisingly they are called \"DenyUsers\" and \"DenyGroups\"."
msgstr ""

msgid "<literal>PasswordAuthentication yes</literal> It is completely your choice what you want to do. It is more secure to only allow access to the machine from users with ssh-keys placed in the <filename>~/.ssh/authorized_keys</filename> file. If you want so, set this one to \"no\"."
msgstr ""

msgid "Disable any form of authentication you do not really need, if you do not use, for example <literal>RhostsRSAAuthentication</literal>, <literal>HostbasedAuthentication</literal>, <literal>KerberosAuthentication</literal> or <literal>RhostsAuthentication</literal> you should disable them, even if they are already by default (see the manpage <citerefentry><refentrytitle>sshd_config</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page)."
msgstr ""

msgid "<literal>Protocol 2</literal> Disable the protocol version 1, since it has some design flaws that make it easier to crack passwords. For more information read <ulink name=\"a paper regarding ssh protocol problems\" url=\"http://earthops.net/ssh-timing.pdf\" /> or the <ulink name=\"Xforce advisory\" url=\"http://xforce.iss.net/static/6449.php\" />."
msgstr ""

msgid "<literal>Banner <filename>/etc/<replaceable>some_file</replaceable></filename></literal> Add a banner (it will be retrieved from the file) to users connecting to the ssh server. In some countries sending a warning before access to a given system about unauthorized access or user monitoring should be added to have legal protection."
msgstr ""

msgid "You can also restrict access to the ssh server using <literal>pam_listfile</literal> or <literal>pam_wheel</literal> in the PAM control file. For example, you could keep anyone not listed in <filename>/etc/loginusers</filename> away by adding this line to <filename>/etc/pam.d/ssh</filename>:"
msgstr ""

msgid "\n"
"auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers"
msgstr ""

msgid "As a final note, be aware that these directives are from a OpenSSH configuration file. Right now, there are three commonly used SSH daemons, ssh1, ssh2, and OpenSSH by the OpenBSD people. Ssh1 was the first ssh daemon available and it is still the most commonly used (there are rumors that there is even a Windows port). Ssh2 has many advantages over ssh1 except it is released under a closed-source license. OpenSSH is completely free ssh daemon, which supports both ssh1 and ssh2. OpenSSH is the version installed on Debian when the package <application>ssh</application> is chosen."
msgstr ""

msgid "You can read more information on how to set up SSH with PAM support in the <ulink name=\"security mailing list archives\" url=\"http://lists.debian.org/debian-security/2001/debian-security-200111/msg00395.html\" />."
msgstr ""

msgid "Chrooting ssh"
msgstr ""

msgid "Currently OpenSSH does not provide a way to chroot automatically users upon connection (the commercial version does provide this functionality). However there is a project to provide this functionality for OpenSSH too, see <ulink url=\"http://chrootssh.sourceforge.net\" />, it is not currently packaged for Debian, though. You could use, however, the <filename>pam_chroot</filename> module as described in <xref linkend=\"user-restrict\" />."
msgstr ""

msgid "In <xref linkend=\"chroot-ssh-env\" /> you can find several options to make a chroot environment for SSH."
msgstr ""

msgid "Ssh clients"
msgstr ""

msgid "If you are using an SSH client against the SSH server you must make sure that it supports the same protocols that are enforced on the server. For example, if you use the <application>mindterm</application> package, it only supports protocol version 1. However, the sshd server is, by default, configured to only accept version 2 (for security reasons)."
msgstr ""

msgid "Disallowing file transfers"
msgstr ""

msgid "If you do <emphasis>not</emphasis> want users to transfer files to and from the ssh server you need to restrict access to the <command>sftp-server</command> <emphasis>and</emphasis> the <command>scp</command> access. You can restrict <command>sftp-server</command> by configuring the proper <literal>Subsystem</literal> in the <filename>/etc/ssh/sshd_config</filename>."
msgstr ""

msgid "You can also chroot users (using <application>libpam-chroot</application> so that, even if file transfer is allowed, they are limited to an environment which does not include any system files."
msgstr ""

msgid "Restricing access to file transfer only"
msgstr ""

msgid "You might want to restrict access to users so that they can only do file transfers and cannot have interactive shells. In order to do this you can either:"
msgstr ""

msgid "disallow users from login to the ssh server (as described above either through the configuration file or PAM configuration)."
msgstr ""

msgid "give users a restricted shell such as <application>scponly</application> or <application>rssh</application>. These shells restrict the commands available to the users so that they are not provided any remote execution priviledges."
msgstr ""

msgid "Securing Squid"
msgstr ""

msgid "Squid is one of the most popular proxy/cache server, and there are some security issues that should be taken into account. Squid's default configuration file denies all users requests. However the Debian package allows access from 'localhost', you just need to configure your browser properly. You should configure Squid to allow access to trusted users, hosts or networks defining an Access Control List on <filename>/etc/squid/squid.conf</filename>, see the <ulink name=\"Squid User's Guide\" url=\"http://www.deckle.co.za/squid-users-guide/Main_Page\" /> for more information about defining ACLs rules. Notice that Debian provides a minimum configuration for Squid that will prevent anything, except from <emphasis>localhost</emphasis> to connect to your proxy server (which will run in the default port 3128). You will need to customize your <filename>/etc/squid/squid.conf</filename> as needed."
msgstr ""

msgid "The recommended minimum configuration (provided with the package) is shown below:"
msgstr ""

msgid ""
"\n"
"acl all src 0.0.0.0/0.0.0.0\n"
"acl manager proto cache_object\n"
"acl localhost src 127.0.0.1/255.255.255.255\n"
"acl SSL_ports port 443 563\n"
"acl Safe_ports port 80          # http\n"
"acl Safe_ports port 21          # ftp\n"
"acl Safe_ports port 443 563     # https, snews\n"
"acl Safe_ports port 70          # gopher\n"
"acl Safe_ports port 210         # wais\n"
"acl Safe_ports port 1025-65535  # unregistered ports\n"
"acl Safe_ports port 280         # http-mgmt\n"
"acl Safe_ports port 488         # gss-http\n"
"acl Safe_ports port 591         # filemaker\n"
"acl Safe_ports port 777         # multiling http\n"
"acl Safe_ports port 901         # SWAT\n"
"acl purge method PURGE\n"
"acl CONNECT method CONNECT\n"
"(...)\n"
"# Only allow cachemgr access from localhost\n"
"http_access allow manager localhost\n"
"http_access deny manager\n"
"# Only allow purge requests from localhost\n"
"http_access allow purge localhost\n"
"http_access deny purge\n"
"# Deny requests to unknown ports\n"
"http_access deny !Safe_ports\n"
"# Deny CONNECT to other than SSL ports\n"
"http_access deny CONNECT !SSL_ports\n"
"#\n"
"# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS\n"
"#\n"
"http_access allow localhost\n"
"# And finally deny all other access to this proxy\n"
"http_access deny all\n"
"#Default:\n"
"# icp_access deny all\n"
"#\n"
"#Allow ICP queries from everyone\n"
"icp_access allow all"
msgstr ""

msgid "You should also configure Squid based on your system resources, including cache memory (option <literal>cache_mem</literal>), location of the cached files and the amount of space they will take up on disk (option <literal>cache_dir</literal>)."
msgstr ""

msgid "Notice that, if not properly configured, someone may relay a mail message through Squid, since the HTTP and SMTP protocols are designed similarly. Squid's default configuration file denies access to port 25. If you wish to allow connections to port 25 just add it to Safe_ports lists. However, this is <emphasis>NOT</emphasis> recommended."
msgstr ""

msgid "Setting and configuring the proxy/cache server properly is only part of keeping your site secure. Another necessary task is to analyze Squid's logs to assure that all things are working as they should be working. There are some packages in Debian GNU/Linux that can help an administrator to do this. The following packages are available in Debian 3.0 and Debian 3.1 (sarge):"
msgstr ""

msgid "<application>calamaris</application> - Log analyzer for Squid or Oops proxy log files."
msgstr ""

msgid "<application>modlogan</application> - A modular logfile analyzer."
msgstr ""

msgid "<application>sarg</application> - Squid Analysis Report Generator."
msgstr ""

msgid "<application>squidtaild</application> - Squid log monitoring program."
msgstr ""

msgid "When using Squid in Accelerator Mode it acts as a web server too. Turning on this option increases code complexity, making it less reliable. By default Squid is not configured to act as a web server, so you don't need to worry about this. Note that if you want to use this feature be sure that it is really necessary. To find more information about Accelerator Mode on Squid see the <ulink name=\"Squid User's Guide - Accelerator Mode\" url=\"http://www.deckle.co.za/squid-users-guide/Accelerator_Mode\" />"
msgstr ""

msgid "Securing FTP"
msgstr ""

msgid "If you really have to use FTP (without wrapping it with sslwrap or inside a SSL or SSH tunnel), you should chroot ftp into the ftp users' home directory, so that the user is unable to see anything else than their own directory. Otherwise they could traverse your root file system just like if they had a shell in it. You can add the following line in your <filename>proftpd.conf</filename> in your global section to enable this chroot feature:"
msgstr ""

msgid "\n"
"DefaultRoot ~"
msgstr ""

msgid "Restart ProFTPd by <literal>/etc/init.d/proftpd restart</literal> and check whether you can escape from your homedir now."
msgstr ""

msgid "To prevent ProFTPd DoS attacks using ../../.., add the following line in <filename>/etc/proftpd.conf</filename>: <literal>DenyFilter \\*.*/</literal>"
msgstr ""

msgid "Always remember that FTP sends login and authentication passwords in clear text (this is not an issue if you are providing an anonymous public service) and there are better alternatives in Debian for this. For example, <command>sftp</command> (provided by <application>ssh</application>). There are also free implementations of SSH for other operating systems: <ulink name=\"putty\" url=\"http://www.chiark.greenend.org.uk/~sgtatham/putty/\" /> and <ulink name=\"cygwin\" url=\"http://www.cygwin.com\" /> for example."
msgstr ""

msgid "However, if you still maintain the FTP server while making users access through SSH you might encounter a typical problem. Users accessing anonymous FTP servers inside SSH-secured systems might try to log in the <emphasis>FTP server</emphasis>. While the access will be refused, the password will nevertheless be sent through the net in clear form. To avoid that, ProFTPd developer TJ Saunders has created a patch that prevents users feeding the anonymous FTP server with valid SSH accounts. More information and patch available at: <ulink name=\"ProFTPD Patches\" url=\"http://www.castaglia.org/proftpd/#Patches\" />. This patch has been reported to Debian too, see <ulink name=\"Bug #145669\" url=\"http://bugs.debian.org/145669\" />."
msgstr ""

msgid "Securing access to the X Window System"
msgstr ""

msgid "Today, X terminals are used by more and more companies where one server is needed for a lot of workstations. This can be dangerous, because you need to allow the file server to connect to the clients (X server from the X point of view. X switches the definition of client and server). If you follow the (very bad) suggestion of many docs, you type <literal>xhost +</literal> on your machine. This allows any X client to connect to your system. For slightly better security, you can use the command <literal>xhost +hostname</literal> instead to only allow access from specific hosts."
msgstr ""

msgid "A much more secure solution, though, is to use ssh to tunnel X and encrypt the whole session. This is done automatically when you ssh to another machine. For this to work, you have to configure both the ssh client and the ssh server. On the ssh client, <literal>ForwardX11</literal> should be set to <literal>yes</literal> in <filename>/etc/ssh/ssh_config</filename>. On the ssh server, <literal>X11Forwarding</literal> should be set to <literal>yes</literal> in <filename>/etc/ssh/sshd_config</filename> and the package <application>xbase-clients</application> should be installed because the ssh server uses <filename>/usr/X11R6/bin/xauth</filename> (<filename>/usr/bin/xauth</filename> on Debian unstable) when setting up the pseudo X display. In times of SSH, you should drop the xhost based access control completely."
msgstr ""

msgid "For best security, if you do not need X access from other machines, switch off the binding on TCP port 6000 simply by typing:"
msgstr ""

msgid "\n"
"$ startx -- -nolisten tcp"
msgstr ""

msgid "This is the default behavior in Xfree 4.1.0 (the Xserver provided in Debian 3.0 and 3.1). If you are running Xfree 3.3.6 (i.e. you have Debian 2.2 installed) you can edit <filename>/etc/X11/xinit/xserverrc</filename> to have it something along the lines of:"
msgstr ""

msgid ""
"\n"
"#!/bin/sh\n"
"exec /usr/bin/X11/X -dpi 100 -nolisten tcp"
msgstr ""

msgid "If you are using XDM set <filename>/etc/X11/xdm/Xservers</filename> to: <literal>:0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp</literal>. If you are using Gdm make sure that the <literal>DisallowTCP=true</literal> option is set in the <filename>/etc/gdm/gdm.conf</filename> (which is the default in Debian). This will basically append <literal>-nolisten tcp</literal> to every X command line <footnote><para> Gdm will <emphasis>not</emphasis> append <literal>-nolisten tcp</literal> if it finds a <literal>-query</literal> or <literal>-indirect</literal> on the command line since the query wouldn't work.</para></footnote>."
msgstr ""

msgid "You can also set the default's system timeout for <command>xscreensaver</command> locks. Even if the user can override it, you should edit the <filename>/etc/X11/app-defaults/XScreenSaver</filename> configuration file and change the lock line:"
msgstr ""

msgid "\n"
"*lock:                  False"
msgstr ""

msgid "(which is the default in Debian) to:"
msgstr ""

msgid "\n"
"*lock:                  True"
msgstr ""

msgid "FIXME: Add information on how to disable the screensavers which show the user desktop (which might have sensitive information)."
msgstr ""

msgid "Read more on X Window security in <ulink name=\"XWindow-User-HOWTO\" url=\"http://www.tldp.org/HOWTO/XWindow-User-HOWTO.html\" /> (<filename>/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz</filename>)."
msgstr ""

msgid "FIXME: Add info on thread of debian-security on how to change config files of XFree 3.3.6 to do this."
msgstr ""

msgid "Check your display manager"
msgstr ""

msgid "If you only want to have a display manager installed for local usage (having a nice graphical login, that is), make sure the XDMCP (X Display Manager Control Protocol) stuff is disabled. In XDM you can do this with this line in <literal>/etc/X11/xdm/xdm-config</literal>:"
msgstr ""

msgid "\n"
"DisplayManager.requestPort:     0"
msgstr ""

msgid "For GDM there should be in your gdm.conf:"
msgstr ""

msgid ""
"\n"
"[xdmcp]\n"
"Enable=false"
msgstr ""

msgid "Normally, all display managers are configured not to start XDMCP services per default in Debian."
msgstr ""

msgid "Securing printing access (the lpd and lprng issue)"
msgstr ""

msgid "Imagine, you arrive at work, and the printer is spitting out endless amounts of paper because someone is DoSing your line printer daemon. Nasty, isn't it?"
msgstr ""

msgid "In any UNIX printing architecture, there has to be a way to get the client's data to the host's print server. In traditional <command>lpr</command> and <command>lp</command>, the client command copies or symlinks the data into the spool directory (which is why these programs are usually SUID or SGID)."
msgstr ""

msgid "In order to avoid any issues you should keep your printer servers especially secure. This means you need to configure your printer service so it will only allow connections from a set of trusted servers. In order to do this, add the servers you want to allow printing to your <filename>/etc/hosts.lpd</filename>."
msgstr ""

msgid "However, even if you do this, the <command>lpr</command> daemon accepts incoming connections on port 515 of any interface. You should consider firewalling connections from networks/hosts which are not allowed printing (the <command>lpr</command> daemon cannot be limited to listen only on a given IP address)."
msgstr ""

msgid "<command>Lprng</command> should be preferred over <command>lpr</command> since it can be configured to do IP access control. And you can specify which interface to bind to (although somewhat weirdly)."
msgstr ""

msgid "If you are using a printer in your system, but only locally, you will not want to share this service over a network. You can consider using other printing systems, like the one provided by <application>cups</application> or <ulink name=\"PDQ\" url=\"http://pdq.sourceforge.net/\" /> which is based on user permissions of the <filename>/dev/lp0</filename> device."
msgstr ""

msgid "In <application>cups</application>, the print data is transferred to the server via the HTTP protocol. This means the client program doesn't need any special privileges, but does require that the server is listening on a port somewhere."
msgstr ""

msgid "However, if you want to use <command>cups</command>, but only locally, you can configure it to bind to the loopback interface by changing <filename>/etc/cups/cupsd.conf</filename>:"
msgstr ""

msgid "\n"
"Listen 127.0.0.1:631"
msgstr ""

msgid "There are many other security options like allowing or denying networks and hosts in this config file. However, if you do not need them you might be better off just limiting the listening port. <command>Cups</command> also serves documentation through the HTTP port, if you do not want to disclose potential useful information to outside attackers (and the port is open) add also:"
msgstr ""

msgid ""
"\n"
"&lt;Location /&gt;\n"
" Order Deny,Allow\n"
" Deny From All\n"
" Allow From 127.0.0.1\n"
"&lt;/Location&gt;"
msgstr ""

msgid "This configuration file can be modified to add some more features including SSL/TLS certificates and crypto. The manuals are available at http://localhost:631/ or at <ulink url=\"http://cups.org\" />."
msgstr ""

msgid "FIXME: Add more content (the article on <ulink name=\"Amateur Fortress Building\" url=\"http://www.rootprompt.org\" /> provides some very interesting views)."
msgstr ""

msgid "FIXME: Check if PDG is available in Debian, and if so, suggest this as the preferred printing system."
msgstr ""

msgid "FIXME: Check if Farmer/Wietse has a replacement for printer daemon and if it's available in Debian."
msgstr ""

msgid "Securing the mail service"
msgstr ""

msgid "If your server is not a mailing system, you do not really need to have a mail daemon listening for incoming connections, but you might want local mail delivered in order, for example, to receive mail for the root user from any alert systems you have in place."
msgstr ""

msgid "If you have <command>exim</command> you do not need the daemon to be working in order to do this since the standard <command>cron</command> job flushes the mail queue. See <xref linkend=\"disableserv\" /> on how to do this."
msgstr ""

msgid "Configuring a Nullmailer"
msgstr ""

msgid "You might want to have a local mailer daemon so that it can relay the mails sent locally to another system. This is common when you have to administer a number of systems and do not want to connect to each of them to read the mail sent locally. Just as all logging of each individual system can be centralized by using a central syslog server, mail can be sent to a central mailserver."
msgstr ""

msgid "Such a <emphasis>relay-only</emphasis> system should be configured properly for this. The daemon could, as well, be configured to only listen on the loopback address."
msgstr ""

msgid "The following configuration steps only need to be taken to configure the <application>exim</application> package in the Debian 3.0 release. If you are using a later release (such as 3.1 which uses <application>exim4</application>) the installation system has been improved so that if the mail transport agent is configured to only deliver local mail it will automatically only allow connections from the local host and will not permit remote connections."
msgstr ""

msgid "In a Debian 3.0 system using <application>exim</application>, you will have to remove the SMTP daemon from <command>inetd</command>:"
msgstr ""

msgid "\n"
"$ update-inetd --disable smtp"
msgstr ""

msgid "and configure the mailer daemon to only listen on the loopback interface. In <command>exim</command> (the default MTA) you can do this by editing the file <filename>/etc/exim.conf</filename> and adding the following line:"
msgstr ""

msgid "\n"
"local_interfaces = \"127.0.0.1\""
msgstr ""

msgid "Restart both daemons (inetd and exim) and you will have exim listening on the 127.0.0.1:25 socket only. Be careful, and first disable inetd, otherwise, exim will not start since the inetd daemon is already handling incoming connections."
msgstr ""

msgid "For <command>postfix</command> edit <filename>/etc/postfix/main.conf</filename>:"
msgstr ""

msgid "\n"
"inet_interfaces = localhost"
msgstr ""

msgid "If you only want local mail, this approach is better than tcp-wrapping the mailer daemon or adding firewalling rules to limit anybody accessing it. However, if you do need it to listen on other interfaces, you might consider launching it from inetd and adding a tcp wrapper so incoming connections are checked against <filename>/etc/hosts.allow</filename> and <filename>/etc/hosts.deny</filename>. Also, you will be aware of when an unauthorized access is attempted against your mailer daemon, if you set up proper logging for any of the methods above."
msgstr ""

msgid "In any case, to reject mail relay attempts at the SMTP level, you can change <filename>/etc/exim/exim.conf</filename> to include:"
msgstr ""

msgid "\n"
"receiver_verify = true"
msgstr ""

msgid "Even if your mail server will not relay the message, this kind of configuration is needed for the relay tester at <ulink url=\"http://www.abuse.net/relay.html\" /> to determine that your server is <emphasis>not</emphasis> relay capable."
msgstr ""

msgid "If you want a relay-only setup, however, you can consider changing the mailer daemon to programs that can <emphasis>only</emphasis> be configured to forward the mail to a remote mail server. Debian provides currently both <application>ssmtp</application> and <application>nullmailer</application> for this purpose. In any case, you can evaluate for yourself any of the mail transport agents <footnote><para> To retrieve the list of mailer daemons available in Debian try: <screen> $ apt-cache search mail-transport-agent </screen> The list will not include <command>qmail</command>, which is distributed only as source code in the <application>qmail-src</application> package. </para></footnote> provided by Debian and see which one suits best to the system's purposes."
msgstr ""

msgid "Providing secure access to mailboxes"
msgstr ""

msgid "If you want to give remote access to mailboxes there are a number of POP3 and IMAP daemons available.<footnote><para> A list of servers/daemons which support these protocols in Debian can be retrieved with: <screen> $ apt-cache search pop3-server $ apt-cache search imap-server </screen></para></footnote> However, if you provide IMAP access note that it is a general file access protocol, it can become the equivalent of a shell access because users might be able to retrieve any file that they can through it."
msgstr ""

msgid "Try, for example, to configure as your inbox path <literal>{server.com}/etc/passwd</literal> if it succeeds your IMAP daemon is not properly configured to prevent this kind of access."
msgstr ""

msgid "Of the IMAP servers in Debian the <command>cyrus</command> server (in the <application>cyrus-imapd</application> package) gets around this by having all access to a database in a restricted part of the file system. Also, <command>uw-imapd</command> (either install the <application>uw-imapd</application> or better, if your IMAP clients support it, <application>uw-imapd-ssl</application>) can be configured to chroot the users mail directory but this is not enabled by default. The documentation provided gives more information on how to configure it."
msgstr ""

msgid "Also, you might want to run an IMAP server that does not need valid users to be created on the local system (which would grant shell access too), <application>courier-imap</application> (for IMAP) and <application>courier-pop</application>, <application>teapop</application> (for POP3) and <application>cyrus-imapd</application> (for both POP3 and IMAP) provide servers with authentication methods beside the local user accounts. <command>cyrus</command> can use any authentication method that can be configured through PAM while <command>teapop</command> might use databases (such as <application>postgresql</application> and <application>mysql</application>) for user authentication."
msgstr ""

msgid "FIXME: Check: <application>uw-imapd</application> might be configured with user authentication through PAM too."
msgstr ""

msgid "Receiving mail securely"
msgstr ""

msgid "Reading/receiving mail is the most common clear-text protocol. If you use either POP3 or IMAP to get your mail, you send your clear-text password across the net, so almost anyone can read your mail from now on. Instead, use SSL (Secure Sockets Layer) to receive your mail. The other alternative is SSH, if you have a shell account on the box which acts as your POP or IMAP server. Here is a basic <filename>fetchmailrc</filename> to demonstrate this:"
msgstr ""

msgid ""
"\n"
"poll my-imap-mailserver.org via \"localhost\"\n"
"  with proto IMAP port 1236\n"
"      user \"ref\" there with password \"hackme\" is alex here warnings 3600\n"
"    folders\n"
"      .Mail/debian\n"
"    preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref\n"
"     my-imap-mailserver.org sleep 15 &lt;/dev/null &gt; /dev/null'"
msgstr ""

msgid "The preconnect is the important line. It fires up an ssh session and creates the necessary tunnel, which automatically forwards connections to localhost port 1236 to the IMAP mail server, but encrypted. Another possibility would be to use <command>fetchmail</command> with the SSL feature."
msgstr ""

msgid "If you want to provide encrypted mail services like POP and IMAP, <literal>apt-get install stunnel</literal> and start your daemons this way:"
msgstr ""

msgid "\n"
"stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd"
msgstr ""

msgid "This command wraps the provided daemon (-l) to the port (-d) and uses the specified SSL certificate (-p)."
msgstr ""

msgid "Securing BIND"
msgstr ""

msgid "There are different issues that can be tackled in order to secure the Domain server daemon, which are similar to the ones considered when securing any given service:"
msgstr ""

msgid "configuring the daemon itself properly so it cannot be misused from the outside (see <xref linkend=\"configure-bind\" />). This includes limiting possible queries from clients: zone transfers and recursive queries."
msgstr ""

msgid "limit the access of the daemon to the server itself so if it is used to break in, the damage to the system is limited. This includes running the daemon as a non-privileged user (see <xref linkend=\"user-bind\" />) and chrooting it (see <xref linkend=\"chroot-bind\" />)."
msgstr ""

msgid "Bind configuration to avoid misuse"
msgstr ""

msgid "You should restrict some of the information that is served from the DNS server to outside clients so that it cannot be used to retrieve valuable information from your organization that you do not want to give away. This includes adding the following options: <emphasis>allow-transfer</emphasis>, <emphasis>allow-query</emphasis>, <emphasis>allow-recursion</emphasis> and <emphasis>version</emphasis>. You can either limit this on the global section (so it applies to all the zones served) or on a per-zone basis. This information is documented in the <application>bind-doc</application> package, read more on this on <filename>/usr/share/doc/bind/html/index.html</filename> once the package is installed."
msgstr ""

msgid "Imagine that your server is connected to the Internet and to your internal (your internal IP is 192.168.1.2) network (a basic multi-homed server), you do not want to give any service to the Internet and you just want to enable DNS lookups from your internal hosts. You could restrict it by including in <filename>/etc/bind/named.conf</filename>:"
msgstr ""

msgid ""
"\n"
"options {\n"
"            allow-query { 192.168.1/24; } ;\n"
"            allow-transfer { none; } ; \n"
"            allow-recursion { 192.168.1/24; } ;\n"
"            listen-on { 192.168.1.2; } ;\n"
"            forward { only; } ;\n"
"            forwarders { A.B.C.D; } ;\n"
"};"
msgstr ""

msgid "The <emphasis>listen-on</emphasis> option makes the DNS bind to only the interface that has the internal address, but, even if this interface is the same as the interface that connects to the Internet (if you are using NAT, for example), queries will only be accepted if coming from your internal hosts. If the system has multiple interfaces and the <emphasis>listen-on</emphasis> is not present, only internal users could query, but, since the port would be accessible to outside attackers, they could try to crash (or exploit buffer overflow attacks) on the DNS server. You could even make it listen only on 127.0.0.1 if you are not giving DNS service for any other systems than yourself."
msgstr ""

msgid "The version.bind record in the chaos class contains the version of the currently running bind process. This information is often used by automated scanners and malicious individuals who wish to determine if one's <command>bind</command> is vulnerable to a specific attack. By providing false or no information in the version.bind record, one limits the probability that one's server will be attacked based on its published version. To provide your own version, use the <emphasis>version</emphasis> directive in the following manner:"
msgstr ""

msgid " options { ... various options here ...\n"
"version \"Not available.\"; }; "
msgstr ""

msgid "Changing the version.bind record does not provide actual protection against attacks, but it might be considered a useful safeguard."
msgstr ""

msgid "A sample <filename>named.conf</filename> configuration file might be the following:"
msgstr ""

msgid ""
"\n"
"acl internal {\n"
"        127.0.0.1/32;           // localhost\n"
"        10.0.0.0/8;             // internal\n"
"        aa.bb.cc.dd;            // eth0 IP\n"
"};\n"
"\n"
"acl friendly {\n"
"        ee.ff.gg.hh;            // slave DNS\n"
"        aa.bb.cc.dd;            // eth0 IP\n"
"        127.0.0.1/32;           // localhost\n"
"        10.0.0.0/8;             // internal\n"
"};\n"
"\n"
"options {\n"
"        directory \"/var/cache/bind\";\n"
"        allow-query { internal; };\n"
"        allow-recursion { internal; };\n"
"        allow-transfer { none; };\n"
"};\n"
"// From here to the mysite.bogus zone \n"
"// is basically unmodified from the debian default\n"
"logging {\n"
"        category lame-servers { null; };\n"
"        category cname { null; };   \n"
"};\n"
"\n"
"zone \".\" {\n"
"        type hint;\n"
"        file \"/etc/bind/db.root\";\n"
"};\n"
"\n"
"zone \"localhost\" {\n"
"        type master;\n"
"        file \"/etc/bind/db.local\";\n"
"};\n"
"\n"
"zone \"127.in-addr.arpa\" {\n"
"        type master;\n"
"        file \"/etc/bind/db.127\";\n"
"};\n"
"\n"
"zone \"0.in-addr.arpa\" {\n"
"        type master;\n"
"        file \"/etc/bind/db.0\";\n"
"};\n"
"\n"
"zone \"255.in-addr.arpa\" {\n"
"        type master;\n"
"        file \"/etc/bind/db.255\";\n"
"};\n"
"\n"
"// zones I added myself\n"
"zone \"mysite.bogus\" {\n"
"        type master;\n"
"        file \"/etc/bind/named.mysite\";\n"
"        allow-query { any; };\n"
"        allow-transfer { friendly; };\n"
"};"
msgstr ""

msgid "Please (again) check the Bug Tracking System regarding Bind, specifically <ulink name=\"Bug #94760 (regarding ACLs on zone transfers)\" url=\"http://bugs.debian.org/94760\" />. Feel free to contribute to the bug report if you think you can add useful information."
msgstr ""

msgid "Changing BIND's user"
msgstr ""

msgid "Regarding limiting BIND's privileges you must be aware that if a non-root user runs BIND, then BIND cannot detect new interfaces automatically, for example when you put a PCMCIA card into your laptop. Check the <filename>README.Debian</filename> file in your named documentation (<filename>/usr/share/doc/bind/README.Debian</filename>) directory for more information about this issue. There have been many recent security problems concerning BIND, so switching the user is useful when possible. We will detail here the steps needed in order to do this, however, if you want to do this in an automatic way you might try the script provided in <xref linkend=\"bind-chuser\" />."
msgstr ""

msgid "Notice, in any case, that this only applies to BIND version 8. In the Debian packages for BIND version 9 (since the 9.2.1-5 version, available since <emphasis>sarge</emphasis>) the <emphasis>bind</emphasis> user is created and used by setting the OPTIONS variable in <filename>/etc/default/bind9</filename>. If you are using BIND version 9 and your name server daemon is not running as the <emphasis>bind</emphasis> user verify the settings on that file."
msgstr ""

msgid "To run BIND under a different user, first create a separate user and group for it (it is <emphasis>not</emphasis> a good idea to use nobody or nogroup for every service not running as root). In this example, the user and group <literal>named</literal> will be used. You can do this by entering:"
msgstr ""

msgid ""
"\n"
"addgroup named\n"
"adduser --system --home /home/named --no-create-home --ingroup named \\\n"
"      --disabled-password --disabled-login named"
msgstr ""

msgid "Notice that the user <literal>named</literal> will be quite restricted. If you want, for whatever reason, to have a less restrictive setup use:"
msgstr ""

msgid "\n"
"adduser --system --ingroup named named"
msgstr ""

msgid "Now you can either edit <filename>/etc/init.d/bind</filename> with your favorite editor and change the line beginning with"
msgstr ""

msgid "\n"
"start-stop-daemon --start"
msgstr ""

msgid "to<footnote><para>Note that depending on your bind version you might not have the <literal>-g</literal> option, most notably if you are using bind9 in sarge (9.2.4 version).</para></footnote>"
msgstr ""

msgid "\n"
"start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named"
msgstr ""

msgid "Or you can change (create it if it does not exit) the default configuration file (<filename>/etc/default/bind</filename> for BIND version 8) and introduce the following:"
msgstr ""

msgid "\n"
"OPTIONS=\"-u named -g named\""
msgstr ""

msgid "Change the permissions of files that are used by Bind, including <filename>/etc/bind/rndc.key</filename>:"
msgstr ""

msgid "\n"
"-rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key"
msgstr ""

msgid "and where bind creates its pidfile, using, for example, <filename>/var/run/named</filename> instead of <filename>/var/run</filename>:"
msgstr ""

msgid ""
"\n"
"$ mkdir /var/run/named\n"
"$ chown named.named /var/run/named\n"
"$ vi /etc/named.conf\n"
"[ ... update the configuration file to use this new location ...]\n"
"options { ...\n"
"        pid-file \"/var/run/named/named.pid\";\n"
"};\n"
"[ ... ]"
msgstr ""

msgid "Also, in order to avoid running anything as root, change the <literal>reload</literal> line in the init.d script by substituting:"
msgstr ""

msgid ""
"\n"
"reload)\n"
"       /usr/sbin/ndc reload"
msgstr ""

msgid "to:"
msgstr ""

msgid ""
"\n"
"reload)\n"
"        $0 stop\n"
"        sleep 1\n"
"        $0 start"
msgstr ""

msgid "Note: Depending on your Debian version you might have to change the <literal>restart</literal> line too. This was fixed in Debian's bind version <literal>1:8.3.1-2</literal>."
msgstr ""

msgid "All you need to do now is to restart bind via <literal>/etc/init.d/bind restart</literal>, and then check your syslog for two entries like this:"
msgstr ""

msgid ""
"\n"
"Sep  4 15:11:08 nexus named[13439]: group = named\n"
"Sep  4 15:11:08 nexus named[13439]: user = named"
msgstr ""

msgid "VoilĂ ! Your named now <emphasis>does not</emphasis> run as root. If you want to read more information on why BIND does not run as non-root user on Debian systems, please check the Bug Tracking System regarding Bind, specifically <ulink name=\"Bug #50013: bind should not run as root\" url=\"http://bugs.debian.org/50013\" /> and <ulink name=\"Bug #132582: Default install is potentially insecure\" url=\"http://bugs.debian.org/132582\" />, <ulink name=\"Bug #53550\" url=\"http://bugs.debian.org/53550\" />, <ulink name=\"Bug #52745\" url=\"http://bugs.debian.org/52745\" />, and <ulink name=\"Bug #128129\" url=\"http://bugs.debian.org/128129\" />. Feel free to contribute to the bug reports if you think you can add useful information."
msgstr ""

msgid "Chrooting the name server"
msgstr ""

msgid "To achieve maximum BIND security, now build a chroot jail (see <xref linkend=\"chroot\" />) around your daemon. There is an easy way to do this: the <literal>-t</literal> option (see the <citerefentry><refentrytitle>named</refentrytitle> <manvolnum>8</manvolnum></citerefentry> manual page or page 100 of <ulink name=\"Bind's 9 documentation (PDF)\" url=\"http://www.nominum.com/content/documents/bind9arm.pdf\" />). This will make Bind chroot itself into the given directory without you needing to set up a chroot jail and worry about dynamic libraries. The only files that need to be in the chroot jail are:"
msgstr ""

msgid ""
"\n"
"dev/null\n"
"etc/bind/       - should hold named.conf and all the server zones\n"
"sbin/named-xfer - if you do name transfers\n"
"var/run/named/  - should hold the PID and the name server cache (if\n"
"                  any) this directory needs to be writable by named user\n"
"var/log/named   - if you set up logging to a file, needs to be writable\n"
"                  for the named user\n"
"dev/log         - syslogd should be listening here if named is configured to\n"
"                  log through it"
msgstr ""

msgid "In order for your Bind daemon to work properly it needs permission in the named files. This is an easy task since the configuration files are always at <literal>/etc/named/</literal>. Take into account that it only needs read-only access to the zone files, unless it is a secondary or cache name server. If this is your case you will have to give read-write permissions to the necessary zones (so that zone transfers from the primary server work)."
msgstr ""

msgid "Also, you can find more information regarding Bind chrooting in the <ulink name=\"Chroot-BIND-HOWTO\" url=\"http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html\" /> (regarding Bind 9) and <ulink name=\"Chroot-BIND8-HOWTO\" url=\"http://www.tldp.org/HOWTO/Chroot-BIND8-HOWTO.html\" /> (regarding Bind 8). This same documents should be available through the installation of the <application>doc-linux-text</application> (text version) or <application>doc-linux-html</application> (HTML version). Another useful document is <ulink url=\"http://web.archive.org/web/20011024064030/http://www.psionic.com/papers/dns/dns-linux\" />."
msgstr ""

msgid "If you are setting up a full chroot jail (i.e. not just <literal>-t</literal>) for Bind in Debian, make sure you have the following files in it<footnote><para>This setup has not been tested for new release of Bind yet.</para></footnote>:"
msgstr ""

msgid ""
"\n"
"dev/log - syslogd should be listening here\n"
"dev/null\n"
"etc/bind/named.conf \n"
"etc/localtime\n"
"etc/group - with only a single line: \"named:x:GID:\"\n"
"etc/ld.so.cache - generated with ldconfig \n"
"lib/ld-2.3.6.so\n"
"lib/libc-2.3.6.so\n"
"lib/ld-linux.so.2 - symlinked to ld-2.3.6.so\n"
"lib/libc.so.6 - symlinked to libc-2.3.6.so\n"
"sbin/ldconfig - may be deleted after setting up the chroot\n"
"sbin/named-xfer - if you do name transfers\n"
"var/run/"
msgstr ""

msgid "And modify also <command>syslogd</command> listen on <literal>$CHROOT/dev/log</literal> so the named server can write syslog entries into the local system log."
msgstr ""

msgid "If you want to avoid problems with dynamic libraries, you can compile bind statically. You can use <command>apt-get</command> for this, with the <literal>source</literal> option. It can even download the packages you need to properly compile it. You would need to do something similar to:"
msgstr ""

msgid ""
"\n"
"$ apt-get source bind\n"
"# apt-get build-dep bind\n"
"$ cd bind-8.2.5-2\n"
"  (edit src/port/linux/Makefile so CFLAGS includes the '-static'\n"
"   option)\n"
"$ dpkg-buildpackage -rfakeroot -uc -us\n"
"$ cd ..\n"
"# dpkg -i bind-8.2.5-2*deb"
msgstr ""

msgid "After installation, you will need to move around the files to the chroot jail<footnote><para>Unless you use the <literal>instdir</literal> option when calling <command>dpkg</command> but then the chroot jail might be a little more complex.</para></footnote> you can keep the <literal>init.d</literal> scripts in <filename>/etc/init.d</filename> so that the system will automatically start the name server, but edit them to add <literal>--chroot /location_of_chroot</literal> in the calls to <command>start-stop-daemon</command> in those scripts or use the <emphasis>-t</emphasis> option for BIND by setting it in the OPTIONS argument at the <filename>/etc/default/bind</filename> (for version 8) or <filename>/etc/default/bind9</filename> (for version 9) configuration file."
msgstr ""

msgid "For more information on how to set up chroots see <xref linkend=\"chroot\" />."
msgstr ""

msgid "FIXME: Merge info from <ulink url=\"http://people.debian.org/~pzn/howto/chroot-bind.sh.txt\" />, <ulink url=\"http://www.cryptio.net/~ferlatte/config/\" /> (Debian-specific), <ulink url=\"http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html\" /> and <ulink url=\"http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm\" />."
msgstr ""

msgid "Securing Apache"
msgstr ""

msgid "FIXME: Add content: modules provided with the normal Apache installation (under /usr/lib/apache/X.X/mod_*) and modules that can be installed separately in libapache-mod-XXX packages."
msgstr ""

msgid "You can limit access to the Apache server if you only want to use it internally (for testing purposes, to access the <application>doc-central</application> archive, etc.) and do not want outsiders to access it. To do this use the <literal>Listen</literal> or <literal>BindAddress</literal> directives in <filename>/etc/apache/http.conf</filename>."
msgstr ""

msgid "Using Listen:"
msgstr ""

msgid "\n"
"Listen 127.0.0.1:80"
msgstr ""

msgid "Using BindAddress:"
msgstr ""

msgid "\n"
"BindAddress 127.0.0.1"
msgstr ""

msgid "Then restart apache with <literal>/etc/init.d/apache restart</literal> and you will see that it is only listening on the loopback interface."
msgstr ""

msgid "In any case, if you are not using all the functionality provided by Apache, you might want to take a look at other web servers provided in Debian like <application>dhttpd</application>."
msgstr ""

msgid "The <ulink name=\"Apache Documentation\" url=\"http://httpd.apache.org/docs/misc/security_tips.html\" /> provides information regarding security measures to be taken on Apache web server (this same information is provided in Debian by the <application>apache-doc</application> package)."
msgstr ""

msgid "More information on further restricting Apache by setting up a chroot jail is provided in <xref linkend=\"chroot-apache-env\" />."
msgstr ""

msgid "Disabling users from publishing web contents"
msgstr ""

msgid "The default Apache installation in Debian permits users to publish content under the <filename>$HOME/public_html</filename>. This content can be retrieved remotely using an URL such as: http://your_apache_server/~user."
msgstr ""

msgid "If you do not want to permit this you must change the <filename>/etc/apache/http.conf</filename> configuration file commenting out (in Apache 1.3) the following module:"
msgstr ""

msgid "\n"
"LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so"
msgstr ""

msgid "If you are using Apache 2.0 you must remove the file <filename>/etc/apache2/mods-enabled/userdir.load</filename> or restrict the default configuration by modifying <filename>/etc/apache2/mods-enabled/userdir.conf</filename>."
msgstr ""

msgid "However, if the module was linked statically (you can list the modules that are compiled in running <literal>apache -l</literal>) you must add the following to the Apache configuration file:"
msgstr ""

msgid "\n"
"Userdir disabled"
msgstr ""

msgid "An attacker might still do user enumeration, since the answer of the web server will be a <emphasis>403 Permission Denied</emphasis> and not a <emphasis>404 Not available</emphasis>. You can avoid this if you use the Rewrite module."
msgstr ""

msgid "Logfiles permissions"
msgstr ""

msgid "Apache logfiles, since 1.3.22-1, are owned by user 'root' and group 'adm' with permissions 640. These permissions are changed after rotation. An intruder that accessed the system through the web server would not be able (without privilege escalation) to remove old log file entries."
msgstr ""

msgid "Published web files"
msgstr ""

msgid "Apache files are located under <filename>/var/www</filename>. Just after installation the default file provides some information on the system (mainly that it's a Debian system running Apache). The default webpages are owned by user root and group root by default, while the Apache process runs as user www-data and group www-data. This should make attackers that compromise the system through the web server harder to deface the site. You should, of course, substitute the default web pages (which might provide information you do not want to show to outsiders) with your own."
msgstr ""

msgid "Securing finger"
msgstr ""

msgid "If you want to run the finger service first ask yourself if you need to do so. If you do, you will find out that Debian provides many finger daemons (output from <command>apt-cache search fingerd</command>):"
msgstr ""

msgid "cfingerd - Configurable finger daemon"
msgstr ""

msgid "efingerd - Another finger daemon for unix, capable of fine-tuning your output."
msgstr ""

msgid "ffingerd - a secure finger daemon"
msgstr ""

msgid "fingerd - Remote user information server."
msgstr ""

msgid "xfingerd - BSD-like finger daemon with qmail support."
msgstr ""

msgid "<application>ffingerd</application> is the recommended finger daemon if you are going to use it for a public service. In any case, you are encouraged to, when setting it up through inetd, xinetd or tcpserver to: limit the number of processes that will be running at the same time, limit access to the finger daemon from a given number of hosts (using tcp wrappers) and having it only listening to the interface you need it to be in."
msgstr ""

msgid "General chroot and suid paranoia"
msgstr ""

msgid "<command>chroot</command> is one of the most powerful possibilities to restrict a daemon or a user or another service. Just imagine a jail around your target, which the target cannot escape from (normally, but there are still a lot of conditions that allow one to escape out of such a jail). You can eventually create a modified root environment for the user or service you do not trust. This can use quite a bit of disk space as you need to copy all needed executables, as well as libraries, into the jail. But then, even if the user does something malicious, the scope of the damage is limited to the jail."
msgstr ""

msgid "Many services running as daemons could benefit from this sort of arrangement. The daemons that you install with your Debian distribution will not come, however, chrooted<footnote><para>It does try to run them under <emphasis>minimum priviledge</emphasis> which includes running daemons with their own users instead of having them run as root. </para></footnote> per default."
msgstr ""

msgid "This includes: name servers (such as <command>bind</command>), web servers (such as <command>apache</command>), mail servers (such as <command>sendmail</command>) and ftp servers (such as <command>wu-ftpd</command>). It is probably fair to say that the complexity of BIND is the reason why it has been exposed to a lot of attacks in recent years (see <xref linkend=\"sec-bind\" />)."
msgstr ""

msgid "However, Debian does provide some software that can help set up <command>chroot</command> environments. See <xref linkend=\"auto-chroot\" />."
msgstr ""

msgid "Anyway, if you run any service on your system, you should consider running them as secure as possible. This includes: revoking root privileges, running in a restricted environment (such as a chroot jail) or replacing them with a more secure equivalent."
msgstr ""

msgid "However, be forewarned that a <command>chroot</command> jail can be broken if the user running in it is the superuser. So, you need to make the service run as a non-privileged user. By limiting its environment you are limiting the world readable/executable files the service can access, thus, you limit the possibilities of a privilege escalation by use of local system security vulnerabilities. Even in this situation you cannot be completely sure that there is no way for a clever attacker to somehow break out of the jail. Using only server programs which have a reputation for being secure is a good additional safety measure. Even minuscule holes like open file handles can be used by a skilled attacker for breaking into the system. After all, <command>chroot</command> was not designed as a security tool but as a testing tool."
msgstr ""

msgid "Making chrooted environments automatically"
msgstr ""

msgid "There are several programs to chroot automatically servers and services. Debian currently (accepted in May 2002) provides Wietse Venema's <command>chrootuid</command> in the <application>chrootuid</application> package, as well as <application>compartment</application> and <application>makejail</application>. These programs can be used to set up a restricted environment for executing any program (<command>chrootuid</command> enables you to even run it as a restricted user)."
msgstr ""

msgid "Some of these tools can be used to set up the chroot environment easily. The <command>makejail</command> program for example, can create and update a chroot jail with short configuration files (it provides sample configuration files for <command>bind</command>, <command>apache</command>, <command>postgresql</command> and <command>mysql</command>). It attempts to guess and install into the jail all files required by the daemon using <command>strace</command>, <command>stat</command> and Debian's package dependencies. More information at <ulink url=\"http://www.floc.net/makejail/\" />. <command>Jailer</command> is a similar tool which can be retrieved from <ulink url=\"http://www.balabit.hu/downloads/jailer/\" /> and is also available as a Debian package."
msgstr ""

msgid "General cleartext password paranoia"
msgstr ""

msgid "You should try to avoid any network service which sends and receives passwords in cleartext over a net like FTP/Telnet/NIS/RPC. The author recommends the use of ssh instead of telnet and ftp to everybody."
msgstr ""

msgid "Keep in mind that migrating from telnet to ssh, but using other cleartext protocols does not increase your security in ANY way! Best would be to remove ftp, telnet, pop, imap, http and to supersede them with their respective encrypted services. You should consider moving from these services to their SSL versions, ftp-ssl, telnet-ssl, pop-ssl, https ..."
msgstr ""

msgid "Most of these above listed hints apply to every Unix system (you will find them if reading any other hardening-related document related to Linux and other Unices)."
msgstr ""

msgid "Disabling NIS"
msgstr ""

msgid "You should not use NIS, the Network Information Service, if possible, because it allows password sharing. This can be highly insecure if your setup is broken."
msgstr ""

msgid "If you need password sharing between machines, you might want to consider using other alternatives. For example, you can setup an LDAP server and configure PAM on your system in order to contact the LDAP server for user authentication. You can find a detailed setup in the <ulink name=\"LDAP-HOWTO\" url=\"http://www.tldp.org/HOWTO/LDAP-HOWTO.html\" /> (<filename>/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz</filename>)."
msgstr ""

msgid "You can read more about NIS security in the <ulink name=\"NIS-HOWTO\" url=\"http://www.tldp.org/HOWTO/NIS-HOWTO.html\" /> (<filename>/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz</filename>)."
msgstr ""

msgid "FIXME (jfs): Add info on how to set this up in Debian."
msgstr ""

msgid "Securing RPC services"
msgstr ""

msgid "You should disable RPC if you do not need it."
msgstr ""

msgid "Remote Procedure Call (RPC) is a protocol that programs can use to request services from other programs located on different computers. The <command>portmap</command> service controls RPC services by mapping RPC program numbers into DARPA protocol port numbers; it must be running in order to make RPC calls."
msgstr ""

msgid "RPC-based services have had a bad record of security holes, although the portmapper itself hasn't (but still provides information to a remote attacker). Notice that some of the DDoS (distributed denial of service) attacks use RPC exploits to get into the system and act as a so called agent/handler."
msgstr ""

msgid "You only need RPC if you are using an RPC-based service. The most common RPC-based services are NFS (Network File System) and NIS (Network Information System). See the previous section for more information about NIS. The File Alteration Monitor (FAM) provided by the package <application>fam</application> is also an RPC service, and thus depends on <application>portmap</application>."
msgstr ""

msgid "NFS services are quite important in some networks. If that is the case for you, then you will need to find a balance of security and usability for your network (you can read more about NFS security in the <ulink name=\"NFS-HOWTO\" url=\"http://www.tldp.org/HOWTO/NFS-HOWTO.html\" /> (<filename>/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz</filename>))."
msgstr ""

msgid "Disabling RPC services completely"
msgstr ""

msgid "Disabling portmap is quite simple. There are several different methods. The simplest one in a Debian 3.0 system and later releases is to uninstall the <application>portmap</application> package. If you are running an older Debian version you will have to disable the service as seen in <xref linkend=\"disableserv\" />, because the program is part of the <application>netbase</application> package (which cannot be de-installed without breaking the system)."
msgstr ""

msgid "Notice that some desktop environments (notably, GNOME) use RPC services and need the portmapper for some of the file management features. If this is your case, you can limit the access to RPC services as described below."
msgstr ""

msgid "Limiting access to RPC services"
msgstr ""

msgid "Unfortunately, in some cases removing RPC services from the system is not an option. Some local desktop services (notably SGI's <application>fam</application>) are RPC based and thus need a local portmapper. This means that under some situations, users installing a desktop environment (like GNOME) will install the portmapper too."
msgstr ""

msgid "There are several ways to limit access to the portmapper and to RPC services:"
msgstr ""

msgid "Block access to the ports used by these services with a local firewall (see <xref linkend=\"firewall-setup\" />)."
msgstr ""

msgid "Block access to these services using tcp wrappers, since the portmapper (and some RPC services) are compiled with <filename>libwrap</filename> (see <xref linkend=\"tcpwrappers\" />). This means that you can block access to them through the <filename>hosts.allow</filename> and <filename>hosts.deny</filename> tcp wrappers configuration."
msgstr ""

msgid "Since version 5-5, the <application>portmap</application> package can be configured to listen only on the loopback interface. To do this, modify <filename>/etc/default/portmap</filename>, uncomment the following line: <literal>#OPTIONS=\"-i 127.0.0.1\"</literal> and restart the portmapper. This is sufficient to allow local RPC services to work while at the same time prevents remote systems from accessing them (see, however, <xref linkend=\"limit-bindaddr\" />)."
msgstr ""

msgid "Adding firewall capabilities"
msgstr ""

msgid "The Debian GNU/Linux operating system has the built-in capabilities provided by the Linux kernel. If you install a recent Debian release (default kernel installed is 2.6) you will have <command>iptables</command> (netfilter) firewalling available<footnote><para> Available since the kernel version 2.4 (which was the default kernel in Debian 3.0). Previous kernel versions (2.2, available in even older Debian releases) used <command>ipchains</command>. The main difference between <command>ipchains</command> and <command>iptables</command> is that the latter is based on <emphasis>stateful packet inspection</emphasis> which provides for more secure (and easier to build) filtering configurations. Older (and now unsupported) Debian distributions using the 2.0 kernel series needed the appropriate kernel patch.</para></footnote>."
msgstr ""

msgid "Firewalling the local system"
msgstr ""

msgid "You can use firewall rules as a way to secure the access to your local system and, even, to limit the outbound communications made by it. Firewall rules can also be used to protect processes that cannot be properly configured <emphasis>not</emphasis> to provide services to some networks, IP addresses, etc."
msgstr ""

msgid "However, this step is presented last in this manual basically because it is <emphasis>much</emphasis> better not to depend solely on firewalling capabilities in order to protect a given system. Security in a system is made up of layers, firewalling should be the last to include, once all services have been hardened. You can easily imagine a setup in which the system is solely protected by a built-in firewall and an administrator blissfully removes the firewall rules for whatever reason (problems with the setup, annoyance, human error...), this system would be wide open to an attack if there were no other hardening in the system to protect from it."
msgstr ""

msgid "On the other hand, having firewall rules on the local system also prevents some bad things from happening. Even if the services provided are configured securely, a firewall can protect from misconfigurations or from fresh installed services that have not yet been properly configured. Also, a tight configuration will prevent trojans <emphasis>calling home</emphasis> from working unless the firewalling code is removed. Note that an intruder does <emphasis>not</emphasis> need superuser access to install a trojan locally that could be remotely controlled (since binding on ports is allowed if they are not priviledged ports and capabilities have not been removed)."
msgstr ""

msgid "Thus, a proper firewall setup would be one with a default deny policy, that is:"
msgstr ""

msgid "incoming connections are allowed only to local services by allowed machines."
msgstr ""

msgid "outgoing connections are only allowed to services used by your system (DNS, web browsing, POP, email...).<footnote><para> Unlike personal firewalls in other operating systems, Debian GNU/Linux does not (yet) provide firewall generation interfaces that can make rules limiting them per process or user. However, the iptables code can be configured to do this (see the owner module in the <citerefentry><refentrytitle>iptables</refentrytitle> <manvolnum>8</manvolnum></citerefentry> manual page).</para></footnote>"
msgstr ""

msgid "the forward rule denies everything (unless you are protecting other systems, see below)."
msgstr ""

msgid "all other incoming or outgoing connections are denied."
msgstr ""

msgid "Using a firewall to protect other systems"
msgstr ""

msgid "A Debian firewall can also be installed in order to protect, with filtering rules, access to systems <emphasis>behind</emphasis> it, limiting their exposure to the Internet. A firewall can be configured to prevent access from systems outside of the local network to internal services (ports) that are not public. For example, on a mail server, only port 25 (where the mail service is being given) needs to be accessible from the outside. A firewall can be configured to, even if there are other network services besides the public ones running in the mail server, throw away packets (this is known as <emphasis>filtering</emphasis>) directed towards them."
msgstr ""

msgid "You can even set up a Debian GNU/Linux box as a bridge firewall, i.e. a filtering firewall completely transparent to the network that lacks an IP address and thus cannot be attacked directly. Depending on the kernel you have installed, you might need to install the bridge firewall patch and then go to <emphasis>802.1d Ethernet Bridging</emphasis> when configuring the kernel and a new option <emphasis>netfilter ( firewalling ) support</emphasis>. See the <xref linkend=\"bridge-fw\" /> for more information on how to set this up in a Debian GNU/Linux system."
msgstr ""

msgid "Setting up a firewall"
msgstr ""

msgid "The default Debian installation, unlike other Linux distributions, does not yet provide a way for the administrator to setup a firewall configuration throughout the default installation but you can install a number of firewall configuration packages (see <xref linkend=\"firewall-pack\" />)."
msgstr ""

msgid "Of course, the configuration of the firewall is always system and network dependant. An administrator must know beforehand what is the network layout and the systems to protect, the services that need to be accessed, and whether or not other network considerations (like NAT or routing) need to be taken into account. Be careful when configuring your firewall, as Laurence J. Lane says in the <application>iptables</application> package:"
msgstr ""

msgid "<emphasis>The tools can easily be misused, causing enormous amounts of grief by completely crippling network access to a system. It is not terribly uncommon for a remote system administrator to accidentally get locked out of a system hundreds or thousands of miles away. You can even manage to get locked out of a computer who's keyboard is under your own fingers. Please, use due caution.</emphasis>"
msgstr ""

msgid "Remember this: just installing the <application>iptables</application> (or the older firewalling code) does not give you any protection, just provides the software. In order to have a firewall you need to <emphasis>configure</emphasis> it!"
msgstr ""

msgid "If you do not have a clue on how to set up your firewall rules manually consult the <emphasis>Packet Filtering HOWTO</emphasis> and <emphasis>NAT HOWTO</emphasis> provided by <application>iptables</application> for offline reading at <filename>/usr/share/doc/iptables/html/</filename>."
msgstr ""

msgid "If you do not know much about firewalling you should start by reading the <ulink name=\"Firewalling and Proxy Server HOWTO\" url=\"http://www.tldp.org/HOWTO/Firewall-HOWTO.html\" />, install the <application>doc-linux-text</application> package if you want to read it offline. If you want to ask questions or need help setting up a firewall you can use the debian-firewall mailing list, see <ulink url=\"http://lists.debian.org/debian-firewall\" />. Also see <xref linkend=\"references\" /> for more (general) pointers on firewalls. Another good iptables tutorial is <ulink url=\"http://iptables-tutorial.frozentux.net/iptables-tutorial.html\" />."
msgstr ""

msgid "Using firewall packages"
msgstr ""

msgid "Setting up manually a firewall can be complicated for novice (and sometimes even expert) administrators. However, the free software community has created a number of tools that can be used to easily configure a local firewall. Be forewarned that some of these tools are oriented more towards local-only protection (also known as <emphasis>personal firewall</emphasis>) and some are more versatile and can be used to configure complex rules to protect whole networks."
msgstr ""

msgid "Some software that can be used to set up firewall rules in a Debian system is:"
msgstr ""

msgid "For desktop systems:"
msgstr ""

msgid "<application>firestarter</application>, a GNOME application oriented towards end-users that includes a wizard useful to quickly setup firewall rules. The application includes a GUI to be able to monitor when a firewall rule blocks traffic."
msgstr ""

msgid "<application>guarddog</application>, a KDE based firewall configuration package oriented both to novice and advanced users."
msgstr ""

msgid "<application>knetfilter</application>, a KDE GUI to manage firewall and NAT rules for iptables (alternative/competitor to the guarddog tool although slightly oriented towards advanced users)."
msgstr ""

msgid "fireflier, an interactive tool to create iptables rules based on traffic seen on the system and applications. It has a server-client model so you have to install both the server (<application>fireflier-server</application>) and one of the available clients, with one client available for different desktop environments: <application>fireflier-client-gtk</application> (Gtk+ client), <application>fireflier-client-kde</application> (KDE client) and <application>fireflier-client-qt</application> (QT client)."
msgstr ""

msgid "For servers (headless) systems:"
msgstr ""

msgid "<application>fwbuilder</application>, an object oriented GUI which includes policy compilers for various firewall platforms including Linux' netfilter, BSD's pf (used in OpenBSD, NetBSD, FreeBSD and MacOS X) as well as router's access-lists. It is similar to enterprise firewall management software. Complete fwbuilder's functionality is also available from the command line."
msgstr ""

msgid "<application>shorewall</application>, a firewall configuration tool which provides support for IPsec as well as limited support for traffic shaping as well as the definition of the firewall rules. Configuration is done through a simple set of files that are used to generate the iptables rules."
msgstr ""

msgid "<application>bastille</application>, this hardening application is described in <xref linkend=\"automatic-harden\" />. One of the hardening steps that the administrator can configure is a definition of the allowed and disallowed network traffic that is used to generate a set of firewall rules that the system will execute on startup."
msgstr ""

msgid "Lots of other iptables frontends come with Debian; an extensive list comparing the different packages in Debian is maintained at the <ulink name=\"Firewalls page on the Debian wiki\" url=\"http://wiki.debian.org/Firewalls\" />."
msgstr ""

msgid "Notice that some of the packages outlined previously will introduce firewalling scripts to be run when the system boots. Test them extensively before rebooting or you might find yourself locked from the box. If you mix different firewalling packages you can have undesired effects, usually, the firewalling script that runs last will be the one that configures the system (which might not be what you intend). Consult the package documentation and use either one of these setups."
msgstr ""

msgid "As mentioned before, some programs, like <application>firestarter</application>, <application>guarddog</application> and <application>knetfilter</application>, are administration GUIs using either GNOME or KDE (last two). These applications are much more user-oriented (i.e. for home users) than some of the other packages in the list which might be more administrator-oriented. Some of the programs mentioned before (like <command>bastille</command>) are focused at setting up firewall rules to protect the host they run in but are not necessarily designed to setup firewall rules for firewall hosts that protect a network (like <command>shorewall</command> or <command>fwbuilder</command>)."
msgstr ""

msgid "There is yet another type of firewall application: application proxies. If you are looking into setting up an enterprise-level firewall that does packet filtering and provides a number of transparent proxies that can do fine-grain traffic analysis you should consider using <application>zorp</application>, which provides this in a single program. You can also manually setup this type of firewall host using the proxies available in Debian for different services like for DNS using <application>bind</application> (properly configured), <application>dnsmasq</application>, <application>pdnsd</application> or <application>totd</application> for FTP using <application>frox</application> or <application>ftp-proxy</application>, for X11 using <application>xfwp</application>, for IMAP using <application>imapproxy</application>, for mail using <application>smtpd</application>, or for POP3 using <application>p3scan</application>. For other protocols you can either use a generic TCP proxy like <application>simpleproxy</application> or a generic SOCKS proxy like <application>dante-server</application>, <application>tsocks</application> or <application>socks4-server</application>. Typically, you will also use a web caching system (like <application>squid</application>) and a web filtering system (like <application>squidguard</application> or <application>dansguardian</application>)."
msgstr ""

msgid "Manual init.d configuration"
msgstr ""

msgid "Another possibility is to manually configure your firewall rules through an init.d script that will run all the <command>iptables</command> commands. Take the following steps:"
msgstr ""

msgid "Review the script below and adapt it to your needs."
msgstr ""

msgid "Test the script and review the syslog messages to see which traffic is being dropped. If you are testing from the network you will want to either run the sample shell snippet to remove the firewall (if you don't type anything in 20 seconds) or you might want to comment out the <emphasis>default deny</emphasis> policy definitions (<emphasis>-P INPUT DROP</emphasis> and <emphasis>-P OUTPUT DROP</emphasis>) and check that the system will not drop any legitimate traffic."
msgstr ""

msgid "Move the script to <filename>/etc/init.d/myfirewall</filename>"
msgstr ""

msgid "The below script takes advantage of Debian's use (since Squeeze) of dependency based boot sequencing. For more information see: <ulink name=\"Debian Dependency Based Boot\" url=\"https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot\" /> and <ulink name=\"How to write an LSB Init Script\" url=\"https://wiki.debian.org/LSBInitScripts\" />. With the LSB headers set as they are in the script, insserv will automatically configure the system to start the firewall before any network is brought up, and stop the firewall after any network is brought down."
msgstr ""

msgid "\n"
"# insserv myfirewall"
msgstr ""

msgid "This is the sample firewall script:"
msgstr ""

msgid ""
"\n"
"#!/bin/sh\n"
"### BEGIN INIT INFO\n"
"# Provides:          myfirewall\n"
"# Required-Start:    $local_fs\n"
"# Required-Stop:     $local_fs\n"
"# Default-Start:     S\n"
"# Default-Stop:      0 6\n"
"# X-Start-Before:    $network\n"
"# X-Stop-After:      $network\n"
"# Short-Description: My custom firewall.\n"
"### END INIT INFO\n"
"#\n"
"# Simple example firewall configuration.\n"
"#\n"
"# Caveats:\n"
"# - This configuration applies to all network interfaces\n"
"#   if you want to restrict this to only a given interface use\n"
"#   '-i INTERFACE' in the iptables calls.\n"
"# - Remote access for TCP/UDP services is granted to any host, \n"
"#   you probably will want to restrict this using '--source'.\n"
"#\n"
"# chkconfig: 2345 9 91\n"
"# description: Activates/Deactivates the firewall at boot time\n"
"#\n"
"# You can test this script before applying with the following shell\n"
"# snippet, if you do not type anything in 10 seconds the firewall\n"
"# rules will be cleared.\n"
"#---------------------------------------------------------------\n"
"#  while true; do test=\"\"; read  -t 20 -p \"OK? \" test ; \\\n"
"#  [ -z \"$test\" ] &amp;&amp; /etc/init.d/myfirewall clear ; done\n"
"#---------------------------------------------------------------\n"
"\n"
"PATH=/bin:/sbin:/usr/bin:/usr/sbin\n"
"\n"
"# Services that the system will offer to the network\n"
"TCP_SERVICES=\"22\" # SSH only\n"
"UDP_SERVICES=\"\"\n"
"# Services the system will use from the network\n"
"REMOTE_TCP_SERVICES=\"80\" # web browsing\n"
"REMOTE_UDP_SERVICES=\"53\" # DNS\n"
"# Network that will be used for remote mgmt\n"
"# (if undefined, no rules will be setup)\n"
"# NETWORK_MGMT=192.168.0.0/24\n"
"# If you want to setup a management network (i.e. you've uncommented\n"
"# the above line) you will need to define the SSH port as well (i.e.\n"
"# uncomment the below line.) Remember to remove the SSH port from the\n"
"# TCP_SERVICES string.\n"
"# SSH_PORT=\"22\"\n"
"\n"
"if ! [ -x /sbin/iptables ]; then  \n"
"    exit 0\n"
"fi\n"
"\n"
"fw_start () {\n"
"\n"
"  # Input traffic:\n"
"  /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT\n"
"  # Services\n"
"  if [ -n \"$TCP_SERVICES\" ] ; then\n"
"  for PORT in $TCP_SERVICES; do\n"
"    /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT\n"
"  done\n"
"  fi\n"
"  if [ -n \"$UDP_SERVICES\" ] ; then\n"
"  for PORT in $UDP_SERVICES; do\n"
"    /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT\n"
"  done\n"
"  fi\n"
"  # Remote management\n"
"  if [ -n \"$NETWORK_MGMT\" ] ; then\n"
"    /sbin/iptables -A INPUT -p tcp --src ${NETWORK_MGMT} --dport ${SSH_PORT} -j ACCEPT\n"
"  fi\n"
"  # Remote testing\n"
"  /sbin/iptables -A INPUT -p icmp -j ACCEPT\n"
"  /sbin/iptables -A INPUT -i lo -j ACCEPT\n"
"  /sbin/iptables -P INPUT DROP\n"
"  /sbin/iptables -A INPUT -j LOG\n"
"\n"
"  # Output:\n"
"  /sbin/iptables -A OUTPUT -j ACCEPT -o lo \n"
"  /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT\n"
"  # ICMP is permitted:\n"
"  /sbin/iptables -A OUTPUT -p icmp -j ACCEPT\n"
"  # So are security package updates:\n"
"  # Note: You can hardcode the IP address here to prevent DNS spoofing\n"
"  # and to setup the rules even if DNS does not work but then you \n"
"  # will not \"see\" IP changes for this service:\n"
"  /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT \n"
"  # As well as the services we have defined:\n"
"  if [ -n \"$REMOTE_TCP_SERVICES\" ] ; then\n"
"  for PORT in $REMOTE_TCP_SERVICES; do\n"
"    /sbin/iptables -A OUTPUT -p tcp --dport ${PORT} -j ACCEPT\n"
"  done\n"
"  fi\n"
"  if [ -n \"$REMOTE_UDP_SERVICES\" ] ; then\n"
"  for PORT in $REMOTE_UDP_SERVICES; do\n"
"    /sbin/iptables -A OUTPUT -p udp --dport ${PORT} -j ACCEPT\n"
"  done\n"
"  fi\n"
"  # All other connections are registered in syslog\n"
"  /sbin/iptables -A OUTPUT -j LOG\n"
"  /sbin/iptables -A OUTPUT -j REJECT \n"
"  /sbin/iptables -P OUTPUT DROP\n"
"  # Other network protections\n"
"  # (some will only work with some kernel versions)\n"
"  echo 1 &gt; /proc/sys/net/ipv4/tcp_syncookies\n"
"  echo 0 &gt; /proc/sys/net/ipv4/ip_forward \n"
"  echo 1 &gt; /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts \n"
"  echo 1 &gt; /proc/sys/net/ipv4/conf/all/log_martians \n"
"  echo 1 &gt; /proc/sys/net/ipv4/ip_always_defrag\n"
"  echo 1 &gt; /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses\n"
"  echo 1 &gt; /proc/sys/net/ipv4/conf/all/rp_filter\n"
"  echo 0 &gt; /proc/sys/net/ipv4/conf/all/send_redirects\n"
"  echo 0 &gt; /proc/sys/net/ipv4/conf/all/accept_source_route\n"
"\n"
"}\n"
"\n"
"fw_stop () {\n"
"  /sbin/iptables -F\n"
"  /sbin/iptables -t nat -F\n"
"  /sbin/iptables -t mangle -F\n"
"  /sbin/iptables -P INPUT DROP\n"
"  /sbin/iptables -P FORWARD DROP\n"
"  /sbin/iptables -P OUTPUT ACCEPT\n"
"}\n"
"\n"
"fw_clear () {\n"
"  /sbin/iptables -F\n"
"  /sbin/iptables -t nat -F\n"
"  /sbin/iptables -t mangle -F\n"
"  /sbin/iptables -P INPUT ACCEPT\n"
"  /sbin/iptables -P FORWARD ACCEPT\n"
"  /sbin/iptables -P OUTPUT ACCEPT\n"
"}\n"
"\n"
"\n"
"case \"$1\" in\n"
"  start|restart)\n"
"    echo -n \"Starting firewall..\"\n"
"    fw_stop \n"
"    fw_start\n"
"    echo \"done.\"\n"
"    ;;\n"
"  stop)\n"
"    echo -n \"Stopping firewall..\"\n"
"    fw_stop\n"
"    echo \"done.\"\n"
"    ;;\n"
"  clear)\n"
"    echo -n \"Clearing firewall rules..\"\n"
"    fw_clear\n"
"    echo \"done.\"\n"
"    ;;\n"
"  *)\n"
"    echo \"Usage: $0 {start|stop|restart|clear}\"\n"
"    exit 1\n"
"    ;;\n"
"  esac\n"
"exit 0"
msgstr ""

msgid "Instead of including all of the iptables rules in the init.d script you can use the <command>iptables-restore</command> program to restore the rules saved using <command>iptables-save</command>. In order to do this you need to setup your rules, save the ruleset under a static location (such as <filename>/etc/default/firewall</filename>)"
msgstr ""

msgid "Configuring firewall rules through <command>ifup</command>"
msgstr ""

msgid "You can use also the network configuration in <filename>/etc/network/interfaces</filename> to setup your firewall rules. For this you will need to:"
msgstr ""

msgid "Create your firewalling ruleset for when the interface is active."
msgstr ""

msgid "Save your ruleset with <command>iptables-save</command> to a file in <filename>/etc</filename>, for example <filename>/etc/iptables.up.rules</filename>"
msgstr ""

msgid "Configure <filename>/etc/network/interfaces</filename> to use the configured ruleset:"
msgstr ""

msgid ""
"\n"
"iface eth0 inet static\n"
"        address x.x.x.x\n"
"        [.. interface configuration ..]\n"
"        pre-up iptables-restore &lt; /etc/iptables.up.rules"
msgstr ""

msgid "You can optionally also setup a set of rules to be applied when the network interface is <emphasis>down</emphasis> creating a set of rules, saving it in <filename>/etc/iptables.down.rules</filename> and adding this directive to the interface configuration:"
msgstr ""

msgid "\n"
"    post-down iptables-restore &lt; /etc/iptables.down.rules"
msgstr ""

msgid "For more advanced firewall configuration scripts through <application>ifupdown</application> you can use the hooks available to each interface as in the <filename>*.d/</filename> directories called with <command>run-parts</command> (see <citerefentry><refentrytitle>run-parts</refentrytitle> <manvolnum>8</manvolnum></citerefentry> manual page)."
msgstr ""

msgid "Testing your firewall configuration"
msgstr ""

msgid "Testing your firewall configuration is as easy, and as dangerous, as just running your firewall script (or enabling the configuration you defined in your firewall configuration application). However, if you are not careful enough and you are configuring your firewall remotely (like through an SSH connection) you could lock yourself out."
msgstr ""

msgid "There are several ways to prevent this. One is running a script in a separate terminal that will remove the firewall configuration if you don't feed it input. An example of this is:"
msgstr ""

msgid ""
"\n"
"$  while true; do test=\"\"; read  -t 20 -p \"OK? \" test ; \\\n"
"  [ -z \"$test\" ] &amp;&amp; /etc/init.d/firewall clear ; done"
msgstr ""

msgid "Another one is to introduce a backdoor in your system through an alternate mechanism that allows you to either clear the firewall system or punch a hole in it if something goes awry. For this you can use <application>knockd</application> and configure it so that a certain port connection attempt sequence will clear the firewall (or add a temporary rule). Even though the packets will be dropped by the firewall, since <command>knockd</command> binds to the interface and <emphasis>sees</emphasis> you will be able to work around the problem."
msgstr ""

msgid "Testing a firewall that is protecting an internal network is a different issue, you will want to look at some of the tools used for remote vulnerability assessment (see <xref linkend=\"vuln-asses\" />) to probe the network from the outside in (or from any other direction) to test the effectiveness of the firewall configuation."
msgstr ""