PHP 8x support

[NathanGibbs3]

Open discussion about the evolving state of PHP 8x support in BASE.

---

The idea is to try to keep the discussion about this in one place and not have fragments of it splattered chaotically all across the issue tracker.

• Lets use the issue tracker to track issues.
• Lets use this topic to have & track ideas.

[mesteele]

Navigating to the Use Archive Database all the items under Traffic Profile by Protocol is missing until an event is moved into it and then they all display. If I delete the event, they all disappear.

[mesteele]

PHP 7 works fine with and without events in either the Alert or the Archive database.

Another unrelated issue to the above: The protocol list should be showing 0% when it is empty, and it shows NAN%. If one event is received all the protocols lose the NAN and show correctly. This has been doing the same on PHP7.

PHP 8: I cleared all the events, and it loses all the protocols as it shows above in both the Alert and Archive database.

[mesteele]

I just restarted at zero events and all the protocols were missing on the Alert and Archive database. As soon as it received one event in the Alert database all the protocols showed up and the percentage shows as <1% on the ones with no events, and the one with 1 event shows as 100%

[NathanGibbs3]

I think I found the source of the NAN Issue last night while reviewing the code for this issue, committ 5d91e74 was responsible for that.
Somebody, two guesses who, was writing code without enough coffee. 😄
I already have a fix for that in the pipeline.

Lets make sure I understand this issue correctly.

• We are getting the bar graphs at 0% on PHP 7x.
• We are getting a blank section of page on PHP 8s.

Do I have the right idea?

[mesteele]

If the database is new there are no events posted. The bar graphs on PHP8 are missing. As soon as it receives one event in one of the protocols all the graphs show up. The graph that got the event will show 100% and the remaining graphs will show <1%

On PHP7 all the bar graphs are visible with no events logged and all the percentage values are NAN%. As soon as it receives one event in one of the protocols the graph that got the event will show 100% and the remaining graphs will show <1%

[NathanGibbs3]

OK, got it.
The next commit to devel will have the NAN fix, I suspect that will also fix the PHP 8x display issue, if not we can go back to the drawing board. Either way, I opened Issue #172 to track this.
I'm going to do some work on #161 before pushing to devel, so it will be a bit.

[mesteele]

If $Use_Auth_System = 0; I can still get into Alert Group Maintenance and create or delete.

[NathanGibbs3]

Not specifically related to PHP 8x support.
Issue #161 is open to track this.
If the Auth system is off, I don't see any issues with allowing users full access to alert group functions.
If the Auth system is on, there is the expectation of access levels.
The create, edit, and delete functions should be locked out for users with in roles with numeric ids above ag_editor, currently, they are not.

Maybe the clear function could be locked out as well, your thoughts on that would be appreciated @mesteele .

I am not entirely sure what usage scenarios were envisioned by @secureideas when they built the auth system.
One thing that is clear is that the auth system was never fully implemented, although we have made progress with that.🙂

Added a new project to track Auth System related Issues https://github.com/NathanGibbs3/BASE/projects/5

[mesteele]

It's a lousy authentication system. I'm not sure how it should be, but I don't think users should be able to modify.

[NathanGibbs3]

Agreed, the auth system tables should not even be part of the snort DB.
They should have been implemented as a separate DB, like the Archive DB.
On the bright side, your observations have led the creation of Issues such as #144 & #146, which make the auth system suck less.

[mesteele]

Most of the links in the home page produce an error when accessed and they are directed at that particular database table related to the link.

[NathanGibbs3]

I pushed to devel earlier, CI checks passed, let me know if that commit is better behaved on PHP 8x.
Knowing PHP 8x, something else will probably blow up. 😄
Fingers crossed. 🤞 😄

[mesteele]

Most of the links on the home page are still broken, similar to the below but pointing to different tables.

When I click on an event the below error pops up.

The Archive database is now showing the bar graphs.

Log: error.log

[NathanGibbs3]

I just pushed to devel again, CI checks passed.
I know what the bug is, and generally where it is hiding.
Opened Issue #178 to track it.
I doubt we have seen the last of it, but we will flush it out.
Let me know how this commit works.
Fingers crossed. 🤞 😄

[mesteele]

It appears that the link issue is resolved. I will need to do more testing to see if there are any other issues as I drill down further into the options.

[NathanGibbs3]

That is excellent news. 😄
Thank you.

[NathanGibbs3]

Thank you @mesteele for putting it all in one place.
This will make things so much easier. 👍🙂

[mesteele]

Clicking on any alert, I click the Next button and it pulls up the next alert and I chick on Next again and I get:

PHP Warning: Trying to access array offset on value of type null in D:\winids\inetpub\wwwroot\base\includes\base_state_query.inc.php on line 103
PHP Warning: Trying to access array offset on value of type null in D:\winids\inetpub\wwwroot\base\includes\base_state_query.inc.php on line 103

The above is constant and it is happening in all the categories on the second click of Next.

It appears that all the options that have a next button is doing the same or similar thing.

[mesteele]

I just went to my MySQL Apache2 install and it is not doing this. I'm going to do a fresh install with PostgreSQL IIS and see if it returns.

[NathanGibbs3]

You are definitely on to something. 👍
What you found are bug tracks. 🪰
We just need to know how BASE running in production on PHP8x is tripping it.
When you see that bug, send me the error log, so I can kill it. 🪰 ⚡ 😄

[mesteele]

BASE works as intended with Apache2 and MySQL.

BASE is getting an error. After clicking on an event for viewing anywhere in the list, then clicking Next or Previous the second time gets the error. Using W10, IIS and PostgreSQL.

Base Exits:

Attached IIS log file:
u_ex230422.log

[NathanGibbs3]

OK, thanks.
This is definitely a deal breaker on IIS. It will get a stability tag in the issue tracker for sure.
The IIS error logs only tell me that it is crashing. The Apache error logs usually contain a PHP back trace which gives me a better idea of why it crashed.

I am chasing this down from my end as well. It does exist on PHP 7x, it just doesn't break BASE.
Try it again on Apache and send the error log, even if it doesn't appear to break BASE, PHP 8x should complain in the log which will be helpful.

You have definitely found something that needs to be fixed. 🪰
I'm still assessing it, then need to contain & eliminate it. ⚡ 😄

[NathanGibbs3]

Got him nicely contained in #185 & #186

[mesteele]

Here is the Apache2 error log. It appears to be getting the error but works through it.
error.log

[NathanGibbs3]

Thanks. 😄

[NathanGibbs3]

When the returns from the class under test in various error states are all over the map.

Why BASE, Whyyyyy. 💩 😞

[NathanGibbs3]

Fix is in the devel branch.

[mesteele]

It appears that the Next and Previous is fixed :)

However :) If $Use_Auth_System = 1; then under IIS I get a server error when I go try to access BASE and does not get to the user authentication page. Under Apache I do get an error in the log, and BASE does go to the user authentication page.

The attached log file is after loading BASE and BEFORE I enter my user credentials.

error.log

[NathanGibbs3]

The Apache 'error' tells us that the authentication system is working as designed, at least on Apache.
Using index.php as the default landing page of a BASE install should not trip the authentication system, so I'm still at a loss about where the message is actually coming from.
IIS only seems to tell us 'It's broken!', well, thanks IIS, so is Chernobyl, doesn't help us fix it.

This isn't the first time the Auth system has tripped up IIS, and we still have next to no data to work with, except, 'It's broken!'.
I have a theory, of course, I'm shooting in the dark, but it 'may' help on IIS. The theory's implementation will be out shortly.

[NathanGibbs3]

It's live in the devel branch, see what it does.

[mesteele]

I'm accessing using index.php

It is still has the same issue:

I am attaching two sets of logs for IIS and Apache. I started with new log files for each. I started the webserver, started BASE and stopped the webserver.

Apache2 logs 0 is no authentication and 1 is with authentication.
Apache2 With 0.log
Apache2 With 1.log

IIS logs 0 is no authentication and 1 is with authentication.
IIs With 0.log
IIs With 1.log

[mesteele]

$BASE_urlpath = 'http://winids';

[NathanGibbs3]

Seriously!!!!!! 🤯

This is from the BASE conf file itself.

 Set the base_urlpath to the url location that is the root of your BASE install.
 This must be set for BASE to function! Do not include a trailing slash!
 But also put the preceding slash. e.g. Your URL is http://127.0.0.1/base
 set this to /base

I could be wrong, but I 'think', we actually found the bug this time. 😄

The URL you use is http://winids
So $BASE_urlpath should be set to an empty string just ''

So, I've spent weeks chasing around BASE looking for a bug that is not there.

[mesteele]

Not sure but there has been thousands of installs and no problem like this has been reported. For some reason PHP8 is noticing it, where PHP 5-7 didn't care.

It appears to be working correctly.

[NathanGibbs3]

On IIS. with Auth set to 0 it goes to: Log: auth-0 php_errors.log

Then there has been thousands of installs exposing admin functions and version information to unauthenticated users due to system misconfiguration.

The underlying disclosure issues were addressed in October of 2020 with fixes for Issues #78 & #89
The next BASE Kernel will keep this misconfiguration scenario from re-exposing these issues.

[mesteele]

Thank you for all your hard work, it is appreciated :)

[mesteele]

I'm in the main snort database, I go into Cache and Status. and want to clear all the alerts. I try but the screen just blinks and nothing gets deleted.

The checkmark is on the archive database so I switch to the archive database and try to copy or move events and both give this:

None of the functions seems to be working in Cache and Status in either MySQL or PostgreSQL.

[NathanGibbs3]

That indicates that the Archive DB flag is enabled in conf.
It does not guarantee the existence, structure of, or access to an archive DB.
See Issue #102 for more information.
It appears that you use the archive DB functionality, maybe you could point us to information that would be helpful in closing #102. 🙂

[mesteele]

I'm not sure what you are needing?

I always manually create both databases. Go here and there is a section called Installing the MySQL Database Server on how I Install MySQL. Then go to the section Configuring the MySQL Database Server to see how I manually configure the databases. Then go to the section titled Configuring BASE the Windows Intrusion Detection Systems (WinIDS) Security Console to see how I configured BASE to access both databases.

[NathanGibbs3]

Thank you, I've never run BASE with an archive DB, as there was no documentation in BASE on how to set one up.
So it appears that the archive DB has the same structure as the main snort/ACID/BASE alert DB.
Couple of questions.

1. Is Barnyard being actively maintained?
   • What I have for them is https://github.com/firnsy/barnyard2
   • As barnyard, like BASE is under GPL, I'm thinking about incorporating their DB creation code into a future version of BASE,. That way BASE could bootstrap it's own required DB infrastructure during setup, if needed.
   • Obviously, it would have to check for a pre existing DB structure. We wouldn't want an upgrade trashing a production DB. 🙀 🤯
2. What are your thoughts on removing the authentication tables from the archive DB is a future BASE?
   • It seems like a bad idea to have login credentials laying around in the archive DB.

Your thoughts on any of this would be appreciated. 😄

[mesteele]

So it appears that the archive DB has the same structure as the main snort/ACID/BASE alert DB.

Yes, you could just change event database name to archive and it would done. I have no idea how it works as it has been years since I tried it. I don't think it does PostgreSQL.

Couple of questions.

Is Barnyard being actively maintained?

No, it has not been maintained for a few years now.

What I have for them is https://github.com/firnsy/barnyard2

Yes, and I do the compiling for Windows.

As barnyard, like BASE is under GPL, I'm thinking about incorporating their DB creation code into a future version of BASE,.
That way BASE could bootstrap it's own required DB infrastructure during setup, if needed.

The only thing Barnyard2 does is read in the snort event log, decode it and move the decoded events to whatever database Barnyard2 is configured to use.

Obviously, it would have to check for a pre existing DB structure. We wouldn't want an upgrade trashing a production DB. 🙀 🤯

See the above.

What are your thoughts on removing the authentication tables from the archive DB is a future BASE?

That would be a huge amoubnt of work. For the obvious, it would be better to move all that to a Users Group in the OS.

It seems like a bad idea to have login credentials laying around in the archive DB.

It's never a good idea but I think the original programmer was trying to make ACID as all inclusive as it could.

[mesteele]

PHP apparently has two active versions being developed (8.1.xx and 8.2.xx).

I am using PHP 8.2.5 to test on, so should I move back to 8.1.xx so as not to leapfrog over the version you are using?

What parts of BASE I have built unit tests for get tested on travis-ci from PHP 5.2 - 8-1.

[NathanGibbs3]

Run it on whichever PHP you want to.
BASE was originally designed to run on 4.0.4+. I've tried to keep it that way. As mentioned, I test it on the PHP major.minor combos offered by Travis-ci. That way, as things get added or changed, we don't negate the viability of BASE on older systems.