Repository navigation
Expand file tree
/
Copy pathreadme.txt
More file actions
1599 lines (1111 loc) · 60.8 KB
/
Copy pathreadme.txt
File metadata and controls
1599 lines (1111 loc) · 60.8 KB
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
###############################################################################
# Copyright (C) 2006-2025 Jonathan Michaelson
#
# https://github.com/waytotheweb/scripts
#
# This program is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free Software
# Foundation; either version 3 of the License, or (at your option) any later
# version.
#
# This program is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
# FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
# details.
#
# You should have received a copy of the GNU General Public License along with
# this program; if not, see <https://www.gnu.org/licenses>.
###############################################################################
ConfigServer Security & Firewall
################################
This suite of scripts provides:
1. A straight-forward SPI iptables firewall script
2. A daemon process that checks for Login Authentication
3. A Control Panel configuration interface
4. ... and much more!
The reason we have developed this suite is that we have found over the years of
providing server management services that many of the tools available for the
task are either over-complex, not very friendly, or simply aren't as effective
as they could or should be.
This document contains:
1. Introduction
2. csf Principles
3. lfd Principles
4. csf Command Line Options
5. lfd Command Line Options
6. Login Tracking
7. Script Email Alerts
8. Process Tracking
9. Directory Watching
10. Advanced Allow/Deny Filters
11. Multiple Ethernet Devices
12. Installation on a Generic Linux Server
13. A note about FTP Connection Issues
14. Messenger Service (v1, v2 and v3)
15. Block Reporting
16. Port Flood Protection
17. External Pre- and Post- Scripts
18. lfd Clustering
19. Port Knocking
20. Connection Limit Protection
21. Port/IP address Redirection
22. Integrated User Interface Feature
23. IP Block Lists
24. Mitigating issues with syslog/rsyslog logs (RESTRICT_SYSLOG)
25. Exim SMTP AUTH Restriction
26. UI Skinning and Mobile View
27. CloudFlare
1. Introduction
###############
ConfigServer Firewall (csf)
===========================
We have developed an SPI iptables firewall that is straight-forward, easy and
flexible to configure and secure with extra checks to ensure smooth operation.
csf can be used on any (supported - see the website) generic Linux OS.
The csf installation includes preconfigured configurations and control panel
UI's for cPanel
Directory structure:
/etc/csf/ - configuration files
/var/lib/csf/ - temporary data files
/usr/local/csf/bin/ - scripts
/usr/local/csf/lib/ - perl modules and static data
/usr/local/csf/tpl/ - email alert templates
Login Failure Daemon (lfd)
==========================
To complement the ConfigServer Firewall, we have developed a daemon process
that runs all the time and periodically (every X seconds) scans the latest log
file entries for login attempts against your server that continually fail
within a short period of time. Such attempts are often called "Brute-force
attacks" and the daemon process responds very quickly to such patterns and
blocks offending IP's quickly. Other similar products run every x minutes via
cron and as such often miss break-in attempts until after they've finished, our
daemon eliminates such long waits and makes it much more effective at
performing its task.
There are an array of extensive checks that lfd can perform to help alert the
server administrator of changes to the server, potential problems and possible
compromises.
On cPanel servers, lfd is integrated into the WHM > Service Manager, which will
restart lfd if it fails for any reason.
Control Panel Interface
=======================
To help with the ease and flexibility of the suite we have developed a
front-end to both csf and lfd for cPanel. From there
you can modify the configuration files and stop, start and restart the
applications and check their status. This makes configuring and managing the
firewall very simple indeed.
There is, of course, a comprehensive Command Line Interface (CLI) for csf.
2. csf Principles
#################
The idea with csf, as with most iptables firewall configurations, is to block
everything and then allow through only those connections that you want. This is
done in iptables by DROPPING all connections in and out of the server on all
protocols. Then allow traffic in and out from existing connections. Then open
ports up in and outgoing for both TCP and UDP individually.
This way we can control exactly what traffic is allowed in and out of the
server and helps protect the server from malicious attack.
In particular it prevents unauthorised access to network daemons that we want
to restrict access by IP address, and also should a service suffer a
compromise, it can help prevent access to compromise networks daemons, a
typical example being a hackers sshd daemon running on a random open port.
Perhaps the greatest of reasons is to help mitigate the effects of suffering a
root compromise where often they only way to take advantage of such a failure
is to open a daemon for the hacker to access the server on. While this won't
prevent root compromises, it can help slow them down enough for you to notice
and react.
Another way that a port filtering firewall can help is when a user level
compromise occurs and a hacker installs DOS tools to effect other servers. A
firewall configured to block outgoing connections except on specific ports can
help prevent DOS attacks from working and make it immediately apparent to you
from the system logs.
csf has been designed to keep this configuration simple, but still flexible
enough to give you options to suit your server environment. Often firewall
scripts can become cumbersome of complex making it impossible to identify where
problems lie and to easily fix them.
To take advantage of kernel logging of iptables dropped connections you should
ensure that kernel logging daemon (klogd) is enabled. Typically, VPS servers
have this disabled and you should check /etc/init.d/syslog and make sure that
any klogd lines are not commented out. If you change the file, remember to
restart syslog.
3. lfd Principles
#################
One of the best ways to protect the server from inbound attack against network
daemons is to monitor their authentication logs. Invalid login attempts which
happen in a short space of time from the same source can often mean someone is
attempting to brute-force their way into the server, usually by guessing
usernames and passwords and therefore generating authentication and login
failures.
lfd can monitor the most commonly abused protocols, SSHD, POP3, IMAP, FTP and
HTTP password protection. Unlike other applications, lfd is a daemon process
that monitors logs continuously and so can react within seconds of detecting
such attempts. It also monitors across protocols, so if attempts are made on
different protocols in a short space of time, all those attempts will be
counted against the threshold.
Once the number of failed login attempts is reached, lfd immediately forks a
sub-process and uses csf to block the offending IP address from both in and
outgoing connections. Stopping the attack in its tracks in a quick and timely
manner. Other applications that use cron job timings to run usually completely
miss brute force attacks as they run usually every 5 minutes or by which time
the attack could be over, or simply biding its time. In the meantime lfd will
have block the offenders IP address.
By running the block and alert email actions in a sub-process, the main daemon
can continue monitoring the logs without delay.
If you want to know when lfd blocks an IP address you can enable the email
alert (which is on by default) and you should watch the log file in
/var/log/lfd.log.
4. csf Command Line Options
###########################
Before configuring and starting csf for the first time, it is a good idea to
run the script /etc/csf/csftest.pl using:
perl /etc/csf/csftest.pl
This script will test whether the required iptables modules are functioning on
the server. Don't worry if it cannot run all the features, so long as the
script doesn't report any FATAL errors.
You can view the csf command line options by using either:
# man csf
or
# csf -h
These options allow you to easily and quickly control and view csf. All the
configuration files for csf are in /etc/csf and include:
csf.conf - the main configuration file, it has helpful comments explaining
what each option does
csf.allow - a list of IP's and CIDR addresses that should always be allowed
through the firewall
csf.deny - a list of IP's and CIDR addresses that should never be allowed
through the firewall
csf.ignore - a list of IP's and CIDR addresses that lfd should ignore and
not block if detected
csf.*ignore - various ignore files that list files, users, IP's that lfd
should ignore. See each file for their specific purpose and
tax
If you modify any of the files listed above, you will need to restart csf and
then lfd to have them take effect. If you use the command line options to add
or deny IP addresses, then csf automatically does this for you.
Both csf.allow and csf.deny can have comments after the IP address listed. The
comments must be on the same line as the IP address otherwise the IP rotation
of csf.deny will remove them.
If editing the csf.allow or csf.deny files directly, either from shell or the
WHM UI, you should put a <space>#<space> between the IP address and the comment
like this:
11.22.33.44 # Added because I don't like them
You can also include comments when using the csf -a or csf -d commands, but in
those cases you must not use a # like this:
csf -d 11.22.33.44 Added because I don't like them
If you use the shell commands then each comment line will be timestamped. You
will also find that if lfd blocks an IP address it will add a descriptive
comment plus timestamp.
If you don't want csf to rotate a particular IP in csf.deny if the line limit
is reach you can do so by adding "do not delete" within the comment field,
e.g.:
11.22.33.44 # Added because I don't like them. do not delete
Include statement in configuration files
========================================
You can use an Include statement in the following files that conform to the
format of the originating file:
/etc/csf/csf.allow
/etc/csf/csf.blocklists
/etc/csf/csf.cloudflare
/etc/csf/csf.deny
/etc/csf/csf.dirwatch
/etc/csf/csf.dyndns
/etc/csf/csf.fignore
/etc/csf/csf.ignore
/etc/csf/csf.logfiles
/etc/csf/csf.logignore
/etc/csf/csf.mignore
/etc/csf/csf.pignore
/etc/csf/csf.rblconf
/etc/csf/csf.redirect
/etc/csf/csf.rignore
/etc/csf/csf.signore
/etc/csf/csf.sips
/etc/csf/csf.smtpauth
/etc/csf/csf.suignore
/etc/csf/csf.syslogs
/etc/csf/csf.syslogusers
/etc/csf/csf.uidignore
You must specify the full path to the included file, e.g. in
/etc/csf/csf.allow:
Include /etc/csf/csf.alsoallow
Do NOT put a comment after the Include filename as this will not work and will
invalidate the Include line.
Note: None of the csf commands for adding or removing entries from the
originating file will be performed on Include files. They are treated as
read-only.
5. lfd Command Line Options
###########################
lfd does not have any command line options of its own but is controlled through
init or systemd which stops and starts the daemon. It is configured using the
/etc/csf/csf.conf file.
The best way to see what lfd is up to is to take a look in /var/log/lfd.log
where its activities are logged.
The various email alert templates follow, care should be taken if you
modify that file to maintain the correct format:
/usr/local/csf/tpl/accounttracking.txt - for account tracking alert emails
/usr/local/csf/tpl/alert.txt - for port blocking emails
/usr/local/csf/tpl/connectiontracking.txt - for connection tracking emails
/usr/local/csf/tpl/consolealert.txt - for console root login alert emails
/usr/local/csf/tpl/cpanelalert.txt - for WHM/cPanel account access emails
/usr/local/csf/tpl/exploitalert.txt - for system exploit alert emails
/usr/local/csf/tpl/filealert.txt - for suspicious file alert emails
/usr/local/csf/tpl/forkbombalert.txt - for fork bomb alert emails
/usr/local/csf/tpl/integrityalert.txt - for system integrity alert emails
/usr/local/csf/tpl/loadalert.txt - for high load average alert emails
/usr/local/csf/tpl/logalert.txt - for log scanner report emails
/usr/local/csf/tpl/logfloodalert.txt - for log file flooding alert emails
/usr/local/csf/tpl/modsecipdbcheck.txt - for ModSecurity IP DB size alert emails
/usr/local/csf/tpl/netblock.txt - for netblock alert emails
/usr/local/csf/tpl/permblock.txt - for temporary to permanent block alert emails
/usr/local/csf/tpl/portknocking.txt - for Port Knocking alert emails
/usr/local/csf/tpl/portscan.txt - for port scan tracking alert emails
/usr/local/csf/tpl/processtracking.txt - for process tracking alert emails
/usr/local/csf/tpl/queuealert.txt - for email queue alert emails
/usr/local/csf/tpl/relayalert.txt - for email relay alert emails
/usr/local/csf/tpl/resalert.txt - for process resource alert emails
/usr/local/csf/tpl/scriptalert.txt - for script alert emails
/usr/local/csf/tpl/sshalert.txt - for SSH login emails
/usr/local/csf/tpl/sualert.txt - for SU alert emails
/usr/local/csf/tpl/tracking.txt - for POP3/IMAP blocking emails
/usr/local/csf/tpl/uialert.txt - for UI alert emails
/usr/local/csf/tpl/usertracking.txt - for user process tracking alert emails
/usr/local/csf/tpl/watchalert.txt - for watched file and directory change alert emails
6. Login Tracking
#################
Login tracking is an extension of lfd, it keeps track of POP3 and IMAP logins
and limits them to X connections per hour per account per IP address. It uses
iptables to block offenders to the appropriate protocol port only and flushes
them every hour and starts counting logins afresh. All of these blocks are
temporary and can be cleared manually by restarting csf.
There are two settings, one of POP3 and one for IMAP logins. It's generally
not a good idea to track IMAP logins as many clients login each time to perform
a protocol transaction (there's no need for them to repeatedly login, but you
can't avoid bad client programming!). So, if you do have a need to have some
limit to IMAP logins, it is probably best to set the login limit quite high.
If you want to know when lfd temporarily blocks an IP address you can enable
the email tracking alerts option (which is on by default)
You can also add your own login failure tracking using regular expression
matching. Please read /usr/local/csf/bin/regex.custom.pm for more information
Important Note: To enable successful SSHD login tracking you should ensure that
UseDNS in /etc/ssh/sshd_config is disabled by using:
UseDNS no
and that sshd has then been restarted.
7. Script Email Alerts
######################
(cPanel installations of csf only)
lfd can scan for emails being sent through exim from scripts on the server.
To use this feature you must add an extended email logging line to WHM >
Exim Configuration Manager > Advanced Editor. Search for log_selector and
ensure that the following are included:
log_selector = +arguments +subject +received_recipients
This setting will then send an alert email if more than LF_SCRIPT_LIMIT lines
appear with the same cwd= path in them within an hour. This can be useful in
identifying spamming scripts on a server, especially PHP scripts running
under the nobody account. The email that is sent includes the exim log lines
and also attempts to find scripts that send email in the path that may be the
culprit.
This option uses the /usr/local/csf/tpl/scriptalert text file for alert emails.
If you enable the option LF_SCRIPT_ALERT then lfd will disable the path using
chattr +i and chmod 000 so that the user cannot re-enable it. The alert email
also then includes the commands needed to re-enable the offending path.
Any false-positives can be added to /etc/csf/csf.signore and lfd will then
ignore those listed scripts.
8. Process Tracking
###################
This option enables tracking of user and nobody processes and examines them for
suspicious executables or open network ports. Its purpose is to identify
potential exploit processes that are running on the server, even if they are
obfuscated to appear as system services. If a suspicious process is found an
alert email is sent with relevant information.
It is then the responsibility of the recipient to investigate the process
further as the script takes no further action. Processes (PIDs) are only
reported once unless lfd is restarted.
There is an ignore file /etc/csf/csf.pignore which can be used to whitelist
either usernames or full paths to binaries. Care should be taken with ignoring
users or files so that you don't force false-negatives.
You must use the following format:
exe:/full/path/to/file
user:username
cmd:command line
The command line as reported in /proc has the trailing null character removed
and all other occurrences replaced with a space. So, the line you specify in
the file should have space separators for the command line arguments, not null
characters.
It is strongly recommended that you use command line ignores very carefully
as any process can change what is reported to the OS.
Don't list the paths to perl or php as this will prevent detection of
suspicious web scripts.
For more information on the difference between executable and command line, you
should read and understand how the linux /proc pseudo-filesystem works:
man proc
man lsof
It is beyond the scope of this application to explain how to investigate
processes in the linux /proc architecture.
The email alerts are sent using the processtracking.txt email template.
It should be noted that this feature will not pickup a root compromise as root
processes are ignored - you should use established IDS tools for such security
considerations.
*** NOTE *** You _will_ get false-positives with this particular feature. The
reason for the feature is to bring to your attention processes that have either
been running for a long time under a user account, or that have ports open
outside of your server. You should satisfy yourself that they are indeed false-
positives before either ignoring them or trapping them in the csf.pignore file.
We've done our best to minimise false-positives, but there's a balance between
being cautious and the sensitivity needed to pick up exploits.
The script itself cannot distinguish between malicious intent and intended
script function - that's your job as the server administrator ;-)
The setting PT_SKIP_HTTP does reduce the number of false-positives by not
checking scripts running directly or through CGI in Apache. However, disabling
this setting will make a more thorough job of detecting active exploits of all
varieties.
Another alternative might be to disable PT_SKIP_HTTP and increase PT_LIMIT to
avoid picking up web scripts, however this means that real exploits will run
for longer before they're picked up.
You can, of course, turn the feature off too - if you really want to.
9. Directory Watching
#####################
Directory Watching enables lfd to check /tmp and /dev/shm and other pertinent
directories for suspicious files, i.e. script exploits.
If a suspicious file is found an email alert is sent using the template
filealert.txt.
NOTE: Only one alert per file is sent until lfd is restarted, so if you remove
a suspicious file, remember to restart lfd
To remove any suspicious files found during directory watching, enable
corresponding setting the suspicious files will be appended to a tarball in
/var/lib/csf/suspicious.tar and deleted from their original location. Symlinks
are simply removed.
If you want to extract the tarball to your current location, use:
tar -xpf /var/lib/csf/suspicious.tar
This will preserver the path and permissions of the original file.
Any false-positives can be added to /etc/csf/csf.fignore and lfd will then
ignore those listed files and directories.
Within csf.fignore is a list of files that lfd directory watching will ignore.
You must specify the full path to the file
You can also use perl regular expression pattern matching, for example:
/tmp/clamav.*
/tmp/.*\.wrk
Remember that you will need to escape special characters (precede them with a
backslash) such as \. \?
Pattern matching will only occur with strings containing an asterisk (*),
otherwise full file path matching will be applied
You can also add entries to ignore files owner by a particular user by
preceding it with user:, for example:
user:bob
Note: files owned by root are ignored
For information on perl regular expressions:
http://www.perl.com/doc/manual/html/pod/perlre.html
The second aspect of Directory Watching is enabled with LF_DIRWATCH_FILE. This
option allows you to have lfd watch a particular file or directory for changes
and should they change and email alert using watchalert.txt is sent. It uses a
simple md5sum match from the output of "ls -laAR" on the entry and so will
traverse directories if specified.
10. Advanced Allow/Deny Filters
###############################
In /etc/csf/csf.allow and /etc/csf/csf.deny you can add more complex port and
ip filters using the following format (you must specify a port AND an IP
address):
tcp/udp|in/out|s/d=port|s/d=ip|u=uid
Broken down:
tcp/udp : EITHER tcp OR udp OR icmp protocol
in/out : EITHER incoming OR outgoing connections
s/d=port : EITHER source OR destination port number (or ICMP type)
(use a _ for a port range, e.g. 2000_3000)
(use a , for a multiport list of up to 15 ports, e.g. 22,80,443)
s/d=ip : EITHER source OR destination IP address
u/g=UID : EITHER UID or GID of source packet, implies outgoing connections,
s/d=IP value is ignored
Note: ICMP filtering uses the "port" for s/d=port to set the ICMP type.
Whether you use s or d is not relevant as either simply uses the iptables
--icmp-type option. Use "iptables -p icmp -h" for a list of valid ICMP types.
Only one type per filter is supported
Examples:
# TCP connections inbound to port 3306 from IP 11.22.33.44
tcp|in|d=3306|s=11.22.33.44
# TCP connections outbound to port 22 on IP 11.22.33.44
tcp|out|d=22|d=11.22.33.44
Note| If omitted, the default protocol is set to "tcp", the default connection
direction is set to "in", so|
# TCP connections inbound to port 22 from IP 44.33.22.11
d=22|s=44.33.22.11
# TCP connections outbound to port 80 from UID 99
tcp|out|d=80||u=99
# ICMP connections inbound for type ping from 44.33.22.11
icmp|in|d=ping|s=44.33.22.11
# TCP connections inbound to port 22 from Dynamic DNS address
# www.configserver.com (for use in csf.dyndns only)
tcp|in|d=22|s=www.configserver.com
# TCP connections inbound to port 22,80,443 from IP 44.33.22.11
d=22,80,443|s=44.33.22.11
11. Multiple Ethernet Devices
#############################
If you have multiple ethernet NICs that you want to apply all rules to, then
you can set ETH_DEVICE to the interface name immediately followed by a plus
sign. For example, eth+ will apply all iptables rules to eth0, eth1, etc.
That said, if you leave ETH_DEVICE blank all rules will be applied to all
ethernet devices equally.
12. Installation on a Generic Linux Server
##########################################
csf+lfd can be configured to run on a generic Linux server. There are some
changes to the features available:
1. The default port range is for a typical non-cPanel web server and may need
altering to suit the servers environment
2. The Process Tracking ignore file may need expanding in /etc/csf/csf.pignore
to suit the server environment
The codebase is the same for a all installations, the csf.conf file simply has
the cPanel specific options removed and the GENERIC option added
13. A note about FTP Connection Issues
######################################
It is important when using an SPI firewall to ensure FTP client applications
are configured to use Passive (PASV) mode connections to the server.
On servers running Monolithic kernels (e.g. VPS Virtuozzo/OpenVZ and custom
built kernels) ip_conntrack and ip_conntrack_ftp iptables kernel modules may
not be available or fully functional. If this happens, FTP passive mode (PASV)
won't work. In such circumstances you will have to open a hole in your firewall
and configure the FTP server to use that same hole.
For example, with pure-ftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/pure-ftpd.conf and then restart pure-ftpd:
PassivePortRange 30000 35000
For example, with proftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/proftpd.conf and then restart proftpd:
PassivePorts 30000 35000
FTP over SSL/TLS will usually fail when using an SPI firewall. This is because
of the way the FTP protocol established a connection between client and server.
iptables fails to establish a related connection when using FTP over SSL
because the FTP control connection is encrypted and so cannot track the
relationship between the connection and the allocation of an ephemeral port.
If you need to use FTP over SSL, you will have to open up a passive port block
in both csf and your FTP server configuration (see above).
Perversely, this makes your firewall less secure, while trying to make FTP
connections more secure.
14. Messenger Service
#####################
This feature allows the display of a message to a blocked connecting IP address
to inform the user that they are blocked in the firewall. This can help when
users get themselves blocked, e.g. due to multiple login failures. The service
is provided by several daemons running on ports providing HTTPS, HTML or TEXT
message.
This services uses the iptables nat table and the associated PREROUTING chain.
The ipt_REDIRECT module is used to redirect the incoming port to the relevant
messenger service server port.
Temporary and/or permanent (csf.deny) IP addresses can be serviced by this
feature.
It does NOT include redirection of any GLOBAL or BLOCK deny lists.
It does require the IO::Socket::INET perl module.
It does NOT work on servers that do not have the iptables module ipt_REDIRECT
loaded. Typically, this will be with Monolithic kernels. VPS server admins
should check with their VPS host provider that the iptables module is included.
If you change any of the files in /etc/csf/messenger/ you must restart lfd as
they are all cached in memory.
Use of this feature can be controlled by the Country Code options:
CC_MESSENGER_ALLOW = ""
CC_MESSENGER_DENY = ""
See /etc/csf/csf.conf for an explanation of those options.
Messenger User
==============
You should create a unique user that the messenger services will run under.
This user should be disabled and have no shell access, but should have a home
directory.
For example, you can create such an account (in this example called "csf") from
the root shell using:
useradd csf -s /bin/false
TEXT Messenger Server
=====================
The TEXT message that is displayed is provided by the file:
/etc/csf/messenger/index.text
This file should only contain text. The TEXT server providing this file simply
sends the contents to the connecting port and no protocol exchange takes place.
this means that it may not be suitable for use with protocols such as POP3.
The server has a built-in function that will replace the text [IPADDRESS] in
index.text with the IP address that is blocked by the firewall. This will help
the blocked user know what their blocked IP address is. You can also use the
text [HOSTAME] which will be replaced by the servers FQDN hostname.
The TEXT server does not support SSL connections, so redirecting port 995 will
not work.
The TEXT server port should not be added to the TCP_IN list.
There is a maximum of 15 port allowed in MESSENGER_TEXT_IN.
HTML and HTTPS Messenger v1 Server
==================================
The HTML and HTTPS message that is displayed is provided by the file:
/etc/csf/messenger/index.html
/etc/csf/messenger/index.recaptcha.html (if using the RECAPTCHA_* feature)
The HTML server providing this page is very rudimentary but will accept the use
of linked images that are stored in the /etc/csf/messenger/ directory. The
images must be of either jpg, gif or png format. These images are loaded into
memory so you should keep the number and size to a minimum. No other linked
resource files are supported (e.g. .css, .js).
It is recommeneded to to use inline images (source embedding) to improve page
load speed and reduce lfd overheads.
As the HTML server requires interaction with the client, there is a timer on
the connection to prevent port hogging.
The server has a built-in function that will replace the text [IPADDRESS] in
index.html with the IP address that is blocked by the firewall. This will help
the blocked user know what their blocked IP address is. You can also use the
text [HOSTAME] which will be replaced by the servers FQDN hostname.
The HTTPS service obtains the necessary certificates from MESSENGER_HTTPS_CONF.
The HTML and HTTPS server ports should not be added to the TCP_IN list.
There is a maximum of 15 ports allowed in MESSENGER_HTML_IN and
MESSENGER_HTTPS_IN.
HTML and HTTPS Messenger v2 Server
==================================
This service is only available to cPanel servers running Apache. It utilises
the existing Apache service to provide the message as well as RECAPTCHA
unblocking. It is enabled through the MESSENGERV2 option.
The server must be running Apache v2.4 and using cPanel's EasyApache v4.
HTML and HTTPS Messenger v3 Server
==================================
This service is available to servers running Apache or Litespeed/Openlitespeed.
It utilises the existing web server service to provide the message as well as
RECAPTCHA unblocking. It is enabled through the MESSENGERV3 option.
The web server configuration is created in /var/lib/csf/csf.conf using the
following templates in /usr/local/csf/tpl/:
apache.main.txt
apache.http.txt
apache.https.txt
litespeed.main.txt
litespeed.http.txt
litespeed.https.txt
*.main.txt can contain any web server directives required for the service to
function.
*.http.txt contains the configuration to offer the HTTP service
*.https.txt contains the configuration to offer the HTTPS service. In this file
the virtualhost container is created for each domain served with a certificate
on the server.
These templates are not overwritten during a csf upgrade.
PHP is needed to display the MESSENGER web files (see following). This is
controlled by the MESSENGERV3PHPHANDLER setting.
If left empty, the MESSENGER service will try to configure this. If this does
not work, this should be set as an "Include /path/to/csf_php.conf" or similar
file which must contain appropriate web server configuration to allow PHP
scripts to run under the MESSENGER_USER account. This line will be included
within each MESSENGER VirtualHost container. This will replace the
[MESSENGERV3PHPHANDLER] line from the csf webserver template files.
Messenger v2 and v3
===================
For the service to work, the Messenger User MUST have a specific directory
structure. This will be created by the script if it does not exist so long as
the user has been created with a home directory. The structure needs to mimic
the standard web server setup, e.g. using "csf" as the user:
/home/csf/ (Owner csf:csf, Permissions 711)
/home/csf/public_html/ (Owner csf:nobody, Permissions 711)
lfd will populate this structure with the following files:
/home/csf/public_html/.htaccess
/home/csf/public_html/index.php
If RECAPTCHA_* is enabled these files will be created if they do not already
exist:
/home/csf/recaptcha.php
/home/csf/public_html/index.php
/home/csf/en.php
The HTML and HTTPS index file is created from (respectively):
/etc/csf/messenger/index.php
/etc/csf/messenger/index.recaptcha.php
/etc/csf/messenger/en.php
You should NOT modify the templates in /etc/csf/messenger/ as they will be
overwritten when csf upgrades. Instead modify the files within /home/csf/.
Each time lfd is restarted a check is made of the preceding structure and any
missing files are recreated. This process also creates the configuration file
for Apache in /etc/apache2/conf.d/csf.messenger.conf and restarts httpd.
/etc/apache2/conf.d/csf.messenger.conf contains all the VirtualHost directives
to serve the MESSENGERV2 services.
Translation of /home/csf/en.php is possible by creating the appropriate
[abbr].php file.
The HTML and HTTPS server ports should NOT be added to the TCP_IN list.
As Apache is handling all requests for HTML and HTTPS connections, all
scripting for the service is provided by the files in /home/csf/public_html/
which allows the use of PHP and CGI scripts.
15. Block Reporting
###################
lfd can run an external script when it performs and IP address block following
for example a login failure. This is done by setting the configuration variable
BLOCK_REPORT to a script that must be executable. The following parameters are
passed the the script as arguments:
ARG 1 = IP Address # The IP address or CIDR being blocked
ARG 2 = ports # Port, comma separated list or * for all ports
ARG 3 = permanent # 0=temporary block, 1=permanent block
ARG 4 = inout # Direction of block: in, out or inout
ARG 5 = timeout # If a temporary block, TTL in seconds, otherwise 0
ARG 6 = message # Message containing reason for block
ARG 7 = logs # The logs lines that triggered the block (will contain
# line feeds between each log line)
ARG 8 = trigger # The configuration settings triggered
lfd launches the BLOCK_REPORT in a forked process which terminates after 10
seconds if not completed by then. It runs under the root account, so great care
should be exercised with regard to security of the BLOCK_REPORT script.
To also run an external script when a temporary block is unblocked by lfd.
UNBLOCK_REPORT can be the full path of the external script which must be
executable. The following parameters are passed the the script as arguments:
ARG 1 = IP Address # The IP address or CIDR being blocked
ARG 2 = port* # Port, there could be multiple unblocks for each IP
[*] If a port was specified in the initial block.
16. Port Flood Protection
#########################
This option configures iptables to offer protection from DOS attacks against
specific ports. This option limits the number of connections per time interval
that new connections can be made to specific ports.
This feature does not work on servers that do not have the iptables module
ipt_recent loaded. Typically, this will be with Monolithic kernels. VPS server
admins should check with their VPS host provider that the iptables module is
included.
By default ipt_recent tracks only the last 100 IP addresses. The tracked IP
addresses can be viewed in /proc/net/ipt_recent/* where the port number is the
filename.
Syntax for the PORTFLOOD setting:
PORTFLOOD is a comma separated list of:
port;protocol;hit count*;interval seconds
So, a setting of PORTFLOOD = "22;tcp;5;300,80;tcp;20;5" means:
1. If more than 5 connections to tcp port 22 within 300 seconds, then block
that IP address from port 22 for at least 300 seconds after the last packet is
seen, i.e. there must be a "quiet" period of 300 seconds before the block is
lifted
2. If more than 20 connections to tcp port 80 within 5 seconds, then block
that IP address from port 80 for at least 5 seconds after the last packet is
seen, i.e. there must be a "quiet" period of 5 seconds before the block is
lifted
More information about the ipt_recent module can be found in the iptables man
page and at http://snowman.net/projects/ipt_recent/
Note: Blocked IP addresses do not appear in any of the iptables chains when
using this module. You must manipulate the /proc/net/ipt_recent/* files as per
the module documentation to view and remove IP addresses that are currently
blocked if the blocks have not yet expired.
Restarting csf resets the ipt_recent tables and removes all of its blocks.
Note: There are some restrictions when using ipt_recent:
1. By default it only tracks 100 addresses per table (we try and increase this
to 1000 via modprobe)
2. By default it only counts 20 packets per address remembered
*This means that you need to keep the hit count to below 20.
17. External Pre- and Post- Scripts
###################################
External commands (e.g. iptables rules not covered by csf) can be run before
and/or after csf sets up the iptables chains and rules.
1. To run external commands before csf configures iptables create the file:
/usr/local/csf/bin/csfpre.sh
Set that file as executable and add an appropriate shebang interpreter line and
then whatever external commands you wish to execute.
For example:
#!/bin/sh
/some/path/to/binary -a -b -c etc
Then chmod +x /usr/local/csf/bin/csfpre.sh
2. To run external commands after csf configures iptables create the file:
/usr/local/csf/bin/csfpost.sh
Set that file as executable and add an appropriate shebang interpreter line and
then whatever external commands you wish to execute.
Note: The scripts can alternatively be placed in /etc/csf/. If a script is found in
both locations (/etc/csf/ and /usr/local/csf/bin/) then only the script in
/usr/local/csf/bin/ will be executed.
csfpre.sh/csfpost.sh are run directly. If present, csf chmods the script 0700
and checks for a shebang. If the shebang is missing #!/bin/bash is added to the
top. The script is them run.
Note: While csf runs the script with a preset PATH, you MUST use the full path
to any binaries that you execute within these scripts to ensure they are run
correctly
18. lfd Clustering
##################
This set of options (CLUSTER*) in csf.conf allows the configuration of an
lfd cluster environment where a group of servers can share blocks and, via the
CLI, configuration option changes, allows and removes
In the configuration there are two comma separated lists of IP addresses:
CLUSTER_SENDTO = ""
CLUSTER_RECVFROM = ""