Copy snort config to new interface?
-
I've added a second interface to my system and want to have it monitored by Snort much as my WAN interface is. Is there an easy way to copy all the configuration settings I have on the working interface to the new one? Guess I was hoping for something line the "+" option under Rules.
Rick
-
Hi Rick this will be available in the next release of snort. Bill has already added the functionality to duplicate the settings of an existing interface. We are waiting for the devs to approve the changes and release the package.
See the following thread:
-
WooHOO! Thanks!
I'll just sit tight and wait for that.
Rick
-
WooHOO! Thanks!
I'll just sit tight and wait for that.
Rick
The Pull Request is still waiting for approval and merging by the pfSense Core Team. Hopefully they can get to it soon.
Bill
-
hi
how to install snortsam?
keep in touch
-
hi
how to install snortsam?
keep in touch
snortsam is not currently supported AFIK on pfSense. There was some early work done by a prior package developer, but I don't think it ever even became an ALPHA package.
Bill
-
Bill, I just installed the lastest update. Not seeing the interface add option with duplication. Is it something I have to enable? Looked around but just don't see it. I still just have "add", "edit" or "nix" icons. Did the Devs kill that piece?
rick
-
Bill, I just installed the lastest update. Not seeing the interface add option with duplication. Is it something I have to enable? Looked around but just don't see it. I still just have "add", "edit" or "nix" icons. Did the Devs kill that piece?
rick
That update was not mine. The pfSense team bumped the version number because they recompiled all the PBIs with an updated OpenSSL. It's exactly the same GUI code as 3.0.8.
My Pull Request with the feature you want is still pending their approval and merge. Just in case someone gets around to it, I bumped it up to 3.10.
Bill
-
ahhhhh….
Thanks Bill, I'll keep waiting
Rick
-
ahhhhh….
Thanks Bill, I'll keep waiting
Rick
I'll send the team another e-mail and ask if they can expedite the review.
Bill
-
another week…. Obviously, you are more highly thought of on the forum than by the "core team"
Rick
-
another week…. Obviously, you are more highly thought of on the forum than by the "core team"
Rick
I sent the e-mail and received no response at all. Getting discouraging… :'(.
Bill
-
another week…. Obviously, you are more highly thought of on the forum than by the "core team"
Rick
I sent the e-mail and received no response at all. Getting discouraging… :'(.
Bill
Keep up the good work Bill… Without you there would be no "us" in here…
To put it into perspective the Snort/Suricata Packages have come such a long way since you have taken over its Management! :)
I hope the Devs realize that..... We all do.. :) :)
-
Keep up the good work Bill… Without you there would be no "us" in here…
To put it into perspective the Snort/Suricata Packages have come such a long way since you have taken over its Management! :)
I hope the Devs realize that..... We all do.. :) :)
Agreed!!!
-
Bill,
Looks like 3.10 finally got the nod. I'm spent, I'll attack it in the morning.Thank you!
Rick
-
Bill,
Looks like 3.10 finally got the nod. I'm spent, I'll attack it in the morning.Thank you!
Rick
Unfortunately this update still does not contain my GUI code changes to add the DUP (copy interface) function. This was instead some additional security tweaks to the PHP code for passed parameters.
Bill
-
#$%?!!#$%&(#@!!!!!!
-
#$%?!!#$%&(#@!!!!!!
I did hear from the pfSense developers this afternoon. They apologized for being so far behind with packages review. They have been very busy with 2.1.4 of pfSense. I have a few edits to make to the Pull Request that I will do this weekend, and then hopefully we can get it merged into production early next week.
Bill
-
Is there a user accessible page for versioning information?
I ask because it seems to have ramped up several versions the last couple of days?Rick
-
Is there a user accessible page for versioning information?
I ask because it seems to have ramped up several versions the last couple of days?Rick
You can look at the Commits history on the Github repository for pfsense-packages here: https://github.com/pfsense/pfsense-packages/commits/master.
Each code update will be posted there. For example, you can see that one of the devs merged two of my recent Pull Request commits this morning. The others are still under review and outstanding. You can see open Pull Requests on the same repository at this link: https://github.com/pfsense/pfsense-packages/pulls.
My other changes are under review. The guys are working down some backlogged requests, so let's give them a bit of extra time.
Bill
-
Bill,
OK, so I'm confused….. or did the devs hijack your version 3.0.13??
I updated, it says 3.0.13 but the "CANCLE" typo is still there and no copy feature on the interfaces.While I was doing some cleaning today, I thought I'd try that "emerging-web_client rule 2011695" again its still not fixed either... maybe we should start an over/under pool on which one gets released first?
I'm not complaining, just letting you know what I found.
Waiting, patiently,
Rick
-
Bill,
OK, so I'm confused….. or did the devs hijack your version 3.0.13??
I updated, it says 3.0.13 but the "CANCLE" typo is still there and no copy feature on the interfaces.While I was doing some cleaning today, I thought I'd try that "emerging-web_client rule 2011695" again its still not fixed either... maybe we should start an over/under pool on which one gets released first?
I'm not complaining, just letting you know what I found.
Waiting, patiently,
RickYes, a bit more confusion. One of the devs made an edit to beef up security on two of the PHP pages. That edit contained a bug that actually killed the "return to previous page" feature. I submitted a fix for that in with all my other updates. He merged only the "fix" for his error and not the other updates. They are still under review by a different Core Team developer. I'm still hoping for approval and merge this week. Here is the link to my open Pull Request: https://github.com/pfsense/pfsense-packages/pull/678
Bill
-
Bill,
I haven't given up on you, Buddy… but did the Devs forget about this?? :o
Its been 6+ weeks.Rick
-
Bill,
I haven't given up on you, Buddy… but did the Devs forget about this?? :o
Its been 6+ weeks.Rick
Yes and no. They wanted me to make two more changes which I completed this past Monday. I notified them of the update, but have heard nothing else. I will bump them again.
Bill
-
One of the other heroes on this fine forum ;D
Were you perhaps planning to provide the same for Suricata, Bill? As some consensus seems to be to ditch Snort and use Suricata, which is what I am now, as a brave puppy, am migrating to :P
EDIT: me retarded; it is already there :o
Ok then, another question ( ;D ): I do recall this was discussed some months ago, but have lost track of the subject: jflsakja is giving a tuto on what rules to disable. That will be a lot of work. Is there a way to do this for one interface (LAN) and then copy these settings over to another interface (VLANx)?
Or shall we stick with deleting the VLANx and re-creating it by basing it on the edited LAN-interface?
(Might be a lot of work with many interfaces, and, moreover if you have to change a rule incidentally after the initial setup, as then you will end up deleting and recreating interfaces as well).
Perhaps a simple shell script to apply the settings from one interface to all the others? Or a shell script that automatically deletes and re-creates the interfaces?
Just being the eternal noob here ;D
EDIT2 (for the 2014 ultimate noob award): if Suricata/Snort could be ran on interface groups, that would be an efficient solution. I am sure this is either not possible or an insane amount of work, just suggesting it in case somebody else will generate a smart spin off thought of this idea that could work ;D
-
@Hollander:
One of the other heroes on this fine forum ;D
EDIT2 (for the 2014 ultimate noob award): if Suricata/Snort could be ran on interface groups, that would be an efficient solution. I am sure this is either not possible or an insane amount of work, just suggesting it in case somebody else will generate a smart spin off thought of this idea that could work ;D
Agree with the hero call!
Don't know if the concept of "interface group" is feasible or not, but I like it!!
Rick
-
Yes and no. They wanted me to make two more changes which I completed this past Monday. I notified them of the update, but have heard nothing else. I will bump them again.
Thanks Bill, I'll keep waiting.
-
Yes and no. They wanted me to make two more changes which I completed this past Monday. I notified them of the update, but have heard nothing else. I will bump them again.
Thanks Bill, I'll keep waiting.
I replied also to your PM.
Bill
-
@Hollander:
One of the other heroes on this fine forum ;D
Were you perhaps planning to provide the same for Suricata, Bill? As some consensus seems to be to ditch Snort and use Suricata, which is what I am now, as a brave puppy, am migrating to :P
EDIT: me retarded; it is already there :o
Ok then, another question ( ;D ): I do recall this was discussed some months ago, but have lost track of the subject: jflsakja is giving a tuto on what rules to disable. That will be a lot of work. Is there a way to do this for one interface (LAN) and then copy these settings over to another interface (VLANx)?
Or shall we stick with deleting the VLANx and re-creating it by basing it on the edited LAN-interface?
(Might be a lot of work with many interfaces, and, moreover if you have to change a rule incidentally after the initial setup, as then you will end up deleting and recreating interfaces as well).
Perhaps a simple shell script to apply the settings from one interface to all the others? Or a shell script that automatically deletes and re-creates the interfaces?
Just being the eternal noob here ;D
EDIT2 (for the 2014 ultimate noob award): if Suricata/Snort could be ran on interface groups, that would be an efficient solution. I am sure this is either not possible or an insane amount of work, just suggesting it in case somebody else will generate a smart spin off thought of this idea that could work ;D
The new DUP (duplicate) feature in Suricata should copy over ALL the settings except for interface name and whitelist/homenet settings. Those go to defaults. So any enabled/disabled rules and their associated categories should already get copied over in Suricata. This is also in the Snort update awaiting pfSense devs approval.
The Interface Groups would be a lot of work, I think.
Bill
-
The new DUP (duplicate) feature in Suricata should copy over ALL the settings except for interface name and whitelist/homenet settings. Those go to defaults. So any enabled/disabled rules and their associated categories should already get copied over in Suricata. This is also in the Snort update awaiting pfSense devs approval.
The Interface Groups would be a lot of work, I think.
Bill
Thank you Sir Bill ;D
I had no doubt it would be a huge amount of work to use Interface Groups.
Just for my understanding, about the new DUP feature:
1. It isn't already there, right? (I am looking but can't see it; only the option to create a new interface based on another one).
2. Will it be just copy the config from interface 1 to interface 2, or will it be create a new interface based on an existing one? Because if the latter, suppose I have 10 VLANs and find a change necessary on LAN which I also want on the 10 VLANs, I'd have to first delete the 10 VLAN's from Suricata and then recreate them based on the changed LAN. So that might be a lot of work. If, on the other hand, the first, so copy only the config settings from LAN to the 10 VLANs, then it would be extremely workable.At least that is what I was thinking 10 seconds ago ;D
-
What would be an even better solution, would be the option to put all of the Virtual Interfaces into a group and have only one Snort/Suricata Interface to handle them all.
That would be a lot of memory usage to create 1 WAN and 10 vlan Snort/Suricata Interfaces.
If PulledPork was fully utilized, we could populate the enablesid and disablesid conf files, which would allow modifications to the Rules more efficiently than having to edit them one at a time, per interface per pfSense Box….
This debate has been going on since 2012 when Ermal was maintaining the package before Bill... https://forum.pfsense.org/index.php?topic=46101.0
-
@Hollander:
The new DUP (duplicate) feature in Suricata should copy over ALL the settings except for interface name and whitelist/homenet settings. Those go to defaults. So any enabled/disabled rules and their associated categories should already get copied over in Suricata. This is also in the Snort update awaiting pfSense devs approval.
The Interface Groups would be a lot of work, I think.
Bill
Thank you Sir Bill ;D
I had no doubt it would be a huge amount of work to use Interface Groups.
Just for my understanding, about the new DUP feature:
1. It isn't already there, right? (I am looking but can't see it; only the option to create a new interface based on another one).
2. Will it be just copy the config from interface 1 to interface 2, or will it be create a new interface based on an existing one? Because if the latter, suppose I have 10 VLANs and find a change necessary on LAN which I also want on the 10 VLANs, I'd have to first delete the 10 VLAN's from Suricata and then recreate them based on the changed LAN. So that might be a lot of work. If, on the other hand, the first, so copy only the config settings from LAN to the 10 VLANs, then it would be extremely workable.At least that is what I was thinking 10 seconds ago ;D
It should be there in Suricata, but only if you have a "currently open" interface. By that I mean either a physical interface or a VLAN that is not already in use by another instance of Suricata (or Snort when this feature is public in Snort). To illustrate, if you have a WAN and LAN and already have both configured for Suricata, then the DUP icons are hidden (or maybe grayed-out, I don't remember ATM). If you then go add an additional interface under Interfaces in the firewall menu, or create a VLAN, then the DUP icons should become active on the Suricata Interfaces tab.
It does not work like a "template". I lost that battle with the pfSense developers. They said "no" to that type of operation. Instead it was suggested to just use the DUP feature. It works just like the same feature with firewall rules (that is, create a new rule based on this one). It won't create a physical interface or VLAN. You must do that first manually, then come back to Suricata and you can duplicate an existing interface's settings over to the newly created interface or VLAN. Once done it's done. If you change the original interface, those changes do not automatically replicate to the copy. It's simply a point-in-time copy of the original.
Bill
-
It should be there in Suricata, but only if you have a "currently open" interface. By that I mean either a physical interface or a VLAN that is not already in use by another instance of Suricata (or Snort when this feature is public in Snort). To illustrate, if you have a WAN and LAN and already have both configured for Suricata, then the DUP icons are hidden (or maybe grayed-out, I don't remember ATM). If you then go add an additional interface under Interfaces in the firewall menu, or create a VLAN, then the DUP icons should become active on the Suricata Interfaces tab.
It does not work like a "template". I lost that battle with the pfSense developers. They said "no" to that type of operation. Instead it was suggested to just use the DUP feature. It works just like the same feature with firewall rules (that is, create a new rule based on this one). It won't create a physical interface or VLAN. You must do that first manually, then come back to Suricata and you can duplicate an existing interface's settings over to the newly created interface or VLAN. Once done it's done. If you change the original interface, those changes do not automatically replicate to the copy. It's simply a point-in-time copy of the original.
Bill
Thank you Sir Bill ;D
If I may: people like you and the other heroes should never have to be in a battle with the pfSense developers. I hope that the powers that be won't be angry at me for saying this, but there are three kinds of heroes on this board: obviously the pfSense developers, next the package- and script developers like you and the other great guys, and next the people who have extreme knowledge and simply answer noob questions time after time again (one of them still refuses me buying him a cup of coffee ;D ). All are equally important: together, these three groups of people, make pfSense the great product it is. None can go without the other.
Next: I have no indepth networking experience, but as I have confessed before: I have quite some extensive knowledge in ERP-systems. The big ones, not the SMB-ones. I worked in that for > 10 years and even have a nice little 'platinum architect' badge somewhere. From that, even I as an economist, learned: normalization. No hard coding, no 'we'll do that part in Excel/do it manually - every three days', but make things flexible, structured: so you can automate it.
So, if the TPTB will take this from a stupid economist who knows nothing about networking, but knows something about things that might even be more complex than networking - huge ERP systems: templates that you can apply are to be preferred.
I remember, a few years ago, having to approve an MDM (Master Data Management) upload of 14 billion records to the globally distributed ERP-servers. I approved it because I knew the templates with which the data was converted was sane. For the life of it I would have never approved it if I had to verify the 18000 conversion reports of all our workers across the globe. I think that huge Fortune500 company would have gone bankrupt within minutes due to wrong deliveries and law suites from vendors and customers across the globe.
It makes sense even from a stupid economist's point of view: computers are about automation. Don't do yourself what that machine can do for you automatically. Efficiency. More time to drink beer instead of doing the same repetitive (hello Mr. Ford ;D ) task over and over again until you reach your pension.
Stupid economists may mumble from time to time: simply ignore them at your will ;D
So, Bill: is there perhaps a way to apply the settings from LAN to VLANx via a script in the CLI?
Bye :P
-
@Hollander:
So, Bill: is there perhaps a way to apply the settings from LAN to VLANx via a script in the CLI?
Bye :P
Yes, this is technically possible, but the developers were not keen on the idea so I did not include it. All of the settings for an interface are stored as XML data in the /conf/config.xml file on the firewall. If you study that file and know XML, you can pretty quickly see how things work. Just find the section for Packages and then Suricata (or Snort). Each configured Suricata interface has its own sub-section in the file. Copying one sub-section over to another, and adjusting for interface names and a couple of other interface-unique parameters is all that is required.
Bill
