Posts Tagged ‘present time’

How to get full host and IP address of last month logged in users on GNU / Linux

Friday, December 21st, 2012

This post might be a bit trivial for the Linux gurus, but for novices Linux users hopefully helpful. I bet, all Linux users know and use the so common used last command.

last cmd provides information on last logged in users over the last 1 month time as well as shows if at present time of execution there are logged in users. It has plenty of options and is quite useful. The problem with it I have often, since I don't get into the habit to use it with arguments different from the so classical and often used:

last | less

back in time when learning Linux, is that whether run it like this I can't see full hostname of users who logged in or is currently logged in from remote hosts consisting of longer host names strings than 16 characters.

To show you what I mean, here is a chunk of  last | less output taken from my home router

# last|less
root     pts/1        ip156-108-174-82 Fri Dec 21 13:20   still logged in  
root     pts/0        ip156-108-174-82 Fri Dec 21 13:18   still logged in  
hipo     pts/0        ip156-108-174-82 Thu Dec 20 23:14 - 23:50  (00:36)   
root     pts/0        g45066.upc-g.che Thu Dec 20 22:31 - 22:42  (00:11)   
root     pts/0        g45066.upc-g.che Thu Dec 20 21:56 - 21:56  (00:00)   
play     pts/2 Thu Dec 20 17:30 - 17:31  (00:00)   
play     pts/2 Thu Dec 20 17:29 - 17:30  (00:00)   
play     pts/1 Thu Dec 20 17:27 - 17:29  (00:01)   
play     pts/1 Thu Dec 20 17:23 - 17:27  (00:03)   
play     pts/1 Thu Dec 20 17:21 - 17:23  (00:02)   

root     pts/0        ip156-108-174-82 Thu Dec 20 13:42 - 19:39  (05:56)   
reboot   system boot  2.6.32-5-amd64   Thu Dec 20 11:29 - 13:57 (1+02:27)  
root     pts/0        e59234.upc-e.che Wed Dec 19 20:53 - 23:24  (02:31)   

The hostname last cmd output as you can see is sliced, so one cannot see full hostname. This is quite inconvenient, especially, if you have on your system some users who logged in with suspicious hostnames like the user play which is a user, I've opened for people to be able to play my system installed Cool  Linux ASCII (text) Games. In normal means, I would skip worrying about the…..  user, however as I've noticed one of the ascii games similar to nethack called hunt was kept hanging on the system putting a load of about 50% on the CPU   and was run with the play user and according to logs, the last logged in username with play was containing a hostname with "" as a hostname.

This looked to me very much like a script kiddie, attempt to root my system, so I killed hunt, huntd and HUNT hanging processes and decided investigate on the case.

I wanted to do whois on the host, but since the host was showing incomplete in last | less, I needed a way to get the full host. The first idea I got is to get the info from binary file /var/log/wtmp – storing the hostname records for all logged in users:

# strings /var/log/wtmp | grep -i vexploit | uniq

To get in a bit raw format, all the hostnames and IPs (whether IP did not have a PTR record assigned):

strings /var/log/wtmp|grep -i 'ts/' -A 1|less

Another way to get the full host info is to check in /var/log/auth.log – this is the Debian Linux file storing ssh user login info; in Fedora and CentOS the file is /var/log/secure.

# grep -i vexploit auth.log
Dec 20 17:30:22 pcfreak sshd[13073]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser=  user=play

Finally, I decided to also check last man page and see if last is capable of showing full hostname or IPS of previously logged in hosts. It appears, last is having already an argument for that so my upper suggested methods, turned to be useless overcomplexity. To show full hostname of all hosts logged in on Linux over the last month:

# last -a |less

root     pts/2        Fri Dec 21 14:04   still logged in
root     pts/1        Fri Dec 21 13:20   still logged in
root     pts/0        Fri Dec 21 13:18   still logged in
hipo     pts/0        Thu Dec 20 23:14 - 23:50  (00:36)
root     pts/0        Thu Dec 20 22:31 - 22:42  (00:11)
root     pts/0        Thu Dec 20 21:56 - 21:56  (00:00)
play     pts/2        Thu Dec 20 17:30 - 17:31  (00:00)
play     pts/2        Thu Dec 20 17:29 - 17:30  (00:00)
play     pts/1        Thu Dec 20 17:27 - 17:29  (00:01)
play     pts/1        Thu Dec 20 17:23 - 17:27  (00:03)
play     pts/1        Thu Dec 20 17:21 - 17:23  (00:02)
root     pts/0        Thu Dec 20 13:42 - 19:39  (05:56)
reboot   system boot  Thu Dec 20 11:29 - 14:58 (1+03:28)    2.6.32-5-amd64
root     pts/0        Wed Dec 19 20:53 - 23:24  (02:31)

Listing all logged in users remote host IPs (only) is done with last's "-i" argument:

# last -i
root     pts/2   Fri Dec 21 14:04   still logged in  
root     pts/1   Fri Dec 21 13:20   still logged in  
root     pts/0   Fri Dec 21 13:18   still logged in  
hipo     pts/0   Thu Dec 20 23:14 - 23:50  (00:36)   
root     pts/0      Thu Dec 20 22:31 - 22:42  (00:11)   
root     pts/0      Thu Dec 20 21:56 - 21:56  (00:00)   
play     pts/2  Thu Dec 20 17:30 - 17:31  (00:00)   
play     pts/2  Thu Dec 20 17:29 - 17:30  (00:00)   
play     pts/1  Thu Dec 20 17:27 - 17:29  (00:01)   
play     pts/1  Thu Dec 20 17:23 - 17:27  (00:03)   
play     pts/1  Thu Dec 20 17:21 - 17:23  (00:02)   
root     pts/0   Thu Dec 20 13:42 - 19:39  (05:56)   
reboot   system boot          Thu Dec 20 11:29 - 15:01 (1+03:31)  

One note to make here is on every 1st number of month last command  clear ups the records storing for user logins in /var/log/wtmp and nullifies the file.

Though the other 2 suggested, methods are not necessary, as they are provided in last argument. They're surely a mus do routine, t when checking a system for which doubting it could have been intruded (hacked). Checking both /var/log/wtmp and /var/log/auth.log / and /var/log/auth.log.1 content and comparing if the records on user logins match is a good way to check if your login logs are not forged. It is not a 100% guarantee however, since sometimes attacker scripts wipe out their records from both files. Out of security interest some time, ago I've written a small script  to clean logged in user recordfrom /var/log/wtmp and /var/log/auth.log – – the script has to be run as a super to have write access to /var/log/wtmp and /var/log/auth.log. It is good to mention for those who don't know, that last reads and displays its records from /var/log/wtmp file, thus altering records in this files will alter  last displayed login info.

Thanks God in my case after examing this files as well as super users in /etc/passwd,  there was no  "signs", of any succesful breach.


How to print simple text pages on Linux in console with old LPR parallel port attached printer

Tuesday, February 7th, 2012

LPT parallel port pinout diagram with explanations

Many younger people, might not know lpr command, historically it was heavily used for printing in the early GNU / Linux days.
lpr ships the text to be printed to the printer which is physically attached on LPT (Line Print Terminal) parallel port . Those who lived the DOS era surely know in those "ancient" days, everyone who wanted to print has to use the LPT parallel port

Present time, everyone knows there is almost no modern printer that is attached to the PC via LPT port but rather the USB port is used for communication between the printer the computer.
Nevertheless The USB printers on Linux are managed by CUPS, the lpr command is still functional shipping the text to be printed via CUPS (cups-lpd daemon).
Before cups-lpd was introduced the service managing the print jobs was lpd
Hence lpr is still functional.

To print a plain text file of one page with lpr on Linux:

linux:~# cat text-file-to-print.txt | lpr

For multiple printers to switch between multiple printers there is the PRINTER shell variable:

linux:~# export PRINTER=printer-Name-and-Type

To print a really long text file (a book in TXT) the pr command comes handy. As you can read in the cmd manual pr converts text files for printing

Lets say you would like to have a 60 lines of text per printed page, the cmd to issue is:

linux:~# pr -l60 text-file-to-print.txt | lrp

All queued printing jobs can be reviewed with the lpq, if you have a printer attached try:

linux:~# lpq
lp is ready and printing
Rank Owner Job Files Total Size
active hipo 1 text-file-to-print.txt 62045 bytes

Since some years it is pretty rare for people to use lpq, since most of the parallel printing is managed by CUPS server, what most people use nowdays to check the printer queue is lpstat : e.g.

linux:~# lpstat

Printing status and all things related to queued jobs for printing gets logged in /var/log/lpr.log

There is even more simplistic way to print directly to the printer (if the printer is attached via a LPT port) through the kernel /dev/lp, for example:

linux:~# cat text-file-to-print.txt >> /dev/lp

For more than one printer attached the naming of /dev/lp, might probably be /dev/lp0, /dev/lp1 etc.
The lprm command also exists in case if you would like to cancel a printjob in the queue. Lets say I want to cancel a job in the queue with Job ID 5:

linux:~# lrpm 5

To cancel a current running job in the middle the /usr/bin/cancel command exists.

An interesting historic fact is that nowdays opening lpr, lpq or any of the other tools for simple text mode printing one sees on top of the page Apple Inc.

Lets clear this up CUPS (Common Unix Printing System) (open source) printing platform is not owned by Apple, since it is licensed under GPL2 and LGPL. The reason why the Apple Inc. shows up in man pages is because in year 2007, the founder of CUPS printing server Michael Sweet hired him to work for Apple Inc. "purchasing" the CUPS source. However as we know they did not really purchased the code, because the code was already belonging to the community (licensed under GPL2). Apple however as a marketing trick used the fact that Sweet worked for them and as probably as a matter of marketing asked him to place the Apple Inc. in the copyright source and manual areas. Obviously this is not true, since Apple Inc. does not hold copyright for CUPS as CUPS can be copied by anyone (its open source) 😉

Most of the people will never print using this commands, since printing is now, ages ahead, anyways for simple people (like me), who just need to print a text with no special fonts or graphics text printing is just great.

Text printing is also a good learning experience for Linux novices and is good to be known just as a piece of UNIX history.

How to exclude for a particular IP address in Qmail Mail server install / Fix to Thunderbird mail sent error (Exploitable Server See: error

Tuesday, November 1st, 2011

In the office, some of my colleagues has started receiving error messages, while trying to send mail with Thunderbird and Outlook Express
The exact error they handed to me reads like this:

An error occured while sending mail. The mail server responded: Exploitable Server See: Please check the message recipient

Here is also a screenshot, I’ve been sent via Skype with the error poping up on a Thunderbird installed on Windows host.

Typing the url lead me to to a page saying that the IP address of the mail client which is trying to send mail is blacklisted . This is not strange at all condireng that many of the office computers are running Windows and periodically get infected with Viruses and Spyware which does sent a number of Unsolicated Mail (SPAM).

The record for the IP seems to be an old one, since at the present time the office network was reported to be clear from malicious SMTP traffic.

The error disallowing the mail clients to send from the office continued for already 3 days, so something had to be done.

We asked the ISP to change the blacklisted IP address of xx.xx.xx.xx , to another one but they said it will take some time and they can’t do it in a good timely matter, hence to make mail sending work again with POP3 and IMAP protocols from the blacklisted IPs I had to set in the Qmail install to not check the xx.xx.xx.xx IP against mail blacklisting databases.

On qmail install disabling an IP check in RBLSMTPD is done through editting /etc/tcp.smtp and following recreate of /etc/tcp.smtp.cdb – red by qmailctl script start.
The exact line I put in the end of /etc/tcp.smtp to disable the RBLSMTPD check is:


Further on to recreate /etc/tcp.smtp.cdb and reload the new cdb db records:

qmail:~# qmailctl cdb
qmail:~# qmailctl restart

Onwards, the IP blacklist issue was solved and all office computers from xx.xx.xx.xx succeeded in sending mails via SMTP.