Paul Beckett 18:31:03 UTC

Good evening. I'm keeping half an eye on chat via phone while looking after my daughter

emphazer 18:31:49 UTC

hello everybody

walter 18:32:53 UTC

hi

airween 18:34:01 UTC

hi all

xanadu 18:34:57 UTC

Hi!

franbuehler 18:37:59 UTC

Hi

dune73 18:42:04 UTC

Hi there, my wife lost a contact lens inside her eye. That's rather painful. Please start without me.

walter 18:42:51 UTC

okay, I guess we will start by working down the agenda: https://github.com/coreruleset/coreruleset/issues/2169

walter 18:43:14 UTC

as for the sponsor developments, they are coming along quite nicely!

walter 18:43:51 UTC

Christian knows more about this so we’ll leave detailed discussion for later I guess :)

walter 18:44:35 UTC

let’s go to the Open PRs…

walter 18:44:46 UTC

https://github.com/coreruleset/coreruleset/pull/2168 in need of a quick review, maybe @airween

walter 18:45:09 UTC

what do you think @airween? it looks like a small issue

airween 18:46:13 UTC

yes, I'll check this, I'm going to assign it to myself.

airween 18:46:37 UTC

oh, it's already assigned to @fzipitria

fzipitria 18:46:47 UTC

Hey!

fzipitria 18:46:51 UTC

Sorry, was on calls 🙂

dune73 18:46:56 UTC

[I'm back. Lens retrieved. Mission accomplished. Apologies from my panicking wife.]

dune73 18:47:51 UTC

Nothing more to add with regards to sponsoring. It's coming along nicely, but it's apparently a lot of work.

dune73 18:48:23 UTC

@Walter do you want to continue with hosting the meeting? I do not mind - or I can take over. You decide.

walter 18:49:47 UTC

if you could take over that would be my preference 🙂 I’m not as up to date as I’ve had a crunch month at work with 7 day work weeks, so I haven’t kept track very well

dune73 18:49:56 UTC

🙂

dune73 18:50:10 UTC

Fine. (well not the 7 day work weeks).

dune73 18:51:10 UTC

So 2168 is in good hands. I was just calling on @airween to take a glance because he told us the remaining failing tests on NGINX were due to engine bugs and this looks like a bug in the tests and ModSecv3 being less forgiving (or whatever).

dune73 18:51:18 UTC

Guess we can move on.

walter 18:52:21 UTC

next one is https://github.com/coreruleset/coreruleset/pull/2163

dune73 18:52:25 UTC

2163 is a renaming PR. We used to name the 934 group after NodeJS, but now it looks like there will be very few NodeJS rules and we have a need for a generic application attack rule group.

walter 18:52:33 UTC

sounds fair to me

dune73 18:53:10 UTC

Unfortunately, the PR fails on FTW, probably due to the renaming. theMiddle seems a bit lost. Could somebody with an ftw background take a look at this?

walter 18:53:47 UTC

_@fzipitria_maybe?

fzipitria 18:53:53 UTC

Yes

walter 18:54:10 UTC

maybe the filenames are hardcoded somewhere?

dune73 18:54:18 UTC

Thanks. Feel free to merge as soon as the tests pass. The PR looks good to me.

dune73 18:54:24 UTC

hardcoded: Maybe, yes.

dune73 18:54:43 UTC

2156 is a ctl cleanup PR. Maybe more to come.

maxleske 18:55:08 UTC

hi

walter 18:55:15 UTC

2156 makes sense to me

dune73 18:55:16 UTC

ctl:ruleEngine off is a bit radical, removeByTag:OWASP_CRS seems more compatible with other rule sets. What do you think?

dune73 18:55:37 UTC

Hello @maxleske! Great to see you. Wondered if you would show up.

fzipitria 18:57:45 UTC

I think it makes sense. I never liked just turning off.

dune73 18:57:47 UTC

I do not see anybody disagreeing. So I guess this is good to go. @azurIt also wonders what to do with other CRS specific stuff. Like variables / SecMarkers not named after CRS. Personally, I do not see this as a problem. We're known enough and the variables / SecMarkers carry very uncommon names.

dune73 18:58:09 UTC

Merge right away, or somebody does a review?

walter 18:58:21 UTC

I think it can be merged!

dune73 18:58:49 UTC

Cool. Then please go about it.

walter 18:58:57 UTC

done

dune73 18:59:28 UTC

2052 adds more teeth to an existing rules. Possibly also more FPs. We need a proper review.

dune73 18:59:39 UTC

It's maybe also a candidate for the incubator to test the water.

walter 19:00:01 UTC

I could test it out on live traffic for a few weeks

walter 19:00:27 UTC

at first sight it doesn’t seem too dangerous…

dune73 19:00:43 UTC

I agree. So would you do the review?

walter 19:00:55 UTC

sure, I just check for FP’s, and then merge it?

dune73 19:01:23 UTC

Yes, I think that's all what's needed. Thank you.

dune73 19:01:50 UTC

#2149 is a very welcome cleanup of our regex assembly by @maxleske.

dune73 19:02:25 UTC

I took a close look at the documentation and file format. But now we need a review or more bluntly: Somebody generating all the regexes anew and comparing the output.

franbuehler 19:03:43 UTC

I could do this

dune73 19:03:44 UTC

FYI: For 3.3 or so we failed to get the regex assembly script to do a specific thing, so we duplicated the behaviour into a 2nd script with a subtle difference. But it was obviously a hack. Max has now merged the two and adds more flexibility to the way we use the script and the source files (-> Adding possibilities for empty lines and comments!)

dune73 19:03:55 UTC

Thank you @franbuehler!

walter 19:04:21 UTC

this is a nice change!

dune73 19:04:49 UTC

Absolutely. It's so good to see dirty spots being cleaned up one after the other.

dune73 19:04:57 UTC

Hope we are not adding too many new ones.

dune73 19:05:56 UTC

2067 is the unfinished machine learning plugin. It was contributed from a student who won't be doing any work on this anymore. I do not think we can / should merge as is, but with some love, this could be made into something useful.

dune73 19:06:21 UTC

Cutting down my optimism, I have to admit that it's unlikely I will find the time to do this anytime soon. (with soon being 2021)

walter 19:07:12 UTC

ack

dune73 19:07:31 UTC

So if somebody looks for a new pet project, this could be it. And if not, we can also let it linger as unfinished PR for some more time.

maxleske 19:08:03 UTC

My plate is full 🙂

dune73 19:08:38 UTC

OK, then let's skip this.

dune73 19:09:44 UTC

2050 needs a reviewer with an interest in regex optimization. It's a simplification of the regex, but it might also introduce more FPs. So I am not sure it's worth it, but the existing ReDoS on the rule is probably also very bad. So it's hard to judge ...

maxleske 19:10:46 UTC

I'll take it

dune73 19:11:30 UTC

Thank you @maxleske. @airween?

airween 19:11:47 UTC

a side note: I made a small tool which collects the @rx operators and the arguments, and checks them against the REDOS. I've found that one with that tool

maxleske 19:12:08 UTC

Nice! Could you link it in the issue?

airween 19:12:30 UTC

this is it, the 2050 (I guess)

dune73 19:13:25 UTC

Cool one. I remember you showing said tool, I think.

dune73 19:13:33 UTC

But I was not aware this was behind 2050.

dune73 19:14:00 UTC

With 2049, we're in bit of a tricky situation.

dune73 19:15:01 UTC

TW has picked up our request to add more holistic JSON CT header. But only as a commented out suggestion, not as an update to the recommended rule 200001. They do not want to expand 200001, but think about introducing a new rule 200006 that does the same thing.

dune73 19:15:20 UTC

They also mention the recommended rules are more of a proposal and not meant to be comprehensive.

walter 19:15:31 UTC

I like our solution

dune73 19:16:01 UTC

Yet, they are also asking for more opinions and I would appreciate if you could share your view in the ModSec PR where this discussion happens.

dune73 19:16:30 UTC

After that discussion is over, we could also think about issuing our own recommended rules, this time a comprehensive variant!

walter 19:16:35 UTC

I think we should merge it, it doesn’t harm if there are multiple rules setting it

walter 19:16:44 UTC

even if TW updates their rules

dune73 19:16:49 UTC

That could in fact be a topic for the dev retreat.

dune73 19:17:28 UTC

I am very reluctant to add redundancy here, as it makes debugging very hard, namely in the crazy case that TW mentions as a reason why they do not want to update 200001.

dune73 19:18:26 UTC

There are more issues with the modsec recommended rules and a workshop on the topic could be very beneficial and end up with a vastly superior setup.

dune73 19:20:10 UTC

-> the crazy case: People setting an exotic JSON CT, but it's not really JSON what they submit. When we start to body parse this as JSON, the parser will start to fail. I think that's acceptable, but TW thinks it's not. With redundant twins of 200001, debugging that would become tricky for weak users.

walter 19:20:59 UTC

I think this would probably be very rare

csanders 19:21:29 UTC

exceedingly, if they went through all that effort

walter 19:21:32 UTC

(though I do sometimes have an app submitting non-json or just an empty file with a json Content-Type and getting it rejected by modsec)

dune73 19:22:00 UTC

The empty file JSON is a classic source of pain with ModSec.

azurIt 19:22:16 UTC

Sorry friends, i have to go, good night!

walter 19:22:27 UTC

we could make a rule that switches off the JSON parser if content-length is 0 🙂

dune73 19:22:28 UTC

So you guys think we should merge and see how this evolves? Or we wait for the dev retreat?

emphazer 19:22:36 UTC

good night azurit

dune73 19:22:37 UTC

Bye @azurIt! Thanks for joining!

dune73 19:23:50 UTC

Personally, I would prefer to wait and to fork the recommended rules after we talk it through in October.

walter 19:24:22 UTC

that’s also a good option. maybe then we could also set some more reasonable defaults for the PcreMatchLimits 🙂

fzipitria 19:25:13 UTC

@jptosso

dune73 19:25:45 UTC

Exactly. And look into the positioning of the rules. And kick 200004 and look into the proper position for 200005.

xanadu 19:26:23 UTC

The split between 'modsecurity.conf' and 'crs-setup.conf' is very confusing at first… Having a unified setup '.conf' file (which I think is what is being suggested here) would be amazing

dune73 19:27:16 UTC

Not sure we can make it into a single file. But no longer depending on a single additional config file from ModSec (which is also odd in the light of alternative engines being established).

dune73 19:28:17 UTC

So what do we do? I can live with a merge now, but as I said, I'd prefer to wait some more.

walter 19:29:19 UTC

I’m in favor of merging but I can see the other point too!

dune73 19:29:41 UTC

Other opinions?

fzipitria 19:30:00 UTC

Really a tough one

maxleske 19:30:18 UTC

no clue...

franbuehler 19:31:41 UTC

I don't have a strong opinion here. But we are not in a hurry here and could wait with merging...

fzipitria 19:32:02 UTC

I would wait for now

walter 19:33:40 UTC

OK

dune73 19:33:43 UTC

@Walter can you live with we schedule this for October?

walter 19:33:49 UTC

sure!

dune73 19:34:02 UTC

In the meantime we can direct users to the new rule 200006 that has been merged as a comment.

dune73 19:34:07 UTC

Thank you.

dune73 19:34:59 UTC

Two more to go. With 1993 we are a bit at an impasse as @Walter and I could not agree on basic plugin configuration / enabling at the previous meeting and we have not talked this through between us in the meantime.

dune73 19:35:24 UTC

I suggest @Walter and I schedule a separate meeting in August so this can then proceed and the way is clear for future plugins.

walter 19:36:21 UTC

OK

dune73 19:36:55 UTC

Anything else to add here?

dune73 19:37:36 UTC

The PR has been open quite some time - I do not know how Azurit feels about it. But a release is not imminent anyways, so I hope that's OK.

dune73 19:39:22 UTC

Final one: 1975: This is just a check if there is suddenly somebody who uses NextCloud/Owncloud and could see him-/herself reviewing this PR properly. This is a contributing PR but we are not able to merge since no team member has any experience or time for this.

dune73 19:40:41 UTC

I see few volunteers for 1975, so let's keep this open.

dune73 19:41:08 UTC

Thank you all, this has been quick, we covered a lot of PRs on top of the 11 ones that we merged in July.

↳ maxleske 19:46:48 UTC

@dune73 The issue appears to me to in part that there's functionality which could be used by some people but we can't make it available (even as an "alpha") because we can't put it into a release. Would it be feasible to put this into some kind of "plugin", e.g., git submodule or something so it can be pulled in even without an official release? As one of the people says, NextCloud appears to be unusable currently...

dune73 19:41:27 UTC

Next item on the agenda is the status of the Coraza WAF, an alternative engine to ModSec.

dune73 19:41:40 UTC

@jptosso is here to give us an update. Please Juan!

jptosso 19:42:21 UTC

Hey, thank you @dune73 Well, thank you for having me here, Coraza is an actual working port for modsecurity written in golang

jptosso 19:42:45 UTC

It’s been in development for a year and it’s almost production ready.

walter 19:42:55 UTC

very cool!

jptosso 19:43:22 UTC

the architecture is similar and the APIs are already working and integrated with Caddy server

jptosso 19:43:42 UTC

The idea with this project is to address some issues modsecurity team is not interested in

dune73 19:44:04 UTC

What do you mean by "architecture is similar"? Similar to ModSec? Or Caddy?

jptosso 19:44:48 UTC

to modsecurity, the APIs are similar and it works on the same principles, the main difference is Coraza uses token parsing instead of YACC

jptosso 19:45:04 UTC

package main import( "fmt" engine"github.com/jptosso/coraza-waf" "github.com/jptosso/coraza-waf/seclang" )

func main() { // First we initialize our waf and our seclang parser waf := engine.NewWaf() parser := seclang.NewParser(waf)

// Now we parse our rules
parser.FromString(`SecRule REMOTE_ADDR "@rx .*" "id:1,phase:1,drop"`)

// Then we create a transaction and assign some variables
tx := waf.NewTransaction()
tx.ProcessConnection("127.0.0.1", 8080, "127.0.0.1", 12345)

tx.ProcessRequestHeaders()

// Finally we check the transaction status
if tx.Interrupted() {
	fmt.Println("Transaction was interrupted")
}

}

jptosso 19:45:13 UTC

this is a working sample for a Coraza transaction

jptosso 19:46:22 UTC

right now Coraza is just a modsecurity implementation but the idea is to add some interesting enterprise features like openapi support enhanced logging (syslog and others) antivirus native support clustering and more

jptosso 19:46:35 UTC

https://github.com/jptosso/coraza-waf#roadmap-long-term

dune73 19:46:52 UTC

Oh, you have 113 stars already. Congratulations.

dune73 19:47:11 UTC

Can you say anything about performance?

jptosso 19:47:22 UTC

yes, performance is of great importance

jptosso 19:47:31 UTC

we are using libpcre just as modsecurity and its the main bottleneck

jptosso 19:47:48 UTC

I can share an actual profiling graph

airween 19:48:02 UTC

and does Coraza support the libinjenction?

jptosso 19:48:21 UTC

yes, it’s integrated using CGO

jptosso 19:48:31 UTC

I have been working on a golang port without success

jptosso 19:48:59 UTC

I plan to use golang flags to compile CGO versions (with libinjection and libpcre) and without CGO (with golang implementation of libinejction and re2)

airween 19:49:31 UTC

is there any binary package?

dune73 19:49:34 UTC

So RE2 and friends are on your roadmap (-> very important from my perspective)

jptosso 19:49:54 UTC

you can use the working docker image

jptosso 19:49:58 UTC

jptosso/coraza-waf

jptosso 19:50:07 UTC

jptosso 19:50:40 UTC

https://medium.com/@jptosso/implementing-coraza-waf-with-docker-a55a995f055e here is a working wordpress implementation

dune73 19:51:13 UTC

PHP+Apache is the backend in this docker setup?

jptosso 19:51:19 UTC

yes

jptosso 19:51:24 UTC

you can actually use caddy +fastcgi

jptosso 19:51:31 UTC

but i believe apache is easier to explain

dune73 19:51:35 UTC

Cool. Something to run for real.

dune73 19:51:46 UTC

I hear you are close to a v1.0 release?

jptosso 19:51:56 UTC

yes, so close

jptosso 19:52:05 UTC

the api is almost stable, there are only some minor changes to expect

dune73 19:52:18 UTC

So it's like a matter of weeks?

jptosso 19:52:19 UTC

but they wont affect integrators, just internal functionalities

jptosso 19:52:28 UTC

august is my deadline

jptosso 19:52:46 UTC

with a coverage of 85%+

dune73 19:53:03 UTC

85% of the CRS testsuite?

jptosso 19:53:14 UTC

actually coreruleset is fully supported

jptosso 19:53:22 UTC

except by DDOS protections

dune73 19:53:33 UTC

Forget about those.

maxleske 19:53:41 UTC

Wow! Sounds to good to be true TBH 😄

jptosso 19:53:55 UTC

yea I havent implemented persistent collections yet

jptosso 19:54:05 UTC

the dependencies required are too heavy

jptosso 19:54:27 UTC

so I’m not sure if using a plugin architecture or hardcoding them

dune73 19:55:57 UTC

I would not add persistent collections for the time being. Few people use them and it's what makes the code so painful. CRS will outsource the DDoS stuff into a plugin soon and then we'll be free of persistent collections in the core release. I think that's all you need to support while establishing your software on the market.

dune73 19:56:49 UTC

RE2 support, superior performance, small memory footprint and 100% coverage of the CRS test suite are much more important from my point of view.

fzipitria 19:57:08 UTC

We need to push for that

fzipitria 19:57:28 UTC

RE2 in all our regexes

franbuehler 19:57:34 UTC

I have to go to bed. Good night and bye 👋

maxleske 19:58:05 UTC

I mostly agree. However, in our set up we relied heavily on the IP collection to do basic DOS filtering. I also wrote a rule to get clients to back off after producing too many failures from the backend, that rule also used collections.

jptosso 19:58:34 UTC

So actually I need some help testing CRS, I have manually tested more than 1000 rules but there are 1000+ more to go The actual tests are not compatible because they are meant for apache

fzipitria 19:58:43 UTC

I've used mod_evasive for thst

dune73 19:58:45 UTC

Bye @franbuehler!

jptosso 19:58:51 UTC

and Caddy won’t behave as apache

fzipitria 19:59:19 UTC

I would not expect "binary" compatibility

dune73 19:59:22 UTC

We should be able to help you there, I guess.

airween 19:59:38 UTC

I'm very happy to help in testing!

dune73 19:59:39 UTC

Binary compatibility would be very nice, but would probably also need some work on our side.

fzipitria 19:59:45 UTC

But more semantic one, were we achieve the same protection level

maxleske 20:00:12 UTC

Could we add a Coraza setup to the Docker test containers?

fzipitria 20:00:43 UTC

We can

dune73 20:00:50 UTC

@maxleske That's all very useful and nice to do in ModSec, but there are alternatives beyond ModSec to accomplish this, so I think it should not be a priority for @jptosso.

jptosso 20:00:53 UTC

@airween that would be awesome !

fzipitria 20:01:02 UTC

But we need to rely on go-ftw

jptosso 20:01:23 UTC

there is a repo, its outdated: https://github.com/jptosso/coraza-ruleset

jptosso 20:01:34 UTC

I will update it today with tools to test coraza against CRS

dune73 20:01:53 UTC

What needs to happen so I can run Coraza in Apache and NGINX? So without the Caddy...

jptosso 20:02:12 UTC

Well there is a chance, you can actually create a new package and use CGO externs

jptosso 20:02:36 UTC

but I wouldn’t recommend it, as we spoke with @fzipitria, modern web servers are here to stay

jptosso 20:02:45 UTC

and we should potentiate them

fzipitria 20:03:22 UTC

The reality is that we might take time to see this working in Apache or nginx

dune73 20:05:50 UTC

That might be true for startups, but the venerable ones will be around many years down the road. What does it take on a dev level to make it happen the way ModSec3 has an API and an NGINX module that works with said ModSec3 API. Can you do the same with Coraza and all it takes somebody does the work, or is this more complicated (sorry, but I am not familiar with CGO externs and other things real programmers know).

jptosso 20:06:39 UTC

technically modsecurity uses externs to create it’s libraries, it’s the same principle

jptosso 20:06:46 UTC

but we would have to add C code to coraza

jptosso 20:06:53 UTC

in order to create “exportable headers”

jptosso 20:07:32 UTC

and the golang community doesn’t like CGO, it’s kind of a taboo

dune73 20:08:18 UTC

Why would you have to do this? Could not the NGINX/Apache module transpose the exportable headers into a format that the native Coraza can read in GO?

jptosso 20:08:46 UTC

Yes but it requires a lot of C work, I would need a lot of help

jptosso 20:09:21 UTC

but it would basically be the same as libmodsecurity with similar hooks

dune73 20:10:18 UTC

OK, got it. I see the big amount of work - and I also see it's not useful for you to make this a priority. But it might be for somebody else.

airween 20:10:26 UTC

and then we could embed Coraza in any kind of HTTP server, which written in C?

jptosso 20:10:52 UTC

yes, using CGO and externs

airween 20:11:04 UTC

sounds fine

dune73 20:11:32 UTC

Thank you for this status update and the docker container. This is really cool.

maxleske 20:12:14 UTC

🕺

jptosso 20:12:24 UTC

Thank you guys

dune73 20:12:48 UTC

You are most welcome.

jptosso 20:12:50 UTC

well if you have any comment or want to contribute you can find me here in slack or write me to jptosso@gmail.com

dune73 20:13:14 UTC

Thank you for joining. We're observing your progres eagerly.

dune73 20:14:19 UTC

Time is moving fast. I'd like to talk a bit about our dev retreat in October and then maybe about more ideas to spend our money (OWASP kind of wants us to spend it in the year we're receiving it, so we better get going).

dune73 20:15:17 UTC

For the retreat, we have 4 full participants and 3 participants not the full weak, 3 tentative participants, 1 decline and 2 devs have not responded yet.

dune73 20:16:33 UTC

So this comes along nicely and I take it we'll be between 6 and 10 people for most of the week. I think they have 7 or 8 rooms or so and I guess there is nothing wrong with bringing a mobile bed for a few nights to accomodate more people.

dune73 20:17:20 UTC

I've started a wiki page at https://github.com/coreruleset/coreruleset/wiki/Dev-Retreat-Topics

dune73 20:18:03 UTC

If you have any idea what we could do there, please add it. It does not mean we will really do that once on site. But we will consider it together when we do the real program. So the more ideas the better.

airween 20:18:54 UTC

oh, looks like I can't attend for the full week. Here in .hu, where will the Autumn Holiday in schools on that day, and family wants me...

dune73 20:20:02 UTC

Oh, oh.

maxleske 20:20:08 UTC

I have to go. Thanks and good night!

dune73 20:20:26 UTC

Bye @maxleske Thank you for participating.

airween 20:20:48 UTC

but I'm looking for some solution 😛

dune73 20:21:31 UTC

Oh, dealing with the family during holidays will be tricky. Interested in your creative solution... 🙂

dune73 20:22:17 UTC

That much on the dev retreat. If you do not have any questions / suggestions beyond the wiki page for now, then let's move on.

dune73 20:23:40 UTC

We have a budget of about 4K on dev-on-duty. I expect the dev retreat to be 8-10K. Azurit is writing a rule exclusion package for gold sponsor Kemp and that might be another 5-7K or so.

dune73 20:24:04 UTC

Under the line, we have at least 20K that we can spend on useful things that are beneficial for our project.

dune73 20:25:01 UTC

As I stated earlier, I would not mind being paid something for the coordination / communication / sponsoring work, but not before we are over 50K sponsoring per year.

airween 20:25:17 UTC

we can or we must? I mean, can we carry to the next year?

walter 20:25:25 UTC

That doesn’t sound unreasonable. It is taking you a lot of effort.

dune73 20:26:07 UTC

@airween: Let's say it's complicated and I spare you the details. Taking over too much will probably not work.

dune73 20:26:30 UTC

Thanks @Walter, but let's postpone that until we have more to spare.

airween 20:26:31 UTC

ah, I see

dune73 20:27:38 UTC

One thing that works nicely is the dev-on-duty and I was wondering what you guys would think about expanding it a bit and making it 200 USD per week. Like covering Twitter hashtags #ModSecurity #CRS3 #CoreRuleSet too?

dune73 20:28:13 UTC

Azurit and Franbuehler have left already and they are engaged a lot as dev-on-duty, so we will obviously not take any decisions, but let's hear what you think?

walter 20:28:43 UTC

sounds good to me!

dune73 20:29:44 UTC

For me it's a way that serves the community and it allows a CRS dev to make some money aside. And if it's easy getting that money because there is actually very little work, then that's a benefit of being a CRS developer, I think. 🙂

dune73 20:31:46 UTC

We could also pass on some money to other OWASP projects and become more popular within OWASP that way. Like the "CRS grant for promising new OWASP projects" of 2K USD per year. (But that's probably a lot of hassle for a jury and complicated to coordinate with HQ).

walter 20:33:17 UTC

yeah, but preferably projects related to CRS…

Paul Beckett 20:33:40 UTC

If there are experienced Devs with time available, could some money be used to pay for development time for new features/rule categories?

dune73 20:34:13 UTC

Another thing I have been discussing with Walter and Airween is a potential solution to the fake JSON that ModSec is writing. As you probably know, the ModSec alert message is taken as is and wrapped into JSON. People will then have to parse this themselves for their reports and everybody tries to reinvent the wheel. I do not see Trustwave solving this anytime soon, but it's more and more a blocker for CRS adoption when I talk to customers / potential enterprise users.

walter 20:34:17 UTC

maybe we could even have a red team try to evade our protections

dune73 20:34:37 UTC

Commercial solutions of course come with great reporting features ...

dune73 20:34:54 UTC

A CRS bug bounty program sounds like a plan, yes!

walter 20:35:14 UTC

I feel we get very little input from breakers

walter 20:35:22 UTC

I guess they would rather keep their exploits to themselves…

walter 20:35:52 UTC

a bug bounty could solve that!

dune73 20:35:53 UTC

Or we pay somebody to set up a real demo site so the breakers get something to grind their teeth into.

Paul Beckett 20:36:39 UTC

Some might want to keep them to themselves, but bug disclosure can be pretty scary often resulting in people threatening to sue you. Participation in a bug bounty programme gives people a safe way of disclosing

dune73 20:36:57 UTC

@Paul Beckett Payment for generic rule development is certainly also an option. But I am somewhat afraid it kills the nature of a volunteer driven project. So I have a tendency to push for auxilliary projects that do not kill our incentives.

dune73 20:37:28 UTC

Yes, disclosure policy or a bug bounty could be a way forward.

dune73 20:38:05 UTC

As it happens, I am on very good terms with 2 bug bounty companies... I might be able to set up something with a profitable price tag.

dune73 20:39:05 UTC

For the record: @csanders has created a CRS demo site. But it stayed a proof of concept and it's not production ready.

dune73 20:39:54 UTC

Do you have more ideas?

dune73 20:41:06 UTC

For the JSON logging problem: Kemp is thinking about developing this themselves and using it as a unique selling point for their platform. I think that would make a lot of sense. But they told me they would also welcome somebody else pushing a solution they could re-use. But we ought to make up our mind in the next few weeks.

xanadu 20:43:09 UTC

How much would it cost to get the CRS fully audited? Or would that not be practical/worthwhile?

airween 20:43:11 UTC

in case of full native JSON log output, how do you imagine it? I mean does it need to keep the limit? (1131 byte)

dune73 20:43:28 UTC

Money is always a bit a tricky topic. Would you generally be OK if Walter and I talk this all through, consulting individual project members depending on the subject and move forward with spending projects?

dune73 20:44:00 UTC

@xanadu I have no f**ing clue. But we could try and get into the EU auditing program. That would be neat.

Paul Beckett 20:45:04 UTC

Not sure if this is helpful... And realise it's a generic modsec 'feature' not CRS, but for enterprise use one of the biggest barriers seems to be logging and log visualisation. Are there any projects that address either of these... Which could use funding?

dune73 20:45:11 UTC

@airween: I'd say a best effort would be enough. JSON would mean you lose some information, but at least it's JSON. Or we do it outside ModSec and we can go beyond 1131 perhaps. Such a project would need a deep discussion on the goals.

dune73 20:46:18 UTC

@Paul Beckett Solving the JSON issue would be a basic building block to allow for better log integration and consequently reporting and visualisation afterwards. But when you can't even get the rule ID in a simple JSON format, that it's kind of moot.

dune73 20:49:27 UTC

Repeating my question: Would you generally be OK if Walter and I talk this all through, consulting individual project members depending on the subject and move forward with spending projects?

dune73 20:49:45 UTC

I do not want to push this down your throat, but September and afterwards December is close. 🙂

airween 20:51:09 UTC

agree

walter 20:52:26 UTC

OK 🙂 no objections…

walter 20:53:43 UTC

I guess everybody is almost asleepnow

walter 20:53:45 UTC

I surely am

walter 20:53:55 UTC

shall we call it a day?

Paul Beckett 20:54:39 UTC

My thumbs up was meant to indicate agreement with @dune73 spending suggestion

dune73 20:54:57 UTC

Yes, let's close this. Thank you all for participating! It's been fun seeing you all again!

emphazer 20:55:08 UTC

I wish everybody a good night

Paul Beckett 20:55:15 UTC

Good night everyone

xanadu 20:55:24 UTC

Night!

walter 20:55:32 UTC

see you in two weeks for the issues chat. I’ve reserved some time for working on my issues so hopefully I will have some good news

airween 20:56:49 UTC

good night!

walter 20:56:53 UTC

bye bye!

Paul Beckett 21:03:18 UTC

Re: earlier comments about spending money, supporting other OWASP projects and testing rule evasion... I wonder whether we could get any join up with the ZAP project/community.

fzipitria 21:03:43 UTC

👋