[FIRMWARE] Itus Networks Shield Firmware Upgrade *WIP*

Question time.

I've already put out there that I really don't know Snort, so I'm checking to see if what I'm thinking is actually correct.

In Router mode, where there 2 snort instances running concurrently - one for the WAN, one for the LAN - rather than 1 instance that just covers both?  This is what it looks like from what I can see in the codebase.  Is this so you can have multiple rule sets, one less restrictive between eth1/eth2 (br-lan) and a heavier barrier over eth0?  Can anyone explain why this setup might be better than a single instance of snort covering both br-lan and eth0 at the same time?  Since a properly setup HOME_NET limits the IP scope (I'm currently using ipvar HOME_NET [10.0.0.0/8,172.16.0.0/12,192.168.1.0/16] instead of ipvar HOME_NET any, for example, with EXTERNAL_NET being !$HOME_NET)

---

If you reply to this email, your message will be added to the discussion below:

http://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1778.html

To start a new topic under Technical Discussion, email [hidden email]
To unsubscribe from Itus Networks Owners Forum, click here.
NAML

Hey Roadrunnere42,

My test versions are running Snort 2.13.9 (latest non-beta version).  I'm not sure about previous versions, but my current test is running a single Snort Config with DAQ afpacket (nfq isn't working right at the moment, I'm looking into it) in inline mode covering both eth0 and br-lan.  I have noticed that doing this, I can no longer use SSH to github, so I think there is a rule blocking outbound ssh.  This is why I was asking about the concurrently running Snort (one for WAN, one for LAN).  snort7/snort8 was setup this was, right?  Any idea which one was which?

I asked about you and Lua because I saw that most of the commits on Github were credited to you :)

I do my testing on the Shield itself.  Because I use the Gateway slot, I can leave the other two slots alone.  This allows me to do a recovery if I have to without going through the tftp process.  I'll point out that the only difference between the 3 modes is the image uboot picks on boot.  Programmatically, there isn't anything that keeps "Gateway" from being "Router", for example.

If you want a test build, I'll email you a send.firefox.com link and you can follow the directions in the first post.

The question is, do you want a version that doesn't change the mmcblk1p3 mount (changes don't survive reboots) or one that does (changes will survive reboots).  If you're not using the Gateway spot, the one that changes the mmcblk1p3 is best, since it allows you to experiment more.  Just let me know.

If you WANT to build out from source, you should be able to by getting the github source.  The only thing that might cause issues in building out the source yourself is the fact that I haven't kept track of what host packages are required, so you'd probably have to work through the build dependencies when they error.  My ubuntu box serves no purpose other than development, so I have no issues with throwing any packages on the system that I need .

Anyway, let me know..

Roadrunnere42 wrote

Hi Grommish
I was under the impression that snort could not do multi tasking, so itus
has one instant of snort running on each core, I could be wrong.

With regards to doing Lua for luCi i did look into it a few years back but
could not work out do i learn Lua or luCi. I could not find any learning
docs for luCi.

How are you doing testing with openwrt on the Shield, do you work things
out in a vm running openwrt and then copy to the Shield?

I also ran ipvar HOME_NET [10.0.0.0/8,172.16.0.0/12,192.168.1.0/16] instead
of ipvar HOME_NET any on my Shield, but left it out on any upgrade because
it had a side effect which messed things up for some people, but you right
not to use  ipvar HOME_NET any.

Do i have to build a firmware image from github and then copy over a you
said at the beginning of these emails.

Roadrunnere42

---

If you reply to this email, your message will be added to the discussion below:

http://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1780.html

To start a new topic under Technical Discussion, email [hidden email]
To unsubscribe from Itus Networks Owners Forum, click here.
NAML

Roadrunnere,

I'm beginning to suspect your assumption on why there were 2 snorts might be right.  The configurations seem identical, which you wouldn't suspect would be the case if they were actually different.

I did find some interesting things though.

If I switch from nfq to afpacket, I can span the interfaces (eth0:br-lan) and do a spread.

      PACKET_FANOUT (since Linux 3.1)
              To scale processing across threads, packet sockets can form a fanout group.  In this mode, each matching packet is
              enqueued onto only one socket in the group.  A socket joins a fanout group by  calling  setsockopt(2)  with  level
              SOL_PACKET  and  option  PACKET_FANOUT.  Each network namespace can have up to 65536 independent groups.  A socket
              selects a group by encoding the ID in the first 16 bits of the integer option value.  The first packet  socket  to
              join  a  group implicitly creates it.  To successfully join an existing group, subsequent packet sockets must have
              the same protocol, device settings, fanout mode and flags (see below).  Packet sockets can leave  a  fanout  group
              only by closing the socket.  The group is deleted when the last socket is closed.

              Fanout supports multiple algorithms to spread traffic between sockets, as follows:
              *  The  default mode, PACKET_FANOUT_HASH, sends packets from the same flow to the same socket to maintain per-flow
                 ordering.  For each packet, it chooses a socket by taking the packet flow hash modulo the number of sockets  in
                 the group, where a flow hash is a hash over network-layer address and optional transport-layer port fields.

              *  The load-balance mode PACKET_FANOUT_LB implements a round-robin algorithm.

              *  PACKET_FANOUT_CPU selects the socket based on the CPU that the packet arrived on.

              *  PACKET_FANOUT_ROLLOVER processes all data on a single socket, moving to the next when one becomes backlogged.

              *  PACKET_FANOUT_RND selects the socket using a pseudo-random number generator.

              *  PACKET_FANOUT_QM  (available  since  Linux 3.14) selects the socket using the recorded queue_mapping of the re‐
                 ceived skb.

              Fanout modes can take additional options.  IP fragmentation causes packets from the same flow  to  have  different
              flow  hashes.   The flag PACKET_FANOUT_FLAG_DEFRAG, if set, causes packets to be defragmented before fanout is ap‐
              plied, to preserve order even in this case.  Fanout mode and options are communicated in the second 16 bits of the
              integer  option value.  The flag PACKET_FANOUT_FLAG_ROLLOVER enables the roll over mechanism as a backup strategy:
              if the original fanout algorithm selects a backlogged socket, the packet rolls over to the next available one.

I was going to specify config daq_var: fanout_type=lb and config daq_var: fanout_flag=defrag, although some of the other ones might be worth looking at.  

Does anyone have any way to stress-test Snort to test for throughput?

---

If you reply to this email, your message will be added to the discussion below:

http://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1785.html

To start a new topic under Technical Discussion, email [hidden email]
To unsubscribe from Itus Networks Owners Forum, click here.
NAML

https://github.com/Grommish/Itus_Shield_v2/blob/master/files/etc/snort/rotatelogs

This is the script i ended up going with.  It'll save the newest 5 alert.fast.xxxxx by timestamp in /etc/snort/logs and kill the rest off, but only after pulling any Priority 1 alerts/drops.

I know Road is on the road without email for the next 2 weeks, but he'll catch up..  @Gnomad and @user8446, currently it only pulls the Priority 1 logs from the existing alert.fast.xxxx before it culls them, but it's triggered every 30 minutes.  Should the file results be appended or overwritten (currently it's overwriting them)?  I'm thinking appending, since I'd hate for any Priority 1 logs to be lost.  of course, it's sitting in RAM, so if it reboots, it'll be gone.. Maybe it should be written to disk instead.  this way a DDNS/RCE crash bug can't just clear the history..

---

If you reply to this email, your message will be added to the discussion below:

http://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1789.html

To unsubscribe from [FIRMWARE] Itus Networks Shield Firmware Upgrade *WIP*, click here.
NAML

One of the reasons I was looking into the F2FS (Flash Friendly File System) was because it incorporates wear-leveling, which helps with the destructive writes shortening the life.

Currently, I am moving the alert.fast.xxxx files (1mb each) to /etc/snort/logs, pulling out the Priority 1 logs and saving them on disk, then removing everything but the last 5 logs (by timestamp).  I'm crontab'ing this every half an hour.  You're right about the logs getting get many and large quickly, and I understand the concern.

What about this..

Every 30 minutes, pulling the Priority 1 alerts/drops out and storing that on disk, but instead of moving/removing the alert.fast.xxxx files, just removing all but the "newest" 4 (not counting the active alert.fast file) to keep the RAM from getting filled up.

This way, we can remove almost all of the MMC writes AND free up RAM.

Thoughts on this strategy?

---

If you reply to this email, your message will be added to the discussion below:

http://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1791.html

To unsubscribe from [FIRMWARE] Itus Networks Shield Firmware Upgrade *WIP*, click here.
NAML

Every Shield has a embedded Flash card.. It's what the MMC (Multi-Media Card) in /dev/mmcblk0 means :D

It's an embedded Flash card, basically..  I wasn't referring to the front-panel SD card slot.

I'm not sure if stock luCi has the cron page, but I can certainly pull it if it doesn't.  i did notice that the cron service was disabled by default, I had to enable and start it. I'll need to figure out how to make sure it's started by default in the image.

The front-panel SD slot *should* work out of the box if anyone ever wanted to use it, but I've never bothered to check.  The drivers are there for it though.

Gnomad wrote

Sounds reasonable!  The original shield luci had a page showing all the
custom crons - is that something you've pulled over?
If so, people can always tweak the timing to their own requirements
anyway.

Note that (from memory) not all shield models have the MMC slot, and for
other users an MMC card might not be inserted - so you'll want an
availability detection check upfront regardless.

---

If you reply to this email, your message will be added to the discussion below:

http://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1793.html

To unsubscribe from [FIRMWARE] Itus Networks Shield Firmware Upgrade *WIP*, click here.
NAML