Copy snort config to new interface?
-
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.
-
-
@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
