I had a thought that the parsing you already do might be useful in another way. I use fail2ban that montiors logs and builds iptables rules after x number of occurrences. It uses regex but I could imagine building those regex for the log montioring would be useful using the snort rules as a basis. execution time would be the biggest challenged, but my thought is that having 10k rules in your firewall as opposed to having regex'ed applied to the logs might be a apples to apples difference but might be more flexible as its not in memory.

Ubuntu 20 Server + psad 2.4.6 + fwsnort-1.6.8

fwsnort.sh script failing add iptables rules with last emerging-all.rules version

problem on ports with ! [!445,!1500]

seems a famliar issue?

root@2w1r:/usr/local/src/fwsnort-1.6.8# fwsnort
[+] Testing /sbin/iptables for supported capabilities...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    Snort Rules File          Success   Fail      Total

[+] attack-responses.rules    16        1         17
[+] backdoor.rules            65        11        76
[+] bad-traffic.rules         9         3         12
[+] chat.rules                29        1         30
[+] ddos.rules                18        14        32
[+] dns.rules                 19        2         21
[+] dos.rules                 9         7         16
[+] emerging-all.rules        11877     7035      18912
[+] experimental.rules        0         0         0
[+] exploit.rules             36        46        82
[+] finger.rules              13        1         14
[+] ftp.rules                 21        49        70
[+] icmp-info.rules           65        28        93
[+] icmp.rules                18        4         22
[+] imap.rules                1         37        38
[+] info.rules                8         2         10
[+] local.rules               0         0         0
[+] misc.rules                42        18        60
[+] multimedia.rules          4         6         10
[+] mysql.rules               3         0         3
[+] netbios.rules             11        419       430
[+] nntp.rules                0         13        13
[+] oracle.rules              3         295       298
[+] other-ids.rules           3         0         3
[+] p2p.rules                 18        0         18
[+] policy.rules              20        1         21
[+] pop2.rules                2         2         4
[+] pop3.rules                6         21        27
[+] porn.rules                21        0         21
[+] rpc.rules                 37        91        128
[+] rservices.rules           13        0         13
[+] scan.rules                14        4         18
[+] shellcode.rules           21        0         21
[+] smtp.rules                14        45        59
[+] snmp.rules                17        0         17
[+] sql.rules                 42        4         46
[+] telnet.rules              13        2         15
[+] tftp.rules                9         2         11
[+] virus.rules               0         1         1
[+] web-attacks.rules         46        0         46
[+] web-cgi.rules             348       2         350
[+] web-client.rules          9         16        25
[+] web-coldfusion.rules      35        0         35
[+] web-frontpage.rules       35        0         35
[+] web-iis.rules             112       7         119
[+] web-misc.rules            300       28        328
[+] web-php.rules             115       11        126
[+] x11.rules                 2         0         2
                              =============================
                              13519     8229      21748

[+] Generated iptables rules for 13519 out of 21748 signatures: 62.16%

[+] Logfile: /var/log/fwsnort/fwsnort.log
[+] iptables script (individual commands): /var/lib/fwsnort/fwsnort_iptcmds.sh


    Main fwsnort iptables-save file: /var/lib/fwsnort/fwsnort.save

    You can instantiate the fwsnort policy with the following command:

    /sbin/iptables-restore < /var/lib/fwsnort/fwsnort.save

    Or just execute: /var/lib/fwsnort/fwsnort.sh


root@2w1r:/usr/local/src/fwsnort-1.6.8# bash /var/lib/fwsnort/fwsnort.sh

[+] Splicing fwsnort 13519 rules into the iptables policy...
iptables-restore v1.8.4 (legacy): invalid port/service `!445' specified
Error occurred at line: 9043
Try `iptables-restore -h' or 'iptables-restore --help' for more information.

fwsnort_iptcmds.sh file output problem

### alert tcp $HOME_NET !80 -> $EXTERNAL_NET [!25,!445,!1500] (msg:"ET TROJAN Win32/BlackCarat XORed (0x77) CnC Checkin"; flow:established,to_server; dsize:>800; content:"|77 77|"; offset:2; depth:2; content:"|77|"; distance:1; within:1; content:"|77 77 77 77 77 77 77 77 77 77 77 77 77|"; distance:1; within:13; content:"|20 77 1e 77 19 77 13 77 18 77 00 77 04|"; distance:0; fast_pattern; content:!"|00 00 00 00 00 00|"; reference:md5,514AB639CD556CEBD78107B4A68A202A; reference:url,www.virusbulletin.com/uploads/pdf/conference_slides/2018/AncelKuprins-VB2018-WolfSheep.pdf; classtype:trojan-activity; sid:2026525; rev:6; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2018_10_18, deployment Perimeter, former_category MALWARE, malware_family BlackCarat, performance_impact Low, signature_severity Major, tag RAT, updated_at 2019_01_30;)
$IPTABLES -A FWSNORT_OUTPUT_ESTAB -p tcp -m tcp ! --sport 80 -m multiport ! --dports 25,!445,!1500 -m length --length 850:1550 -m string --hex-string "|20771e77197713771877007704|" --algo bm --from 77 -m string --hex-string "|7777|" --algo bm --from 66 --to 68 -m string --hex-string "|77|" --algo bm --from 69 --to 70 -m string --hex-string "|77777777777777777777777777|" --algo bm --from 66 --to 79 -m string ! --hex-string "|000000000000|" --algo bm -m comment --comment "sid:2026525; msg:ET TROJAN Win32/BlackCarat XORed (0x77) CnC Checkin; classtype:trojan-activity; reference:md5,514AB639CD556CEBD78107B4A68A202A; rev:6; FWS:1.6.8;" -j LOG --log-ip-options --log-tcp-options --log-prefix "[2295] SID2026525 ESTAB "
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp -m tcp ! --sport 80 -m multiport ! --dports 25,!445,!1500 -m length --length 850:1550 -m string --hex-string "|20771e77197713771877007704|" --algo bm --from 77 -m string --hex-string "|7777|" --algo bm --from 66 --to 68 -m string --hex-string "|77|" --algo bm --from 69 --to 70 -m string --hex-string "|77777777777777777777777777|" --algo bm --from 66 --to 79 -m string ! --hex-string "|000000000000|" --algo bm -m comment --comment "sid:2026525; msg:ET TROJAN Win32/BlackCarat XORed (0x77) CnC Checkin; classtype:trojan-activity; reference:md5,514AB639CD556CEBD78107B4A68A202A; rev:6; FWS:1.6.8;" -j LOG --log-ip-options --log-tcp-options --log-prefix "[7029] SID2026525 ESTAB "

is there a commandline force install method?

git pull ; install.pl --force

Using the emerging-all, it takes a long time and I'm not sure how far along it is to judge the duration.

André Nunes Batista reported the following issue to the Debian users list, and it should be fixed in the next release:

Hello debianers!

I run fwsnort to update and improve on my iptables rule sets. On
updating it's rules though I got this error message:

iptables-restore < /path/to/fwsnort.save

iptables-restore v1.4.14: Invalid hex char '|' Error occurred at line:
4013 Try `iptables-restore -h' or 'iptables-restore --help' for more
information.

The line mentioned on the error contains the rule bellow:

-A FWSNORT_OUTPUT_ESTAB -p tcp -m tcp -m string --string "PRIVMSG "
--algo bm -m string --hex-string "|2d2d2d2d2d2d2d2d2d2d2d2d||2d||2d||
2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||
2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||
2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||
2d||2d||2d||2d||2d||2d||2d||2d||2d||2d||2d|" --algo bm --from 72 -m
comment --comment "sid:2017291; msg:ET TROJAN ATTACKER IRCBot - PRIVMSG
Response - net command output; classtype:trojan-activity; rev:5;
FWS:1.6.2;" -j LOG --log-ip-options --log-tcp-options --log-prefix
"[3006] SID2017291 ESTAB "

Upon removing this line, iptables-restore did it's job without
complaining. Since this line was automagically generated by "fwsnort
--update-rules ; fwsnort --ipt-sync", I wonder if it's worth a bug
report.

On my opensuse 13.2 system, i don't have ifconfig and there's no package i can find to install so I use ip add, any suggestions on how to tweak this to make it work with that instead?

The excellent NetAddr::IP module should be used to replace the Net::IPv4Addr module.

This is distro specific info. Please reject/ignore if its not relevant to the project. I think there should be a readme/mention as to how to start fwsnort service on the Linux distributions.

The fwsnort service on Ubuntu does not start by default even after adding it in the startup.

The fix/workaround is to manually create a symlink - by which the fwsnort service starts after iptables-persistent service.

Ex:
Assuming runlevel is 2 - I have manually created a below symlink for fwsnort.

/etc/rc2.d# ls -l S38fwsnort S37iptables-persistent
lrwxrwxrwx 1 root root 29 Oct 2 13:16 S37iptables-persistent -> ../init.d/iptables-persistent
lrwxrwxrwx 1 root root 17 Sep 25 20:12 S38fwsnort -> ../init.d/fwsnort

By default if one uses the distro specific commands to enable fwsnort at bootup - the init script creates a wrong sequence ID (say number 20) which is lesser than sequence ID of iptables service - resulting in fwsnort not getting started on the bootup.

For your consideration / FYI - if you feel this helps this project.

Thanks

Michael:

Hey it's been super depressing coming across these poor abandoned Linux Security repos from the last few years.

I'm a weird situation now where I can just use IPTables essentially, so finding this produced the greatest joy Github has ever given me.

Thanks not only for working on this, but continuing for what seems like a decade+.

YOU ARE GREAT

• Dan Ehrlich

I just ran

apt-get install fwsnort
fwsnort --update-rules
fwsnort

and got this output:

[+] Testing /sbin/iptables for supported capabilities...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    Snort Rules File          Success   Fail      Total

[+] emerging-all.rules        0         23074     23074
                              =============================
                              0         23074     23074

[+] No rules parsed.

[+] Logfile: /var/log/fwsnort/fwsnort.log
[-] No Snort rules could be translated, exiting

Looks to me like just about every line, according to fwsnort.log, fails with an unsupported keyword "metadata".

Interestingly, -p ip was invalid on my system so i replaced it with -p all
referred to this http://ipset.netfilter.org/iptables.man.html

iptables v1.4.21: no command specified
Opensuse 13.2

cd /var/lib/fwsnort
fwsnort
sed -i "s/-p ip/-p all/g" fwsnort_iptcmds.sh
./fwsnort_iptcmds.sh

Recent RHEL and CentOS distros have moved to firewalld. fwsnort needs to support this.

With the recent move towards producing fwsnort iptables policies in iptables-save format, a more sensible default behavior is to not interpret the running iptables policy in order to exclude Snort rules that might not apply. This option was originally added as the default because before the iptables-save format was introduced it took a while to instantiate an fwsnort iptables policy. Also, since most Snort rules restrict themselves to established TCP connections, there is little penalty (other than a small amount of kernel memory) for instantiating Snort rules for which traffic is filtered out - such TCP connections would never make to the established state anyway.

Linux firewalling may move towards nftables, so this needs to be investigated for fwsnort compatibility.

Server OS: Ubuntu 18.04.5 LTS
Kernel: Linux 4.15.0-132-generic
Psad is installed.

I just installed fwsnort with no issues via apt-get install fwsnort.
After install I ran into some problems.

• A single log entry: iptables ipv4options extension not available, disabling ipopts translation.
• No chains have been inserted into iptables rules.
• The command fwsnort --ipt-apply ended up with
  /var/lib/fwsnort/fwsnort.sh does not exist. at /usr/sbin/fwsnort line 3410.

Indeed, fwsnort.sh doesn't exist in my filesystem. Neither in your repository, not in the download from CipherDyne nor in the Ubuntu package itself.

What is the iptables ipv4options extension? Is there a kernel module missing? Where can I find the fwsnort.sh?

I have extensively used fwsnort for about three years, follow along in the mailing lists, am using Linux Firewalls to train a coworker, etc.

I would like to donate in a structured way, along with my other open source donations.

Have you heard of Gratipay? Would you consider using it?

https://gratipay.com/on/github/mrash/

Add ipset support for Snort rules with large numbers of IP addresses. This feature was suggested by Imad Daou.

Hi,

I very much like the idea behind fwsnort, it seems to be a very nifty utility. I happened to try it out, but I have stumbled upon a few thing that are not quite clear to me.
I have attempted to find some answers in your book Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort, but I was only partially successful.

So, may I to ask you a few questions, please?

1. It seems that fwsnort has been cooperating mainly with snort-rules from emerging-threats.net and they are compatible as much as possible (I see why pcre field is hard to convert). However, Snort also features with their own native set of rules (regardless if with paid VRT subscription or not) and their format seems to be a bit different and fwsnort happens to fail on them completely.

Does fwsnort plan to support or test against these rules as well? I don't really understand why it seems not to, when these are the "primary" rules for Snort.

2. Digging a little deeper, I have learned a few reasons why Snort VRT rules don't work. Putting the pcre situations aside, often the problem is presence of:
   a) byte_test and byte_jump
   b) metadata field

From what I read in you book (page 171 - section Unsupported Snort Rule Options), byte_test, byte_jump and similar rely on u32 iptables module, which is now very much available for current kernels and iptables version. I have noticed that u32 support is also enlisted in your TODO. Do you think these features and u32 support might be available any time soon?

Regarding the metadata field, as I understand the situation, this usually describes either IPS action to be taken (e.g. drop) or some sort of extra information. In the first case, conversion to iptables seems clear to me (-j DROP perhaps), in the second case I can see that users might be okay with discarding this information in order to conversion otherwise to succeed.

Could you comment on these topic when you have a minute?

Regards,

Dan