Linux, Windows, Software Tips, Articles and Hacks
Also, for CentOS: http://www.tecmint.com/ssh-two-factor-authentication/
Want to secure your SSH server with easy-to-use two-factor authentication? Google provides the necessary software to integrate Google Authenticator’s time-based one-time password (TOTP) system with your SSH server. You’ll have to enter the code from your phone when you connect.
Check the server if it is root compromised.
lsattr /usr/bin
Root compromised output. All of those files are set to immutable and append only. That’s what the “ia” you see is.
[root@mail ~]# lsattr /usr/bin s---ia------- /usr/bin/bzcmp s---ia------- /usr/bin/getkeycodes s---ia------- /usr/bin/enc2xs s---ia------- /usr/bin/mail-files s---ia------- /usr/bin/chage s---ia------- /usr/bin/mdeltree s---ia------- /usr/bin/nslookup s---ia------- /usr/bin/semodule_link s---ia------- /usr/bin/mbchk s---ia------- /usr/bin/rpcgen s---ia------- /usr/bin/lkbib s---ia------- /usr/bin/dig s---ia------- /usr/bin/webazolver s---ia------- /usr/bin/pstruct s---ia------- /usr/bin/spfd s---ia------- /usr/bin/linux64 s---ia------- /usr/bin/semodule_expand s---ia------- /usr/bin/readlink s---ia------- /usr/bin/as s---ia------- /usr/bin/makedb s---ia------- /usr/bin/seq s---ia------- /usr/bin/id s---ia------- /usr/bin/colcrt s---ia------- /usr/bin/pod2man s---ia------- /usr/bin/zipnote s---ia------- /usr/bin/hcitool s---ia------- /usr/bin/lftp s---ia------- /usr/bin/run-with-aspell s---ia------- /usr/bin/[ s---ia------- /usr/bin/perl s---ia------- /usr/bin/mailstat s---ia------- /usr/bin/ecryptfs-setup-swap s---ia------- /usr/bin/lpstat.cups s---ia------- /usr/bin/linux32 s---ia------- /usr/bin/ipcclean s---ia------- /usr/bin/pkill s---ia------- /usr/bin/mzip s---ia------- /usr/bin/mcookie s---ia------- /usr/bin/pm-restart s---ia------- /usr/bin/rcp s---ia------- /usr/bin/fgconsole
Non root compromised
[root@austin ~]# lsattr /usr/bin -------------e- /usr/bin/pigz -------------e- /usr/bin/isosize -------------e- /usr/bin/php -------------e- /usr/bin/system-config-firewall -------------e- /usr/bin/ftpdctl -------------e- /usr/bin/berkeley_db_svc -------------e- /usr/bin/wftopfa -------------e- /usr/bin/yum-builddep -------------e- /usr/bin/tic -------------e- /usr/bin/ptardiff
Other checks:
I would check the following:
Logs. If you have root access you should check things like history which will give you command history and log files in /var/logs.
Baseline. If you have a baseline like file hashes to work with for application and system files this will help a lot. You can also use backups to compare a previous state. If using a backup to compare files, use a slightly older one if you can. The site may have been compromised a while before and it is only now that the redirect has been activated.
Check any includes. The files may not be on your server. They may be script includes such as or iframe type tags. Also do not exclude images, PDFs of Flash (SWF), video files. It is a fairly common trick to embed links in to files of a different content type. I would suggest you inspect them by hand particularly at the start and end of a file. The file may be completely a link/html/javascript or may be a legitimate image file with a link trailing at the end of the file.
Check for unusual file dates, sizes and permissions e.g. 777.
Check cron jobs for unusual jobs. Someone compromising a system will often leave a back door to get back in again and again. Cron is a very popular way to do this if they managed to get that far.
Check for the absence of files, you may not be able to have access to logs but the absence of them is equally a tell tail sign that someone has cleaned up after themself.
Use search engines. Not surprising search engines are great at finding everything. Use directives like site: e.g. site:yoursitehere.com baddomain.com see if you get any hits.
Often a link or redirect will be obfuscated so long javascript code with single letter variables should be analyzed carefully.
Do a packet capture with a tool like Wireshark or tcpdump from a secure workstation to the site. Save it to file and search the file for a parts of the url.
Check database records that may be queried or updated. The link could be injected in the database not the PHP.
Don't exclude the client's workstation. Use a free online virus scanner if need be. Also check nslookup and see what that resolves to. Check browser extensions, clear cache and check hosts files.
I would check the following:
Logs. If you have root access you should check things like history which will give you command history and log files in /var/logs.
Baseline. If you have a baseline like file hashes to work with for application and system files this will help a lot. You can also use backups to compare a previous state. If using a backup to compare files, use a slightly older one if you can. The site may have been compromised a while before and it is only now that the redirect has been activated.
Check any includes. The files may not be on your server. They may be script includes such as or iframe type tags. Also do not exclude images, PDFs of Flash (SWF), video files. It is a fairly common trick to embed links in to files of a different content type. I would suggest you inspect them by hand particularly at the start and end of a file. The file may be completely a link/html/javascript or may be a legitimate image file with a link trailing at the end of the file.
Check for unusual file dates, sizes and permissions e.g. 777.
Check cron jobs for unusual jobs. Someone compromising a system will often leave a back door to get back in again and again. Cron is a very popular way to do this if they managed to get that far.
Check for the absence of files, you may not be able to have access to logs but the absence of them is equally a tell tail sign that someone has cleaned up after themself.
Use search engines. Not surprising search engines are great at finding everything. Use directives like site: e.g. site:yoursitehere.com baddomain.com see if you get any hits.
Often a link or redirect will be obfuscated so long javascript code with single letter variables should be analyzed carefully.
Do a packet capture with a tool like Wireshark or tcpdump from a secure workstation to the site. Save it to file and search the file for a parts of the url.
Check database records that may be queried or updated. The link could be injected in the database not the PHP.
Don't exclude the client's workstation. Use a free online virus scanner if need be. Also check nslookup and see what that resolves to. Check browser extensions, clear cache and check hosts files.