Simple way to add an additional sensor without breaking sec-onion or reconfiguring from scratch?
Christian Henderson
One more question. Is there a simple way to add an additional sensor interface without rebuilding sec-onion from scratch or hacking the configs? I've tried rebuilding sec-onion and switching sensors, i've tried manually running nsm_sensor_ps-add, and no matter what I do when I try to add an additional sensor or manually start copying say /etc/nsm/sensor1 /etc/nsm/sensor2 - everything starts to break (i know that's general, but literally snorby/squert/ELSA all start having problems when I try to add in another sensor. Is there a sensor-add script that will add the additional interface without breaking the original one created during setup? Any links or tips on adding an additional sensor to snorby/sguil/squert/ELSA would be appreciated. Thanks! CH
Doug Burks
Here are a few options:
- Re-run Setup. Quick and easy, but deletes your existing config/data.
- Manually run the same commands that Setup runs to add the additional
sensor interface. Take a look at the commands inside of
/usr/bin/sosetup. This is a manual process and error-prone, but I
hope to make it easier some day.
- When you first run Setup on a box, go ahead and configure all
interfaces that may be some day be used for sniffing. If you don't
need all of them immediately, you can then disable the unneeded
interfaces. When they are needed, simply re-enable them and they're
already configured.
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/groups/opt_out.
--
Doug Burks
Andrew Colfelt
> [...]
> - Manually run the same commands that Setup runs to add the additional
> sensor interface. Take a look at the commands inside of
> /usr/bin/sosetup. This is a manual process and error-prone, but I
> hope to make it easier some day.
Oh man, interesting project !
Great learning exercise... if only I could make the time for it !
I don't suppose you could jump-start me here, by highlighting the blocks of code is sosetup that are pertinent ?
I've just done a quick peruse and it all seems pretty approachable, but without learning the entire script inside-and-out, it's hard to see the dependency chain. If all those blocks were highlighted for me, I reckon I could make a reasonable contribution to the effort, if not finish it off myself.
> - When you first run Setup on a box, go ahead and configure all
> interfaces that may be some day be used for sniffing. If you don't
> need all of them immediately, you can then disable the unneeded
> interfaces. When they are needed, simply re-enable them and they're
> already configured.
Filed under: "Sage advice for avoiding the traps for young players !"
Doug Burks
> On Tuesday, February 18, 2014 6:14:42 AM UTC-7, Doug Burks wrote:
>> [...]
>> - Manually run the same commands that Setup runs to add the additional
>> sensor interface. Take a look at the commands inside of
>> /usr/bin/sosetup. This is a manual process and error-prone, but I
>> hope to make it easier some day.
>
> Oh man, interesting project !
>
> Great learning exercise... if only I could make the time for it !
>
> I don't suppose you could jump-start me here, by highlighting the blocks of code is sosetup that are pertinent ?
>
> I've just done a quick peruse and it all seems pretty approachable, but without learning the entire script inside-and-out, it's hard to see the dependency chain. If all those blocks were highlighted for me, I reckon I could make a reasonable contribution to the effort, if not finish it off myself.
# NIDS sensor(s)
for INTERFACE in $INTERFACES; do
--
Doug Burks
Ross Warren
--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.
BBCan177
> - When you first run Setup on a box, go ahead and configure all
> interfaces that may be some day be used for sniffing. If you don't
> need all of them immediately, you can then disable the unneeded
> interfaces. When they are needed, simply re-enable them and they're
> already configured.
> Doug Burks
Hi Doug,
I think this would be a great comment to add to the Sosetup script.
Thanks
Doug Burks
> I think this would be a great comment to add to the Sosetup script.
I think what I'll do is have Setup configure all available sniffing
interfaces and then prompt for which of those interfaces should be
enabled:
https://code.google.com/p/security-onion/issues/detail?id=525
--
Doug Burks
BBCan177
> Doug Burks
That works. I also think sosetup should display a comment to add sensors for "future consideration" until the the development of a script that can add an additional sensor automatically without re-installing and losing all of the existing data.
If I had seen that comment, I would have installed atleast one additional sensor on my server installation.
Just a thought.
Doug Burks
> On Thursday, April 17, 2014 12:18:25 PM UTC-4, Doug Burks wrote:
>> On Thu, Apr 17, 2014 at 12:08 PM, BBCan177 <bbca...@gmail.com> wrote:
>
>> I think what I'll do is have Setup configure all available sniffing
>> interfaces and then prompt for which of those interfaces should be
>> enabled:
>> https://code.google.com/p/security-onion/issues/detail?id=525
>>
>> Doug Burks
>
> That works. I also think sosetup should display a comment to add sensors for "future consideration" until the the development of a script that can add an additional sensor automatically without re-installing and losing all of the existing data.
be configured, just disabled. So after Setup completes, it would then
be a simple matter of editing /etc/nsm/sensortab and uncommenting any
interfaces that you want to enable.
Make sense?
BBCan177
That will work for new installations. Most new users don't read all of the wiki before hand, they just get all excited about seeing SO in action!
Andrew Colfelt
[...]
> Take a look at the code block that begins like this:
>
> # NIDS sensor(s)
> for INTERFACE in $INTERFACES; do
I took a swipe at this, which I am happy to share for review.
But there appears to be a piece missing somewhere.
Initial Config:
eth0: management
eth1: monitoring
eth2: unconfigured device, intended to be added as another monitoring interface by my [#NIDS -> #Bro] hack of sosetup.
My hack appears to be successful in setting up a new sensor interface; all these things look about right ( to my novice eye ):
/etc/nsm/sensortab
/etc/nsm/soTEST-eth2/
/nsm/sensordata/soTEST-eth2/
but sudo service nsm status reveals:
* starting: prads (sessions/assets) [ FAIL ]
- check /var/log/nsm/soTEST-eth2/prads.log for error messages
...and /var/log/prads.log reveals:
[!] Error pcap_open_live: eth2: That device is not up
ifconfig shows:
eth0: OK
eth1: OK
lo: OK
...but eth2 does not exist...
Does this suggest that I should be including another step in my script, beyond just hacking sosetup between #NIDS through Bro, and all relevant variables ?
Doug Burks
You most likely need to add eth2 to /etc/network/interfaces and then
bring the interface up:
https://code.google.com/p/security-onion/wiki/NetworkConfiguration
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
--
Doug Burks
Andrew Colfelt
>
> You most likely need to add eth2 to /etc/network/interfaces and then
>
> bring the interface up:
>
> https://code.google.com/p/security-onion/wiki/NetworkConfiguration
Ok, that resolved the error revealed in prads.log.
One more thing doesn't quite look right, revealed by:
# sudo service nsm status
----------------------------------
Status: Bro
Name Type Host Status Pid Peers Started
soTEST-eth2-1 worker 10.10.10.137 crashed
soTEST-eth2-2 worker 10.10.10.137 crashed
manager manager 10.10.10.137 running 16404 3 28 Apr 16:00:37
proxy proxy 10.10.10.137 running 16442 3 28 Apr 16:00:39
soTEST-eth1-1 worker 10.10.10.137 running 16521 2 28 Apr 16:00:42
soTEST-eth1-2 worker 10.10.10.137 running 16519 2 28 Apr 16:00:42
----------------------------------
Note that the new sensor-interface shows "crashed".
This behavior persists across a reboot.
Doug Burks
sudo broctl install
sudo broctl restart
Andrew Colfelt
> Have you tried the following?
>
> sudo broctl install
> sudo broctl restart
That cleaned things up nicely.
To refine my understanding of broctl install/restart:
- is 'sudo service nsm stop' required before 'broctl install' ?
- would 'sudo reboot' also achieve the result of 'broctl restart'
- if I were to remove a sensor with 'sudo nsm_sensor_del --sensor-name=$SENSORNAME -d', would I also want to re-run 'broctl install' to propagate the change in interfaces ?
It's starting to feel like we're getting somewhere with this, at least to a point where a sufficiently motivated user can get to the destination without too much effort ( stand-alone advanced config only, so far ).
With a few zenity data-collection elements, and perhaps a little logic to handle more than one configuration situation, this could be improved substantially.
With such a product, existing installations can be adjusted painlessly, and with the proposed update to sosetup (https://code.google.com/p/security-onion/issues/detail?id=525), the waterfront might be covered.
Ross Warren - is there any place for this work in the product you've been working on ?
Doug Burks
On Mon, Apr 28, 2014 at 9:46 PM, Andrew Colfelt <abwco...@gmail.com> wrote:
> To refine my understanding of broctl install/restart:
> - is 'sudo service nsm stop' required before 'broctl install' ?
> - would 'sudo reboot' also achieve the result of 'broctl restart'
> - if I were to remove a sensor with 'sudo nsm_sensor_del --sensor-name=$SENSORNAME -d', would I also want to re-run 'broctl install' to propagate the change in interfaces ?
--
Doug Burks
Andrew Colfelt
This thread represents a loosely-organized "procedure" to add a 2nd interface to a sensor, without losing existing nsm data and config.
Although I achieved several incremental victories with this procedure in the lab, it (still) has not been used by me in production, and so I have not yet concluded that it is ready for prime time, mostly because I have not worked on it in a while, and I never got around to bottling all the steps into a single script.
Nevertheless, it is a giant head-start, and for all I know, taken as a whole, it may work perfectly for adding a 2nd interface... as long as that interface is named "eth2"...
I will get back to this project in the next month or so.
Meanwhile, this "procedure" should be considered somewhat dangerous because it appears to be more than it is: an early beta for the intended result...
If anyone else wants to take another swipe at this, please share your findings here.
TJ
Sorry to resurrect an old thread, but I was wondering if this change ever occurred? If so, how can I tell if my interfaces are configured, but not enabled VS. not configured and not enabled?
Thank you!
TJ
Doug,
Thanks for the reply. I removed the "#" from the interface I want to enable in \etc\nsm\sensortab. After a reboot the interface shows up in sostat, I have an error though.
Status: <hostname>-eth1
* netsniff-ng (full packet data)[ OK ]
* pcap_agent (sguil)[ OK ]
* snort_agent (sguil)[ OK ]
* suricata (alert data)[ FAIL ]
* stale PID file found, process will be restarted at the next 5-minute interval!
* barnyard2 (spooler, unified2 format)[ OK ]
The last few lines of my /var/log/nsm/<hostname>-eth1/suricata.log file:
27/7/2015 -- 18:05:41 - <Error> - [ERRCODE: SC_ERR_PF_RING_OPEN(34)] - Failed to open eth1: pfring_open error. Check if eth1 exists and pf_ring module is loaded.
27/7/2015 -- 18:05:41 - <Error> - [ERRCODE: SC_ERR_THREAD_INIT(49)] - thread "RxPFReth11" closed on initialization.
27/7/2015 -- 18:05:41 - <Error> - [ERRCODE: SC_ERR_INITIALIZATION(45)] - Engine initialization failed, aborting...
I'm thinking that I am missing an interface configuration somewhere. I'll continue searching, but if you can point me in the correct direction it would be appreciated.
Thanks
TJ
TJ
To add the monitoring interface, this is what I've done so far:
-- \etc\nsm\sensortab -- remove the # from the interface I wanted to monitor (this also generated the error above)
-- edit \etc\network\interfaces to add/enable the same interface as a promisc interface (cleared the error above)
# Manually added interface configuration for eth1
auto eth1
iface eth1 inet manual
up ip link set $IFACE1 promisc on arp off up
down ip link set $IFACE1 promisc off down
post-up ethtool -G $IFACE1 rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE1 $i off; done
post-up echo > /proc/sys/net/ipv6/conf/$IFACE1/disable_ipv6