Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enumerated treatment beyond case 2: action, 25: limit enable, 107: segmentation support, 112: system status #17

Open
duffy-ocraven opened this issue Aug 26, 2020 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@duffy-ocraven
Copy link

Curious that current code has confined the Read-Property-Response enumerated treatment to solely:

                                        switch(property_identifier) {
                                            case 2: ##! action
                                                data[data_index] = fmt("value=%s", action[value]);
                                                break;
                                            case 25: ##! limit enable
                                                data[data_index] = fmt("value=%s", limit_enable[value]);
                                                break;
                                            case 107: ##! segmentation support
                                                data[data_index] = fmt("value=%s", segmentation_supports[value]);
                                                break;
                                            case 112: ##! system status
                                                data[data_index] = fmt("value=%s", system_statuses[value]);
                                                break;
                                            default:
                                                data[data_index] = fmt("value=%d", value);
                                                break;

Those are all good choices. But I wonder by what criteria those were selected, and why only those?

@duffy-ocraven
Copy link
Author

And why in consts.zeek, only the choice:

const segmentation_supports = {
        [3] = "No Segmentation",

instead of the full enumerated possibilities:

BACnetSegmentation ::= ENUMERATED {
	segmented-both		(0),
	segmented-transmit	(1),
	segmented-receive	(2),
	no-segmentation		(3)

and only the either/or choices:

const limit_enable = {
        [1] = "Event Low Limit Enable",
        [2] = "Event High Limit Enable",

instead of the full bitstring of possibilities that also includes:

        [3] = "Event Both Limits Enable",

@NothinRandom NothinRandom self-assigned this Aug 26, 2020
@duffy-ocraven
Copy link
Author

I am interested in discussing the motivation; doesn't have to be on this Issue thread, but I don't have other contact info for you. Feel free to message me [email protected]

@NothinRandom
Copy link
Contributor

@duffy-corelight, I don't mind discussing it here at all. For both inquiries, this was done so because those are the items that was noticed often in our traffic. I took pcaps for a few days from our production traffic and noticed these in WireShark. The same goes for the enumerations. Is there a reference list that I could use to make sure that all are included? If you have pcaps that you could share, that would be wonderful. I know I pulled the list of vendors from the BACnet website at the time this plugin was developed, so I know at least that was the latest. You could also contact me using my git user name @ gmail.com if there are topics that we need to discuss offline.

I've gone ahead and updated these and will push sometime this week. Again, thanks for being the subject matter expert in BACnet protocol to help improve this plugin!

@duffy-ocraven
Copy link
Author

If we wanted to go for completeness, an automated syntax conversion from BACnet clause 21 is warranted. The enumerated string tables in computer-readable format that I have is 3272 lines.

@duffy-ocraven
Copy link
Author

The content which is going into bacnet.log currently leaves out the property value content, due to lack of completeness in ranging over all the 13 different datatypes. Implemented are just:

                                local data_type: count = identifier_info / 16;
                                switch(data_type) {
                                    case 2,  ##! UINT
                                         9:  ##! ENUMERATION
                                    case 7,  ##! STRING
                                         8:  ##! BIT STRING
                                    case 12: ##! OBJECT

Is the omission because the others (NULL, Boolean, Integer, OctetString, Date, Time, REAL, Double) contain data which consumers of bacnet.log wouldn't care about?

@NothinRandom
Copy link
Contributor

@duffy-corelight, it was because we didn't see traffic that contained the missing datatypes, so it was deemed safer to exclude them just in case incorrect parsing could have crashed zeek.

@duffy-ocraven
Copy link
Author

Wise choice. Deploying a cure worse than the disease would have been excess hubris.

@NothinRandom NothinRandom added the enhancement New feature or request label Aug 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants