|
May 6 2025
Advanced Policy Firewall Support and Upgrades
In keeping with the spirit of GNU/Open Source, I've upgraded APF functions as well as addressed, and patched (in a sense), two bugs found in apf-0.9.5-1; which overall I find to be a really beneficial program and excellent GNU offering and thank those involved for offering the results of their hard work to the Internet community.
For those of you who don't like to read, the issues addressed are:
- APF Upgrade Script Failure - Upgrade tips here
- Insertion of innocent and naughty IPs into firewall rules - Fix here
- Firewall event logging to TTY - Fix here
- Automated task to remove IPs from firewall rules - Upgrade here
- DROP IPs attempting username/password cracks via SSH - Upgrade here
- NEW! Defeat advanced port sniffing techniques - Upgrade here
About Antidos Accidental Multiple IP Firewall Insertions
The bug in the antidos code referred to here relates to the insertion of IP addresses into the firewall DROP rules resulting from antidos' parsing of the Kernel log file. When antidos determines that an IP address has exceeded the TRIG variable set by the system administrator, it has a habit of inserting all IP addresses in the log that happen to be from the same subnet as the offending IP address, regardless of their actual status. This means innocent IPs get caught up and blocked along with the IPs who are doing bad things like port sniffing.
The possibility for such an occurrence is greater than you might think, especially if you have a busy server with popular sites on it. It has happened to me several times which is the reason I started poking around in the first place.
Real World Example of Accidental Multiple IP Firewall Insertions
In this real world example let's assume two different (or several different) SBC or Verizon DSL (or dial-up for that matter) IPs from the same subnet are accessing your box during the same time frame, between antidos cron jobs. One of the IPs is running a hacker script sniffing for open ports, the other's a legitimate customer/system account who makes a single innocent access attempt on a closed port, perhaps 23, forgetting that you, as a good systems administrator, prohibit Telnet and only provide SSH access to your server.
The bad IP keeps pounding away on different ports, while your legitimate user on the good IP soon remembers that Telnet access is prohibited, and properly logs in to his/her account via SSH. The port sniffing hacker and the customer Telnet attempts are all logged as DROP in the kernel log file; many entries for the bad IP over various ports and a single entry or two for the innocent IP over port 23.
Innocent or Bad IPs - Both Accidentally Entered In DROP Rules
The next time the antidos cron job runs, it picks up the bad IP that is port sniffing and blocks it in the firewall rules which is good. However I found it will also pick up any other IP(s) from the same subnet, such as the two accidental Telnet attempts by your customer in the example above, and insert those IPs into the DROP rules as well, regardless of the number of DROP entries in the log file or the TRIG value set in the conf.antidos file.
K.I.S.S. Antidos Bug Patch - Get the patch code from this link
One of the first rules any programmer learns is K.I.S.S. (Keep It Simple Stupid!), as well as comment, comment, comment your code. I took these lessons to heart after learning them from Keith (Krazy) Ward while enrolled in the absolute hardest C programming class at UCLA; Hi Krazy! So I've come up with a quick (K.I.S.S) patch to fix the problem toot-sweet with enough comments (I hope) to allow anyone to use it. Simply copy and paste the code from this link (or you may want this alternative) into the antidos script, replacing the original code and that is it.
Advanced Policy Firewall Upgrade Tips
I make it a habit to poke around and test all GNU software I am interested in because let's face it, it's a good idea. Thus I did just that after upgrading to Advanced Policy Firewall (APF) version apf-0.9.5-1 as root via the install.sh script on a development box.
My testing included running the antidos script without standard output and error redirection. The resulting output showed that via the default upgrade script, antidos contains two errors which cause it to exit and not work at all. Any person, and from the postings I've read on the web apparently many, who blindly updates APF and continues with the antidos cron job with std err and std out redirection find themselves wondering why things are not working as expected.
To alleviate this problem I suggest simply performing the following commands to update APF in lieu of the install.sh script (remember to disable the antidos cron job until you've finished installing):
As root execute
root@domain> cd /etc/apf
root@domain> cp conf.apf conf.apf.orig
root@domain> cd /DirWhereYouUntarredApf-current.tar.gz/apf-0.9.5-1/files/
root@domain> cp -r * /etc/apf/.
Yes to all queries to overwrite files
root@domain> vi /etc/rc.d/init.d/apf
Comment out line: $inspath/vnet/vnetgen >> /dev/null 2>&1
Not sure why this is not used in apf-0.9.5-1 but is not contained in new init file.
And that's it! You've backed up your original conf.apf file in the first step above to conf.apf.orig, so compare it to the new conf.apf file and make the necessary adjustments to that file, then check out the new conf.antidos file and make adjustments, restart apf and you are good to go.
Stop Annoying IPTABLES Event Logging to TTY
By default, all IP DROPs, as well as SSH requests, are logged to TTY as well as /var/log/messages. Since I code on TTY often, I find this particularly annoying and thus decided to do something about it. Below are the steps to take to prevent IPTABLE event logging to TTY.
As root do the following - Don't do this unless you are sure you understand the implications!
- root@domain> vi /etc/syslog.conf
- Add the following line
kern.=debug /var/log/messages
- Save and close /etc/syslog.conf A
- root@domain> vi /etc/apf/log.rules
- # add --log-level debug to the end of the following lines as shown
$IPT -A TELNET_LOG -j LOG --log-prefix "** TELNET ** " --log-level debug
$IPT -A SSH_LOG -j LOG --log-prefix "** SSH ** " --log-level debug
- Save and close /etc/apf/log.rules
- root@domain> vi /etc/apf/firewall
- # add --log-level debug to the end of the following lines as shown
if [ "$DROP_LOG" == "1" ]; then
# Default TCP/UDP INPUT log chain
if [ "$EXLOG" == "1" ]; then
$IPT -A INPUT -p tcp -m limit --limit $LRATE/minute -i $IN_IF -j LOG --log-prefix "** IN_TCP DROP ** " --log-tcp-options --log-ip-options --log-level debug
$IPT -A INPUT -p udp -m limit --limit $LRATE/minute -i $IN_IF -j LOG --log-prefix "** IN_UDP DROP ** " --log-ip-options --log-level debug
else
$IPT -A INPUT -p tcp -m limit --limit $LRATE/minute -i $IN_IF -j LOG --log-prefix "** IN_TCP DROP ** " --log-level debug
$IPT -A INPUT -p udp -m limit --limit $LRATE/minute -i $IN_IF -j LOG --log-prefix "** IN_UDP DROP ** " --log-level debug
fi
fi
if [ "$DROP_LOG" == "1" ] && [ "$EGF" == "1" ]; then
# Default TCP/UDP OUTPUT log chain
if [ "$EXLOG" == "1" ]; then
$IPT -A OUTPUT -p tcp -m limit --limit $LRATE/minute -o $OUT_IF -j LOG --log-prefix "** OUT_TCP DROP ** " --log-tcp-options --log-ip-options --log-level debug
$IPT -A OUTPUT -p udp -m limit --limit $LRATE/minute -o $OUT_IF -j LOG --log-prefix "** OUT_UDP DROP ** " --log-ip-options --log-level debug
else
$IPT -A OUTPUT -p tcp -m limit --limit $LRATE/minute -o $OUT_IF -j LOG --log-prefix "** OUT_TCP DROP ** " --log-level debug
$IPT -A OUTPUT -p udp -m limit --limit $LRATE/minute -o $OUT_IF -j LOG --log-prefix "** OUT_UDP DROP ** " --log-level debug
fi
fi
- Save and close /etc/apf/firewall
- root@domain> /sbin/service syslog reload
- root@domain> /sbin/service apf restart
A) IMPORTANT!
Remember that all kernel debug messages will now be printed to /var/log/messages instead of TTY. You could also direct the kernel debug messages to any file you choose, but be sure to update antidos to reflect the changes. Finally you could also add kern.!=debug /dev/console to have all other kernel messages, except debug, logged to TTY.
 zAPFipExtended: An Upgraded Version of zAPFip Upgrade
The zAPFipExtended upgrade provided here performs the following:
- Looks for SSH username/password crack attempts, adds offending IPs to firewall
- NEW! Now handles intermittent port sniffing trends attempting to avoid detection.
- Automatically removes IPs from firewall rules based on user preferences
- Includes antidos bug patch covered above
zAPFipExtended is an upgrade to the previous zAPFip set of add-on scripts written for use with Advanced Policy Firewall. It was developed in response to trends by malicious port sniffers who are on to the log parsing game used until this point and now spread out their port sniffing attempts over a period of several hours or days in order to avoid detection. By using this upgraded set of scripts I now catch and DROP more IPs who are port sniffing; IPs that would otherwise avoid detection.
zAPFip: An Upgraded Version of APF
The APF upgrade provided here performs the following:
- Looks for SSH username/password crack attempts, adds offending IPs to firewall
- Automatically removes IPs from firewall rules based on user preferences
- Includes antidos bug patch covered above
One last subject is the fact that APF currently has no automated method in place for removing IP addresses added to the DROP rules. As we all know, virtually all IPs used for Internet access these days are assigned via DHCP. Thus Mr. Hacker can be using an IP one day and then a legitimate customer the next. If Mr. Hacker has been using it first to port sniff your box resulting in the insertion of the IP into the firewall rules, then obviously the legitimate customer will also be locked out a day, week, month later when he tries to access the box, until you manually remove the IP from both the Firewall rules and the ad.rules file.
Here I provide an APF upgrade to handle that problem. The upgrade automates the process and allows you to choose how long the DROP IPs stay in the firewall rules before being removed. Minimum requirements are Linux, Perl 5.0 and MySQL 3.23.58. Download zAPFip.tar.gz archive here. The upgrade is super easy to install and configure, even for a complete novice, the archive contains the instructions you need.
zAPFip Compatibility
The zAPFip APF and zAPFipExntended updates have been tested on Fedora Core 2 with the SELinux option off, as well as Fedora Core 1, thus they should work on older versions of Red Hat and other flavors of Linux, however not on FreeBSD. It also works with servers running Core 1, Core 2 and the Ensim Control panel.
Enjoy!!! :-)
gregoryg.net - Quality Internet Services - we do it better; guaranteed.
or Email Us with any questions.
|
|
Virtual Hosting and
Greetings from the