hi guys, how to detect network probes such as port scans, port sweeps or other types.

Is there a built-in tool in Linux to do this? SNMP can detect it?

Are there tools specifically for this?

Thank you.

Snort / Suricata PSAD, Scanlogd, iptables rule sets and more...


Only thing built-in is NetFilter.


SNMP serves another function: check your favorite search engine?

1 members found this post helpful.

You can expect port-scans, and you should do scans yourself. Be certain that you know which ports are open.

Furthermore: don't expose "ssh!" Even though it's a "secure" shell, in that it encrypts the traffic that's sent across the wire, "it's still a shell" that, by default, offers anyone on Planet Earth a login: prompt.

1 members found this post helpful.

Didn't know the SSH offers a login prompt for everyone to try and break the Shell till the hands bleeds.

Thanks unSpawn, i'll check on those stuff.

I'm going to disagree with you here. SSH is a great tool and if used properly it is no more insecure then any other form of connection.

1 members found this post helpful.

The key is to utilize a firewall to limit access to ports only to those who should access those ports..

In my experience, you usually have to open port 80 and port 443 to the world at large because these are the ones that server HTTP and HTTPS traffic, respectively. I always try to limit port 22 (the ssh port) such that only me and my web dev collaborators can connect to it.. This is not always possible -- like if you offer shared hosting or want to be able to connect to a machine from anywhere -- but you can usually set up something pretty restrictive and then open it up to specific IP addresses on request if your dev team is smallish.

Other ports, like MySQL server or something should probably not be open to the public either. Every open port, where some application is listening, offers a potentially exploitable doorway into your machine.

The problem that I have with it is that ... the L33T H4X0R who starts hammering your sshd with passwords doesn't give a tinker's dam whether " the shell that is now offering him a login: prompt " encrypts its traffic or not. He has an avenue by which he can attempt to log-in to your system, and (by default ...) he needs nothing more than a password by which to do it.

(1) Obviously, ssh sometimes is "the pragmatic tool-of-choice." But there is a "right way" and a "wrong way" to do it ... and, there is a 'sticky' in this very forum which talks about what's right and what's wrong. The "right way" consists of digital certificates, where the fall-back use of "passwords" is specifically excluded.

(2) (Open)VPN ... once again using digital certificates ... is a superior alternative (IMHO) because it offers blanket protection. It manifests itself as "a secure router," and therefore is available equally to any-and-all clients on your local network. They don't have to "be sure to be doing the proper thing" in order for their communications to be secure: it just is "secure." (P-r-o-v-i-d-e-d ... t-h-a-t ... "PSKs == passwords(!)" are not being used to (in-)secure the VPN link!)

The crypto term for this is ... "entropy." A password, any(!) password, contains very little entropy. Therefore, it can reasonably be "guessed," and therefore, "forged." A digital certificate consisting of thousands of truly-random bits ... cannot. Such a certificate is not only un-forgeable, but it is also unique.

If you work in any office building, I daresay that you had to use some kind of badge to get to the place where you are now sitting. I'm sure that there was not someone standing there, asking you to "say the magic word."

1 members found this post helpful.

"You got to stop thinking so negative son!!" Go back and read my post once again and re-read the word "Properly" several time and let it sink in.

There are several ways to secure ssh and keep the " L33T H4X0R " out.

The problem with naive password enabled SSH is that they already know one user name - root, so all they have to guess is the password! So ___ALWAYS___ disable root login via SSH!

But even so, getting or guessing a user name is often not as difficult as you might think, and without something else limiting the number of guesses or blocking the path, it is almost inevitable that a sustained probe will be successful.

SSH with shared keys and disabled passwords effectively blocks that path - if you guard your keys.

Even so, moving it to a non-standard port and blocking by IP after a few failed attempts is still worthwhile.

I limit by iptables rules - 3 requests in 5 minutes gets you banned for an hour. 6 requests in 30 minutes gets you banned for life. Even so I still see adaptive bots probing at a sustained slow rate and manually ban them as I see them.

So, SSH is great - but _ONLY_ with shared keys and then _ONLY_ with rate limiting.

1 members found this post helpful.

Waah..so strict heheh.. Actually, better to do that than to be sorry.