Showing posts with label ssh. Show all posts
Showing posts with label ssh. Show all posts

03 April, 2022

Teletype / TTY

A teleprinter (teletypewriter, teletype or TTY) is an electromechanical device that can be used to send and receive typed messages through various communications channels, in both point-to-point and point-to-multipoint configurations.


Initially they were used in telegraphy, which developed in the late 1830s and 1840s as the first use of electrical engineering, though teleprinters were not used for telegraphy until 1887 at the earliest.

The machines were adapted to provide a user interface to early mainframe computers and minicomputers, sending typed data to the computer and printing the response. Some models could also be used to create punched tape for data storage (either from typed input or from data received from a remote source) and to read back such tape for local printing or transmission.

One such (deprecated in these days (2022)) computer-based teletype device, was the portable Minitel.


The Minitel was a videotex online service accessible through telephone lines, and was the world's most successful online service prior to the World Wide Web. It was invented in Cesson-Sévigné, near Rennes in Brittany, France.

The service was rolled out experimentally on 15 July 1980 in Saint-Malo, France, and from autumn 1980 in other areas, and introduced commercially throughout France in 1982 by the PTT (Postes, Télégraphes et Téléphones; divided since 1991 between France Télécom and La Poste).

From its early days, users could make online purchases, make train reservations, check stock prices, search the telephone directory, have a mail box, and chat in a similar way to what is now made possible by the World Wide Web (Internet).

In February 2009, France Télécom indicated the Minitel network still had 10 million monthly connections. France Télécom retired the service on 30 June 2012.

The service was purely PSTN-based (aka public switched telephone network / "plain old telephone system") and required a subscription land-line.

Recently I came over a Norwegian model on a Norwegian auction-site (finn.no), which would be the ideal complement to my next hobby-project: a PDP11/70 Unix mini-replica minicomputer. So I bought it.


This is the Alcatel Terminus 258. A Minitel2-clone made for the Norwegian telecom authority at the time (Televerket, branded on the keyboard-latch in the image above).


The specimen I have is the Unitel-version, meaning; it is not catered for the Minitel-service, but as a control terminal using either a PSTN (Public Switched Telephone Network) or a serial (DIN connector) uplink.



10 March, 2015

Fail2Ban

Fail2Ban works by scanning through log files and reacting to offending actions such as repeated failed login attempts, by using iptables to generate blocking-rules for any defined (listening) protocols / services, aimed at specific offending IP-addresses.

I used to utilize DenyHosts, but as the project was discontinued I had to adapt. And so I also had to retract all my recommendations of DenyHosts and update them all to endorse Fail2Ban instead.

If using Ubuntu or Linux Mint, setting up and using Fail2Ban is easy.

It comes pre-configured (on Ubuntu) to detect malicious SSH-activity with basic notification action,

Firstly, you just have to apt-get it:

sudo apt-get install fail2ban
Then, you just copy over the standard (Ubuntu) "skeleton"-config:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
 Then stop and (re-)start Fail2Ban to load and run the config:
sudo service fail2ban stop && \
sudo service fail2ban start
It can be customized to send e-mail alerts to designated addresses, and various other "actions_".

Protocols and / or services are easily added to the config-file if they aren't already present. Fail2Bans config-file uses an easy syntax (layout-format) for somebody with basic networking- and logging-knowledge.

I tend to also enable the "ssh-ddos" detection, since these days we're seeing more and more distributed attacks. There are more SSH-specific detection's, but they're not necessary.

30 January, 2015

gethostbyname()

The last few years (2010-2015), I have been using a command line log-compiler tool I made, called "sshlog", to monitor incoming SSH-logins, both accepted and failed.

It is basically a crude administration-tool (server-side) for remote use on mobile devices and tablets. In combination with "DenyHosts" (python-program for blocking IPs that carry out repetitive and malicious ssh-bruteforce attempts), it proved to be a very solid security-framework.

That is, until January this year.

Suddenly sshlog reported that there weren't made any malicious ssh-connections the last month, andDenyHosts did not add any new IPs since december last year. Weird...

While log-surfing and manually executing my sshlog-algorithm on my system-logs, I noticed there HAD been malicious ssh-bruteforcing (like usual)... but none of the offending addresses had been added to the blacklist because 'auth.log' was full of warnings about unresolvable hostnames in '/etc/hosts.deny'.

After checking out /etc/hosts.deny, it became apparent that DenyHosts had been adding random canonical hostnames (which, in turn, requires DNS resolving of the IP-addresses) instead of legitimate IP-addresses.

I made my discovery thanks to this repeating error in /etc/hosts.deny:

warning: /etc/hosts.deny, line xxxx: can't verify hostname: getaddrinfo(<some-dynamic-ip>, AF_INET)

*SIGH*

Firstly, I had to stop DenyHosts, then I had to manually 'sed' all the IP-addresses that had been added as canonical hostnames from the DenyHosts config-files, then from /etc/hosts.deny and lastly start DenyHosts up again...

The whole ordeal was apparently caused by none other than... myself -_-

I had enabled DenyHosts to do hostname-lookups for blocked IP-addresses :P *Doh!* which in turn forced DenyHosts to add dynamic hostnames to /etc/hosts.deny, no matter if they were legitimate addresses or not.

Fact is; many of these malicious SSH auto-dialers use dynamic IP-addresses that won't resolve as legitimate addresses in DNS (no registered reverse-lookup, or similar), thus, they are added to '/etc/hosts.deny' with (invalid) canonical hostnames that don't correspond to legitimate MAC and IP-address pairs.