It's nothing new that there are several botnets scouring the Internet for poorly protected SSH servers. Their members are mostly compromized hosts, such as home computers hijacked with trojans and worms. Some "real" servers end up on these botnets as well. Sometimes hired for the purpose, sometimes cracked by the same backdoors as the home computers, or simply compromized via the services they run, usually vulnerable dynamic websites.
These botnets scan vast IP-address ranges trying to find hosts which are running SSH server software on the default port (tcp 22). When they find one, they start trying to log in using brute force. Usually the method of choice is to login as root and use a dictionary for guessing the password. Sometimes they try to login as other users, such as test, staff or use someones first name as the login.
I'm currently working as a network engineer for a medium-sized Internet service provider Nebula in Finland. The interesting 24 hours I'm referring to, started yesterday at 16:10 Finnish time when one of the core routers on our network started acting up. Due to confidentiality issues I can't go into technical details on what happened, but this is the official announcement we gave out to customers during the incident. It was updated this morning and we might provide some further details later on. The translation from Finnish to English is my own.
Problems with network connectivity
Due to a software related issue on a core router, some network connections have experienced problems and interruptions since 16:10 local time. The issue is still under repair.
Update: the fault has been limited and connectivity restored at 20:30. The fault had been resolved already before 17:00, but the effects of it resulted in new issues in connectivity after 18:00.
The overload caused by the fault resulted in connectivity issues between the routers of the internal core network at Nebula. When the original issue had been located and resolved, the level of service started to normalize in stages. Latency in certain connections may have been higher than usual during recovery.
We are sorry for the inconvenience and will be peforming upgrades to minimize similar incidents in the future.
Some changes have occured since I wrote the first part of Keeping in sync. Some of these changes have been dictated by glitches in the technologies, and others by the increase in number of devices involved. I needed to buy a second smartphone as I now have two mobile subscriptions, which made things a bit more complicated than before. Not much really, just a bit.
In the end, the mobile version of OggSync didn't work for some reason. The support people couldn't replicate the error, so it still remains a mystery. The version I was using is still beta, so the issue might be resoved in future releases. This is why I opted to install the desktop version off OggSync on the server running Kerio MailServer and perform the sync between Google Calendar and Kerio there. So far it's been working like a charm.
As for Facebook, I found out that it's possible to use the Export Events -functionality directly from Google Calendar, so I left the FBCal out of the equation. This way the events seem to appear in Google Calendar faster than with FBCal, but I never really timed this, so it's just a hunch.
I gave up using Remember The Milk, as synchronizing it with the rest didn't quite work like I wanted it to work. As said, pushing tasks through Google Calendar resulted in just calendar events. Instead, I opted to use the Tasks-functionality of Outlook. This way the tasks are synchronized natively via Kerio and ActiveSync, while still being accessable with a browser via Kerio Webmail.
Always an interesting topic among nerds :)
I myself use the names of the islands in Tonga.
The Wall Street Journal reported yesterday that "A Russian "cyber-militia" has effectively knocked the central Asian republic of Kyrgyzstan offline in recent days". See the full article here: http://online.wsj.com/article/SB123310906904622741.html
It's quite hard to find traces of DoS attacks on the internet if they only swamp individual websites, but the article suggests that total connectivity to all of Kyrgyzstan has been severely impaired. This led me to wondering if signs of the attack are visible on the global routing table. This can happen if the attack is so severe, that edge routers connecting ISP's to one another can no longer exchange routing data, because the data link between them is fully saturated with attack traffic.
|<< <||> >>|