Is there any way in Linux/Unix to determine the client application user is using to connect to OS. In our environment thousand of users connect to our system via client applications like WinSCP, Dbvisualizer, putty etc. We need to check the client application that users are using to connect to Server.
4
11
Simple answer: No, there is no sure way. Terminal applications often will report available features when queried with the right escape sequences but this is sometimes not enough to detect which application is used, and it can very easily be faked.
In general, the actual terminal application used should not matter, so maybe you should rephrase your question to state the actual problem you try to solve instead.
-
Thanks for the reply, my actual problems are: 1.- To stop use of unknow client applications ( since I cannot determine it in unix so only option I have is to monitor & restrict installation on each client machine.) 2.- To determine a way to log user activity perform via client such as Winscp. – Salman Raza Apr 26 at 11:13
-
1So this is an enterprise environment where you control the network, servers and clients? If so there are plenty on ways to solve your problem, only allows clients to install approved software, only allow admins to install any software, network profiling ( hard for encrypted traffic ), NAC etc – Matt Douhan Apr 26 at 11:41
-
3Why exactly do you need to stop users from using client applications of their choice? Your server integrity should not depend on it, otherwise your security is broken at the core. If the client machines are provisioned by your IT department they should have means of installing only approved software, no need to check that via unreliable mechanisms from the server side. – Hans-Martin Mosner Apr 26 at 11:54
-
As I've written in an answer somewhere else: Don't fear your users! goodreads.com/quotes/… – Hans-Martin Mosner Apr 26 at 11:57
-
1For the logging problem: Log what you know and need (subject to business requirements and regulatory restrictions). User ID, timestamp of connection open and close, server directories visited, file read and write accesses, etc. The client software really shouldn't matter. – Hans-Martin Mosner Apr 26 at 12:07
4
There might be many tools the clients use, but the underlying techniques or protocols these "tools" might use are same like 'SFTP, SSH, telnet' etc, to connect to the server. So all that system will see is some remote host is trying to open a ssh or sftp session on this server. Check /var/log/secure for more. Some common messages you would come across are:
ssh via tools like putty or xshell:
sshd[19199]: Accepted password for root from 10.10.10.10 port 51162 ssh2
sshd[19199]: pam_unix(sshd:session): session opened for user root by (uid=0)
sftp via winscp :
sshd[19238]: Accepted password for root from 10.10.10.10 port 51163 ssh2
sshd[19238]: pam_unix(sshd:session): session opened for user root by (uid=0)
sshd[19238]: subsystem request for sftp
PS: But there might be some extravagant tools that might do your job.. never say never in this world of software!
-
When
sshdis properly configured, no one can log in as root. An administrator must connect his SSH client using his personal credentials, then usesudoto elevate privileges after getting logged in. When someone tries to authenticate as root, it's a red flag that might trigger anti-cracking measures like fail2ban (or a redirect of traffic from the offending IP to a honeypot VLAN). – Monty Harder Apr 26 at 17:46 -
@MontyHarder Since the question was about users logging into the system, I provided some sample logs as examples. True if
sshd_configis configured withPermitRootLogin no, there would be no directrootlogin. But when admin logs in with personal credentials ,andsu -is done to perform privileged operations , even then you see logs ,su: pam_unix(su-l:session): session opened for user root by <personal_login>. So authentication ofrootmight be there occasionally. Its the question of who does it. This is written assuming no broker was used to elevate the access privileges. – sai sasanka Apr 29 at 5:31
