I have a FreeRadius server set up that authenticates users through the PAM (SSSD for AD authentication + MFA via Google Authenticator).
It works well but when I configured it on my firewall I received a message like that :
When authenticating user xxx from 'ip from domain controller', a less secure authentication method PAP is used. Please migrate to PEAP or EAP-TTLS.
I don't understand what this message exactly means. How can I secure the info between my FW/SSH console and the radius server and between the radius server and the domain controller ?
Can I still use PAM with PEAP/EAP-TTLS ? Is it just a mean to secure the network transaction or is it an authentication model ?
Thank you for your help.
The pam_radius plugin always uses pap, and the radius client with pam does not exist with PEAP/EAP-TTLS/EAP-TLS. PAP is less secure because it displays password in plain text. For security reasons you can either have a VPN which may need external hardware or have a TLS proxy like stunnel or nginx at the PAM -radius client and protect the radius packets with TLS. I will go for 2nd option as it is free and freeradius server can be configured to use radsec connection, but ofcourse you will now manage the certificates
Related
I have configured mutual authentication on an Azure Application Gateway. Currently all client certificates issued by the intermediate CA (as configured on SSL profile) are accepted, but I only want a specific certificate to be granted access, ideally based on the subject of the client certificate. Making changes to the CA that issues the client certificate is not feasible in my case.
Options explored:
Use leaf certificate when configuring SSL profile: app gateway seems to ignore the leaf certificate; all client certificates issued by the intermediate CA are accepted.
Configure a rewrite rule action to pass a server variable (e.g. client_certificate_subject) to backend in a custom request header. This would require changing the backend to interpret the request header, which I’m trying to avoid.
Configure a rewrite rule condition to check server variable (e.g. client_certificate_subject) and conditionally take some action. Ideally the action should set the HTTP response code (without forwarding the request to backend) or rewrite to an error page generated by the app gateway (e.g. HTTP 401 unauthorized / 403 forbidden). Can this be done somehow?
WAF rules don’t seem like a viable option as they don’t have access to server variables
Hoping to find a way of configuring this requirement on the app gateway. Thanks.
I understand that you want to be able to allow specific certificates only based on their subject names etc., to be granted access by the Application Gateway.
You can't use a rewrite rule because in order to "get to" a rule in the first place you have to get through the listener and you can't get through the listener if you can't authenticate with mutual authentication.
At this point, the best way to avoid people from accessing App GW would be to not give the Leaf certificate so they cannot access the same.
Also please note that Application Gateway Mutual Authentication is in preview right now and therefore, it is intended for "Evaluation" and testing, and not production currently. Once it is GA, there will be options to have revocation lists and checks.
Hope this helps. Please do let us know if you have further questions. Thank you!
I know that certificates that are sent by the server cant be faked (still there is MD5 collisions but costy) but what about faking the client ..
in man in the middle attack:
cant we tell the server that we are the legitimate client and take data from that server manipulate it then encrypt it again with legitimate client public key ? how does the client be sure that the data came really from the server ?
in theory .. can we inject any data into the response sent by the server to the client ?..
How are you authenticating the client? SSL client certificates? Or some application level system (cookies etc)?
Here's what SSL does in a nutshell:
Negotiates a Diffie-Hellman shared session key between the two parties
Has the server sign the session key and send the result to the client. Once the client verifies this, the client knows there is no MITM, and the server is who they say they are.
If client certificates are enabled, has the client sign the session key and send the signature to the server. The server now knows there is no MITM and the client is who they say they are.
Encrypts all data in both directions using the shared session key
Typically when you use SSL you won't use client certificates. Strictly speaking, the server does not know if the connection is MITM'd. However, most clients will disconnect if the server certificate is bad. The server assumes that if the client pushes forward with the connection, there is no MITM. Even if Mallory, doing the MITM, chooses not to propagate the disconnect from the client, he has no new information now; all he's done is connected to the server himself. Without intercepting the client's session cookie or other authentication information (which is only sent by the client after verifying the connection is secure) the MITM is useless.
So in short, as long as one end or the other verifies the certificate of the other end before initiating any high-level communication of sensitive information, SSL is secure in both directions.
You're right -- without secure certificate authentication on the client and server there is an opening for a man in the middle attack.
SSL can be "secure both ways" if you use mutual authentication also called two-way SSL.
In Hyperledger composer rest api (composer-rest-server) are secure with Enabling authentication for the REST server. but in http://localhost:3000/explorer, All sensitive data is not encryption. Could i use cryptography or other approach to encrypt and decrypt like Zero Knowledge Proof to prevent data privacy (sensitive data)?
And I see Securing the REST server using HTTPS and TLS, when i run command composer-rest-server -c alice1#my-network -t and then open browser https://localhost:3000/explorer, but I don't know how to use it?
Thank you in advance!
Firstly, you would use TLS between the REST client and REST server - see https://hyperledger.github.io/composer/latest/integrating/securing-the-rest-server and general/useful info on TLS with diagrams here
You would really need to set up authentication (known user identities that are using it) with TLS like discussed here then connect to the authentication path for your application to authenticate the user using the REST APIs https://localhost:3000/auth/github: ((or whatever the authPath is for your implemented strategy)) and then interactions/ data in transit between client and server will be encrypted.
Once the REST server is up and running and TLS enabled - you will authenticate at your REST client as the user in question: once authenticated, that user gets an access token or similar. In terms of Composer and the deployed business network / smart contract - that user will (already) have been issued a business network card - that includes the user's blockchain identity (key/cert) and contain connection info/metadata (ie how to connect to the deployed/runtime business network out on the Fabric network). This access may be programmatically, from an application client that's using REST APIs (ie the app user that's logged in to the app, has been assigned this business network card) or indeed - a user is using the REST API client in a browser for example (eg. he/she would import it into their Wallet in the REST client then that would be the default identity in the REST API session, and which interacts / signs transactions that update the business network (create asset, update asset etc), as REST API operations to the REST Server (over TLS) that interacts with the Fabric network (over TLS).
I am attempting to setup a freeradius server to authenticate against a web service. The reason for this is that there is a complicated workflow involving account status and mac address. The workflow seemed out of place to be in freeradius. So my user names, and encrypted passwords are stored remotely to the radius server. Everything works fine using radclient to test. When I started using the the Access Point, I learned it only communicates with the radius server via eap-tls. This means that the User-Password argument is not available for my script.
Is there a way to have eap auth check for user authentication against my script? By this i mean, can i get the password to send to my secondary service?
Alternately, is there a way to get the User-Password from the encrypted eap-message data?
Access points don't usually place restrictions on the EAP type. The device connecting to the AP negotiates an EAP type with FreeRADIUS. If it's using EAP-TLS it's probably a windows machine that hasn't been configured to do anything different.
Investigate EAP flavours to find out which ones are available. If you have EAP-TTLS-PAP you can send the plaintext password from the wireless client, and user it to authenticate against the web service.
In FreeRADIUS v3.0.x there's a rlm_rest module, which can perform basic auth on behalf of the user, with very little configuration.
i trying to get work Rails with Exchange server 2007. I trying to use difference auth methods with it: none, plain, ntlm, login. But none of them does not work and i see exceptions like this for every auth method:
504 5.7.4 Unrecognized authentication type
After long googling i try to use telnet to watch what auth methods supported:
ehlo
...
250-AUTH
250-STARTTLS
...
250-AUTH without any params, but in any manuals in internet this line usually looks like 250-AUTH NTLM LOGIN.
What auth method i should use with this server or i must to reconfigure the exchange?
Some mails servers (both incoming and outgoing) require encryption before they allow authentication.
Judging by the presence of STARTTLS, you are currently connected to port 25 or 587 without encryption.
Try to switch this connection into TLS mode by using the STARTTLS command and promoting your current plain socket to an SSL one. Then repeat EHLO and there should be some auth capabilities listed (e.g. "250-AUTH LOGIN PLAIN").