corradoignoti.it

Dopo un po’ di tempo di inglese “puro”, torno a riproporre la sicurezza in formato italiano, inserendo una nuova categoria nel mio blog: “Sicurezza”.

Qui troveranno spazio tutti gli approfondimenti delle notizie che riguardano la sicurezza ma relativi al solo mondo dell’IT italiano.

Intresting…

For millions of people, especially among the under-25s, online culture is becoming the only culture that matters. Take the plunge, and the world becomes one massive network in which users band together to share just about everything.

And more…

And what is being permanently connected going to do to us? Are we seeing the emergence of a hive mind? Or is it just a new way of maximising your individuality?

But let’s keep in mind the home security! Let’s remember that there’s Google, MySpace and lots of interesting thing, but let’s remember that there’re Viruses, Malware and pornography… and so on!

Speaking about security we use lots of terms but, probably, we are forgetting the true meaning of thoose terms.

I found and interesting article by David E. Stern that tries to answer to the question “What are vulnerabilities?”

Lets look at a few traditional vulnerabilities. The strongest castles became vulnerable to intrusion with the introduction of modern artillery; big enough guns destroy the biggest walls. Early wild west stage coaches were easy targets for large groups of bandits because of their limitations in armor, speed, and defensive weaponry. Humans, without the benefit of vaccinations fall victim to viruses and bacteria because their vulnerable bodies simply can’t fight back.

This is 1 of 3 part article.

Interesting article from SecurityFocus

Malicious SSH login attempts have been appearing in some administrators’ logs for several years. This article revisits the use of honeypots to analyze malicious SSH login attempts and see what can be learned about this activity. The article then offers recommendations on how to secure one’s system against these attacks.

Some raccomandations are given:

There are a number of simple methods to protect against these attacks. The most obvious way is to turn off the daemon service, which on many systems is installed by default. If the computer system runs as a desktop machine, there is likely no need for remote access via SSH to log into the machine. If this is not an option, there are numerous other options.

• Use the /etc/hosts.allow and /etc/hosts.deny files found on most Unix and Linux system to restrict daemon access to specific hosts.
• Install a firewall to restrict access to the SSH server from only designated machines and networks. This works particularly well if administration of a machine from an internal network necessitates remote access to that machine.
• Restrict the SSH server to only authenticate particular users or groups.
• Move the listening port of the SSH server from 22 to some other unused port. While this would not prevent attackers from connecting to the server and start guessing password, it will significantly reduce the likelihood of finding your SSH daemon, as attackers use standard SSH clients and attack tools that assume the SSH server is running on its standard port 22.
• Use an alternate authentication method besides simple passwords. More on this below. If this is not an option, ensure that a strong, complex password or passphrase is used.

SSH provides an alternate authentication method which successfully mitigates password guessing attacks. This authentication method is based on cryptographic keys, or so-called private key and public key. The public key is placed onto the server and acts as a custom lock for access to your account. This lock can only be opened with the corresponding private key. Once you provide this key, you gain access. Password guessing attacks would fail as attackers cannot guess or generate such a private key. All modern SSH servers are configured by default to support this authentication method. However, they usually fail back to password-based authentication in case the incorrect private key is provided, opening the door for password guessing attacks once again. The server needs to instead be configured to accept key-based authentication only for this mitigation strategy to be successful. 

Last month, NIST hosted the Second Hash Workshop, primarily as a vehicle for discussing a replacement strategy for SHA-1.

NIST continues to recommend a transition from SHA-1 to the larger approved hash functions (SHA-224, SHA-256, SHA-384, and SHA-512). In response to the workshop, NIST has also decided that it would be prudent in the long-term to develop an additional hash function through a public competition, similar to the development process for the block cipher in the Advanced Encryption Standard (AES).

From nmap site:

Hello nmap-dev,
this is the final SoC release of the NSE scanning engine.

Nmap Scripting Engine comes with great scripts, but some of the other contributors made a list of useful scripts that didn’t yet exist, and one of them was an SMTP Open Relay testing script.