REST API unauthenticated by default?

[Christian Svensson]

Hello SONiC folks,

I am evaluating SONiC as a platform for future projects, and part of that is of course security.

I was quite surprised to find out that the default REST API configuration appears to be "client_auth = none" from reading the DB schema[1] and observing how SONiC 202012 works.

If SONiC aims to be secure by default, I would probably call this a bug. If it does not aim to be secure by default, why not?

From what I can tell, the REST API seems to be all-powerful so this seems pretty bad to allow unauthenticated remote endpoints to talk to it.

Let's assume for a second this is working as intended, and that unauthenticated API requests are the expected bring-up state. What is the expected user journey towards locking down the switch for production use? To me it seems impossible to do currently - let me explain:

 - So far I had to manually hack in a "REST_SERVER" object in /etc/sonic/config_db.json in order to set "client_auth". There appears to be no CLI command to easily do this currently - that's unfortunate but not unacceptable.

 - Doing a "config load" with that configuration file (and docker restart on sonic-mgmt-framework) sadly wasn't enough to enable "client_auth" so I rebooted the switch as a last resort.

 - This seemed to trigger a recalculation of the flags to "rest_server", but it seems that providing any REST_SERVER object is broken due to a typo in the template[2] (RESET_SERVER vs REST_SERVER). This causes the sonic-mgmt-framework subsystem to crash-loop.

Are people simply running their SONiC switches without API authentication, or am I missing something huge?

Regards,

[1]: https://github.com/Azure/SONiC/blob/master/doc/mgmt/Management%20Framework.md#322414-db-schema

[2]: https://github.com/Azure/sonic-buildimage/blob/master/dockers/docker-sonic-mgmt-framework/mgmt_vars.j2#L2

[Sachin Holla]

Hi Christian,

Looks like code changes to enable password authentication by default (as proposed by the same HLD) are not yet contributed. With the current code you will have to set the following entry in config_db to enable password authentication (HTTP Basic authentication).

sonic-db-cli CONFIG_DB hmset "REST_SERVER|default" client_auth user

However, as you pointed out, the REST startup script is broken -- due to PR #4937. You can revert this PR for your quick POCs or use a 202006 image.

Regards

Sachin

--
You received this message because you are subscribed to the Google Groups "sonicproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonicproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonicproject/CADiuDAR2cc_VdkQYmk_NbeVtbBS2W14LT%3Dp2tN4ucBHfXic0Sw%40mail.gmail.com.

This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[Christian Svensson]

Hi Sachin,

Thanks a lot for your help.

sonic-db-cli CONFIG_DB hmset "REST_SERVER|default" client_auth user

That is a very useful command I did not know of. I will save it, it will help me greatly in the future.

However, as you pointed out, the REST startup script is broken -- due to PR #4937. You can revert this PR for your quick POCs or use a 202006 image.

There are other reasons I cannot use the 202006 image, but indeed I can patch the typo manually of course.

I was mostly interested to understand how SONiC views this default behavior and if I can expect to find more things that needs to be actively hardened - or if SONiC aims to be "reasonably" secure out of the box. E.g. not allowing remote management using default or no passwords etc.

Either way, should I file a bug for this? Given that the behavior does as you say diverge from the statement "By default HTTP Baisc and bearer token authentication modes are enabled." [sic].

Regards,

[Sachin Holla]

Hi Christian,

You can probably open a bug. But I am not sure if sonic community wanted to keep it that way. I see the telemetry server also runs in no authentication mode by default -- it even uses an insecure channel (non TLS).

Regards

Sachin

[Eric Seifert]

Hello, it is true the REST interface by default currently does not use authentication. It has been some time but I think the reasoning was that some users use client certs for everything and had no need for password authentication, or else it was up to the user to configure the desired authentication method. I am willing to raising a PR for switching the default auth mode from “none” to “user” though if this is not the case though.

Thanks,

-Eric Seifert

[Raphael Tryster]

Is there a decision on submitting such a PR?

[Christian Svensson]

Not to my knowledge. I created a PR to fix the typo, but it has not been reviewed yet: https://github.com/Azure/sonic-buildimage/pull/8475

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sonicproject/84a5e236-204e-4a45-8e71-6cb6023f81e8n%40googlegroups.com.