Im implementing my own RPC framework and well moste of the stuff is done but i need some help how do i verify a auth_unix? the structure of the data is definied in http://www.faqs.org/rfcs/rfc1050.html 9.2 UNIX Authentication but how should i verify the user?
UID and GID are compared to the UID and GID on the server to validate their authenticity. These IDs can be shared across unix systems using NIS or some other facility. Anything subsequently executed on the remote system is run under that effective UID and GID.
The application behind the server may implement further authentication, but note that AUTH_UNIX does not authenticate the user in itself; it trusts the UID and GID supplied.
From Section 9.3:
9.3 DES Authentication
UNIX authentication suffers from two major problems:
(1) The naming is too UNIX oriented.
(2) There is no verifier, so credentials can easily be faked.
DES authentication attempts to fix these two problems.
If you use Unix authentication you can only assume that the message originates from a trusted host and some mechanism was in place to authenticate the user before they got the chance to do something that originated the call.
In this case it would be up to the application to verify user credentials. The originating machine name is also supplied so you could make sure that the originating IP address matches it and only reply to that address - this has obvious vulnerabilities to DNS cache poisoning attacks. Also, making this play nicely with DHCP or NAT is left as an exercise to the reader ;-}
Which means you have little choice but to trust the UID and GID or do additional verification within the application sitting on top of your RPC library. The RFC discusses more secure authentication mechanisms. However, Sun RPC is not the most secure of protocols and is generally not recommended for services provided to untrusted clients.
Related
I have a simple app connected to a server via some sockets and the traffic is not yet encrypted users must log in or create accounts before using the app and afterwards traffic is shared between users and server. i want to know if i must encrypt all traffic or just the authentication and account creation?
Use https for all traffic (or an equivalent TLS-based protocol for non-HTTP traffic). Yes, encrypt and certificate-authenticate everything. For modern systems, there are vanishingly few cases where TLS is not the correct answer for network traffic. It is ubiquitously available across platforms, languages, and protocols.
On any modern network system you need an argument for why you wouldn't encrypt and authenticate the connection. It's not a matter of "must" you. It's a matter of "why wouldn't you?"
Let's say I want to set up a poor man's authentication scheme for a simple network service.
I don't want to bother with username/password authentication, for simplicity I just want to have a list of public keys in my application and anyone who can prove they are the owner of that key can use my service.
For the purposes of my application it would greatly simplify the authentication process since all my users are on the local network and they all use Unix. Anytime I onboard a new user I can just ask them for their ssh public key.
Is there a simple way to reuse the mechanism involved in ssh public key authentication in a non-ssh application? This is question is intended to be language agnostic.
If you just have a list of users that can use your application and you have no need to see who did what.
You can setup your server so that it listens only on localhost (127.1) rather than 0.0.0.0, and provide a restricted sshd, forwarding the port required to connect to the application
~/.ssh/authorized_keys will provide a list of the authorized keys that can be used.
ssh -I private_key_file <hostname> -L 3000:localhost:3000
For a basic setup and help with configuring your sshd, check out this answer:
https://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-port-forwarding
Note: Be warned that if you don't lock it down, any user will have full shell access on your box where the machine is hosted.
A dirty hack from top of my head: could you wrap the application so that it would create an actual SSH tunnel from localhost to your server, and use that for ?
Assuming you are talking about a web based application. What you are really looking for is X.509 Client certificates (1.3.6.1.5.5.7.3.2). This will allow you to identify a user individually to your application.
These face the same issues that are usually faced when looking at key distribution. Which is generally considered a hard problem.
If you wanted to head down this road here is what you would need to do.
Generate a root certificate (once)
Setup web server with appropriate modules to parse the certificate (nginx/apache)
Generate a certificate for each user (openssl)
Download cerificiate from centralized server. (maybe use their ssh pub key here)
Install the x509 cert locally (OS Dependent)
On the server side, you would need to process the cert as part of the web-server (nginx or apache should have modules to do this) and then pass the name onto your application as a header field which you can then process internally.
This is a much better security solution than usernames and passwords, however is complex because of the key distribution issue. Most people wouldn't bother since in most applications it is easy enough to integrate logins with LDAP or radius.
I've heard from more than one IT Manager that they don't allow users to user RDP to connect to their internal network from the outside, because it's not safe. They claim that if they'd allow their users to do so, then anyone from the outside will have access to their network as well.
I'm not getting it. In order to use RDP, you need a user name and password, and you can't get in without it. The same is for using Gmail, online banking, and any other web service.
So what do they use instead? LogMeIn. Or a VPN connection, and then use internal RDP. VPN also requires a user name and password.
If they're afraid of a brute-force attack, then someone can brute-force attack the VPN server or LogMeIn just the same. And if these other technologies have lockouts (after x number of failed attempts) then why can't the same be set up for RDP?
Similarly, people always say that VPN is very secure because it uses a "tunnel". I don't fully understand what that means, but regardless, why can't the username and password be cracked the same way any website or web service which uses a user name and password can be.
With proper configuration, RDP is capable of 128-bit RC4 encryption, virtually any port or set of port allocations, and has proven to be relatively bug-free, with only extremely minor flaws ever discovered.
On the other hand, the secure tunnel created in a VPN is far more secure than Remote Desktop. All your data is encrypted for safe transfer from one remote location to another.
Moreover, VPN only allows shared content to be accessed remotely to tighten the security. If your device falls in the wrong hands, they won’t be able to access and manipulate unshared data and resources.
The bottom line is that both RDP and VPN have their own advantages, however, with high security, better performance and manageability, VPN seems to be a clear winner in the competition of Remote Desktop VS VPN service.
I have a web service with several web methods, each web method requires client machine to send their MAC Address and the server will validate this client base on this information (if not valid then return error) before proceeding to further operations. The communication between client and server is HTTPS. I only have about 20 clients or so. The question is is my way of doing this right/secure or not? If not then is there any simple way to do this?
Thanks,
It depends on your security requirements, there is no one definition of "secure enough". As others have said, the MAC can be spoofed, and is in effect just a shared secret/password. However, that is sufficient for many scenarios, when the confidentality of the connection is ensured by HTTPS. You need to define what threats you want to protect the system from, and how much you're willing to invest in security.
No, it's not secure because anyone who knows a valid MAC address in your database could call the web service. Of course knowing a valid MAC address in your database is unlikely possible, it's as if he knew a password.
The client can spoof the MAC address of the machines which is authorized. So, this is not secure.
Protecting your webservice through client certificates would provide better security.
Tutorial : http://www.codeproject.com/KB/WCF/9StepsWCF.aspx
Microsoft's Enterprise SSO server is bundled with BizTalk Server - I'm fairly familiar with how to configure it, make sure it's working, etc. My questsion is, what exactly does it do, and how does it do it?
My best understanding is that it is used to securely store configuration for things like ports and adapters, because configuration items often include things like credentials, passwords, connection strings, etc. In terms of "how it works", my best guess is that the configuration values are stored encrypted in an SSO database, and the "master secret" is simply the encryption key that only privileged credentials (like the one running the BizTalk hosts) have access to, so they can use it to access the encrypted configuration.
Can someone shine some light on this and point out where this is right/wrong?
You're pretty close overall. EntSSO is used by BizTalk internally to store any sensitive data. This includes particularly the adapter-specific part of any send port/receive location configuration.
But that's not all EntSSO does; it can also be used to provide credential mapping services between Windows and non-windows systems, by storing sets of encrypted credentials for other applications and mapping within them. Basically, this can be used to provide single sign-on services when building BizTalk solutions so that BizTalk can "act as" a specific user when doing stuff on their behalf.
For example, you could have BizTalk receive a message over an HTTP/SOAP receive location set up with Windows Integrated authentication, and then let BizTalk flow that authentication information over to an FTP send port where the Windows user credential is mapped to a specific username/password combination associated to it so that BizTalk can authenticate as said user to the FTP server. With this, different Windows Users sending messages to BizTalk would result in separate FTP connections created with different credentials on the other end (this is different from the default BizTalk behavior of using a single credential for all operations on a send port).
Obviously EntSSO offers a bunch of other options beyond this, but that's kinda the big deal.
BTW, the BizTalk docs actually contain a fairly extensive section on EntSSO that is pretty useful.