Is there any implementation for openwrt an ips / ids like suricata or snort?

if no, what is required to start and port one from bsd or anything?

[OpenWrt Wiki] Snort.

(as an aside, if this is to be the first of similar posts maybe try checking the wiki before posting? Or a simple google search)

im sorry , last time i checked few years found nothing

sad this does not have a gui like pfsense, is there any way i could collab to create a gui in luci for it?

have your team tought about making some kind of * a must have* requirement, to have a gui in luci for required packages?, it would be a substancial improvement for openwrt users, so less experienced could have it easier, for example ban ip now haves luci ui and they are working on a newer version for it

would be a great idea: to include * a must have * requirement of an ui so less tech savy users would use such packages

ok so can i make a fork or how come? i have never done collab in any open source project- dont know how to start: any small briefing ? as open source i know any experienced can collab but as told before i've never done it and would like to sum up

A Suricata port has been attempted, but the Rust port was too old and getting in the way. I haven't seen any progress on it for a year or two.

Snort configuration is discussed in detail on this thread. Maybe start at the bottom. I'm in the process of vastly expanding the config file and supporting scripts (see the tarball linked near the end of the thread).

One caveat: you'll need at least a 1GB RAM device to get snort working, it is a huge memory hog. Also it's good if you have a lot of CPU, might work on some high end ARM, but I'd also suggest x86 to be safe.

1 Like

oh.. so no hope of snort or suricata working correctly on mips soc nor arm because most buffed routers have 256 mb of ram not 1gb, unless you use an usb drive as swap...

so we got a snort package but is not really working because of hardware limitations

:sigh: ....


Yeah, unlikely that it will run well on a 256M box, the initial process on my x86 instances consumes about 120M just to start, and that's after lots of tuning and only running it in pcap-IDS mode. If you turn on IPS, then that number about doubles (probably due to the way snort defrags packets when in nfq-IPS mode).

1 Like

i heard suricata is better (pulls less memory)

Yeah, that's what I've heard, too. It's a more modern piece of code and looks to be more widely used, so I'd expect it to be better all around, but it still needs work. I think the recent rust updates with newer kernels will help there, but I don't see anyone interested recently.

512mb of ram is a lot considering we re talking about typical routers... is sad , looks like we wont see in any close future an ids ips running on typical 8 16 hardware

ok but looks it is not working so we got package but not working also pulling lot of ram

looks like we will not see in near future ips ids for normal openwrt powered devices

As an example, I tried running snort3/IPS mode on an Intel N95 (x86) and throughput was CPU limited. As I recall 400-600 MBps depending. I switched to a more powerful AMD 5800U (x86) and am not limited,

1 Like

would be a nice idea to make it work for wrt x86 x64 and make it a very good competence against those BSD based routers but we all know snort sniffs a lot of ram and cpu mainly and the norm soc mips or soc not potent arm chips for now

Yeah, with the full default set of rules, the memory footprint is 1.1-1.2 G.


John, was that with your custom build including the Intel pattern matching accelerators?

I think so but I am not 100% sure given all the changes made. I have since returned that hardware so have no way of knowing.

Years ago there was a OpenWrt fork with Snort integrated and it worked great and had LuCI integration but the company went under. I'm actually still using the appliance now as a router as it has been mainlined into OpenWrt (

Maybe you can take some bits from the gui instead of starting from scratch:

It's quite fun to dig through all the changes since then. Particularly, that LuCI is working towards eliminating Lua, while the transition from snort to snort3 gained Lua as its configuration language.

Their packaging of snort appears to have favored end-user simplicity, with a handful of prepackaged configurations, and in LuCI you just picked one of them (so it's a simple dropdown and only a couple settings).

Here's their config:

config snort 'snort'
	option config_file1 '/etc/snort/profile/config1_advanced.conf'
	option config_file2 '/etc/snort/profile/config2_engine.conf'
	option config_file3 '/etc/snort/profile/config3_preprocessors.conf'
	option config_file4 '/etc/snort/profile/config4_other.conf'
	option profile 'snort'
#	option interface ''

My current approach is a more general, option-based one, where the config file is quite rich, with lots of complexity for the user, but much greater ability to make choices (that's always the tradeoff isn't it).

Compare my current default config (yow):

# This is not an exhaustive list of configuration items, just those that
# require more explanation than is given in the tables that define them, below.
# snort
#     interface       - default should usually be 'uci get network.wan.device',
#                       something like 'eth0'
#     mode            - 'ids' or 'ips', for detection-only or prevention, respectively
#     oinkcode        -
#     config_dir      - Location of the base snort configuration files.  Default /etc/snort
#     temp_dir        - Location of all transient snort config, including downloaded rules.
#                       Default /var/snort.d
#     log_dir         - Location of the generated logs, and oh-by-the-way the snort
#                       PID file (why?).  Default /var/log
#     action          - 'alert', 'block', 'reject' or 'drop'
#     method          - 'pcap', 'afpacket' or 'nfq'
#     snaplen         - int daq.snaplen = 1518: set snap length (same as -s) { 0:65535 }
# nfq -
#     queue_maxlen    - nfq's '--daq-var queue_maxlen=int'
#     queue_count     - Count of queues to use when method=nfq, usually 2-8.
#     thread_count    - int snort.-z: <count> maximum number of packet threads
#                       (same as --max-packet-threads); 0 gets the number of
#                       CPU cores reported by the system; default is 1 { 0:max32 }
#     chain_type      - Chain type when generating nft output.
#     chain_priority  - Chain priority when generating nft output.
#     include         - Full path to user-defined extra rules to include inside queue chain.
config snort 'snort'
        option enabled         '1'              # one of [0, 1]
        option oinkcode        ''               # a string
        option config_dir      '/etc/snort'     # a path string
        option temp_dir        '/var/snort.d'   # a path string
        option log_dir         '/var/log'       # a path string
        option logging         '1'              # one of [0, 1]
        option mode            'ids'            # one of [ids, ips]
        option method          'pcap'           # one of [pcap, afpacket, nfq]
        option action          'alert'          # one of [alert, block, drop, reject]
        option interface       'eth0'           # a string
        option snaplen         '1518'           # 1518 <= x <= 65535

config nfq 'nfq'
        option queue_count     '4'              # 1 <= x <= 16
        option queue_start     '4'              # 1 <= x <= 32768
        option queue_maxlen    '1024'           # 1024 <= x <= 65536
        option thread_count    '0'              # 0 <= x <= 32
        option chain_type      'input'          # one of [prerouting, input, forward, output, postrouting]
        option chain_priority  'filter'         # one of [raw, filter, 300]
        option include         ''               # a path string

Very nice what you are doing there!

Yes I remember the config in LuCI was aimed for the novice and anything advanced would just be changed in snort.conf directly

1 Like