chrism@imntv.com wrote:

That doesn't really have much affect anymore. The bad people are now scanning high ports looking for any sshd (or other service) that's listening.

they aren't "people", they are virus/worms... blindly poking at ports and trying the same lame list of passwords.

you can't make them stop, unless you control the entire world... just ignore the noise.

I find it kind of odd that noone has come up with a 'RBL' for bots...

ISPs could easily receive routes via BGP from "some trusted source" that has NULL routes for all of the 'infected' hosts which are attacking people..

A few dozen honeypots and you would quickly have a large list of infected hosts in which to ignore entirely.

-Drew

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of chrism@imntv.com Sent: Thursday, February 15, 2007 11:10 AM To: CentOS mailing list Subject: Re: [CentOS] Defending againts simultanious attacks

John R Pierce wrote:

chrism@imntv.com wrote:

...

That doesn't really have much affect anymore. The bad people are now

...

scanning high ports looking for any sshd (or other service) that's listening.

they aren't "people", they are virus/worms... blindly poking at ports and trying the same lame list of passwords.

you can't make them stop, unless you control the entire world... just ignore the noise.

I think everyone on the list is aware of the automated nature of the attacks. And I *do* ignore the noise.

Cheers, _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Thu, February 15, 2007 1:15 pm, Scott Silva wrote:

Drew Weaver spake the following on 2/15/2007 8:27 AM:

...

I find it kind of odd that noone has come up with a 'RBL' for bots...

ISPs could easily receive routes via BGP from "some trusted source" that has NULL routes for all of the 'infected' hosts which are attacking people..

A few dozen honeypots and you would quickly have a large list of infected hosts in which to ignore entirely.

ISP's are in the market to sell bandwidth. And bots use bandwidth. Even if an ISP would just police it's own address space it would help. At home I have roadrunner, and they have no problem blocking "incoming" port 25 and port 80 traffic, but have no problem letting a connection blast away at everybody outgoing. So I can't have a simple webserver, but I can have a spamming operation. Go figure!

Speakesy.net polices their network properly and allows servers in the TOS. One of the few left. And they do police their network for open relays. They rule!

There is for ssh.

Denyhosts has a syncronization mode where you can share info back to the community.

http://denyhosts.sourceforge.net/

See the faq for sync mode.

On Thu, Feb 15, 2007 at 11:27:05AM -0500, Drew Weaver said:

I find it kind of odd that noone has come up with a 'RBL' for bots...

ISPs could easily receive routes via BGP from "some trusted source" that has NULL routes for all of the 'infected' hosts which are attacking people..

A few dozen honeypots and you would quickly have a large list of infected hosts in which to ignore entirely.

-Drew

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of chrism@imntv.com Sent: Thursday, February 15, 2007 11:10 AM To: CentOS mailing list Subject: Re: [CentOS] Defending againts simultanious attacks

John R Pierce wrote:

...

chrism@imntv.com wrote:

...

That doesn't really have much affect anymore. The bad people are now

...

...

scanning high ports looking for any sshd (or other service) that's listening.

they aren't "people", they are virus/worms... blindly poking at ports and trying the same lame list of passwords.

you can't make them stop, unless you control the entire world... just ignore the noise.

I think everyone on the list is aware of the automated nature of the attacks. And I *do* ignore the noise.

Cheers, _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Thanks everybody.

there quit a lot and very useful information for a newbie like me. i'll have a look into some of the suggestion, almost all of them a new to me. i'll try them by myself, and might be get back to you guys if there is any problem.

thanks.

On 15/02/07, Jens Ahlin mailing_lists+centos@caleotech.com wrote:

Why not change the port that the SSH daemon listens to. Change it to use an unused port > 1024 and you will see that the attempt will stop.

  Jens

...

Hi,

i have one centos 4.3 box, exposed to the internet. since several weeks ago, i found numerous attemps to connect through SSH, but failed.

they tried with many username, including root. it's comes from different IP. some of them are foreign website.

How do i make my centos become smarter in handling this kind of attacks.

eventhough i've disable all the user accounts, left only the admin accounts. making the password so hard, longer and combining alphabet, numbers and characters... yet i dont want the attackers keep on trying.

any suggestions?

thanks in advance. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Oh my ... im not a policeman, but that may have been a freudian slip?

I meant "Port Knocking", and i have no idea what "Pork Knocking" is, although it does sound like an old english sport of the common people?

Regards,

MrKiwi

MrKiwi wrote:

I have *never* had an ssh attempt on my boxes with non-standard port numbers. I (used to) get *hourly* attempts on port 22.

If you really want to get paranoid though, have a look at the various port openers. "Pork knocking" is the phrase you need to google for.

Regards,

MrKiwi

Kamill S wrote:

...

Hello,

you can let listen sshd on Port 222 for example. Edit /etc/ssh/sshd_conf

In line #Port 22

Greetz

Mohd Syakir wrote:

...

Hi,

i have one centos 4.3 box, exposed to the internet. since several weeks ago, i found numerous attemps to connect through SSH, but failed.

they tried with many username, including root. it's comes from different IP. some of them are foreign website.

How do i make my centos become smarter in handling this kind of attacks.

eventhough i've disable all the user accounts, left only the admin accounts. making the password so hard, longer and combining alphabet, numbers and characters... yet i dont want the attackers keep on trying.

any suggestions?

thanks in advance. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Beware of the thread ...

http://slashdot.org/it/04/02/05/1834228.shtml?tid=126&tid=172

on Slashdot regarding Port Knocking - there are some good points, but loads and loads of misinformation and uninformed whining about Port Knocking lowering your overall level of security.

Regards,

MrKiwi

John R Pierce wrote:

MrKiwi wrote:

...

Oh my ... im not a policeman, but that may have been a freudian slip?

I meant "Port Knocking", and i have no idea what "Pork Knocking" is, although it does sound like an old english sport of the common people?

in a nutshell, your server listens for a special packet on a arbitrary port, then allows the source IP of that packet to make a connection on another port. for instance, a UDP packet to port 3515 with a specific payload, and you then open up SSH on 22 to the source of that UDP for the next 10 seconds or whatever.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

M. Fioretti wrote:

On Sat, Feb 17, 2007 13:34:39 PM +1300, MrKiwi (mrkiwi@gmail.com) wrote:

...

Beware of the thread ...

http://slashdot.org/it/04/02/05/1834228.shtml?tid=126&tid=172

on Slashdot regarding Port Knocking - there are some good points, but loads and loads of misinformation and uninformed whining about Port Knocking lowering your overall level of security.

May we ask you to sum up in a few lines both the good points and the misinformed/whining ones?

Thank you in advance,

Marco

Sure;

Gems/Insightful comments.

"Thus, it is impossible to distinguish a totally silent box (listening on no ports, dropping all packets) that has implemented port knocking from a box that is merely totally silent."

"The idea has been around but this is the first real implementation I've heard of; would make port scanning completely useless. The problem is relying on additional client-side tools. I guess you could manually telnet to a series of ports quickly, then opening the ssh connection but the special packet idea wouldn't work unless you had proper tools on the client side." [Note there are now many client side tools (nix/win/mac) which implement port knocking and/or SinglePacketAuthorization]

"The funny thing is, why open up ports in a general fashion? Why not just open up those ports to connections from the IP that knocked?"

Most good implementations do just this - you knock, the port knocking server opens the firewall for ONLY your ip to connect to ONLY one port. EvilHacker can still scan the server and find no open port.

"Don't rely on something remaining secret unless you're willing to protect it as a secret. This "knock to open" is just another hoop a cracker has to jump through on the way into your machine. It will stop the clueless ones cold until they read about how the observant ones got around it, then it won't stop anybody. But it might also lull the owner of the box into a false sense of security, and to the extent it does, it's a bad idea."

The first part of this is true - but in the same way that "brute forcing an encrypted packet before its payload becomes of no value" is another hoop that thankfully few crackers have managed to jump through. In my opinion, port scans which lead to login or cracking attempts will still make up the bulk of malicious traffic for a long time yet. Port knocking reduces your visibility. The enemy already has infrared goggles, so why does the army still wear camo? The second point is the most dangerous part of port knocking - a false sense of protection.

Whines/Missed the point/Plain wrong.

1. "This doesn't seem like much of an advantage over simply using different ports for services"

It has the advantage of being able to use standard OR non-standard ports, however only *your* clients can even see the open port to connect to. An analogy would be; a lock-picker can easily pick your door lock. If he must know a special 'knock' pattern before he can even see/touch the lock, his lock picking skills become much less valuable.

2. "the whole thing seems kind of insecure to me without a method to dynamically change the knocking sequence"

No - All port knocking does is hide the open port from people who dont know the knock. (caveat below). This in no way introduces any kind of insecurity. Caveat: port knocking can be implemented with crypto-style payloads to eliminate the risk of a replay attack, so even knowing the port knock sequence doesn't open the port if you don't have a way to generate the correct packet payloads. I don't know much about this, however there is a more advanced version which builds on this (and other concepts too) - Single Packet Authorization. Google it.

3. "Something tells me I'm going to be seeing a lot bigger firewall logs in the future, as this catches on."

Nope - No more than the 000's of log entries you already get from port scans.

4. "Open a whole range of ports--say, a couple thousand. Then an attacker won't (easily) be able to try all the possible knock sequences."

This misses the point - you leave the ports closed. An attacker cannot (easily) tell the difference between a port-knocking protected ssh port, and a server which is not running ssh. In both cases, the ssh port is closed. In the first case, it only opens after you knock on a seq of *closed* ports. In the second case, no combination of knocking on ports will open the ssh port.

5. "Ports that are closed but part of the knocking scheme would return a connection refused, while all the other (filtered) ports would simply be dropped"

No - Your firewall will not REJECT the packets, it will DROP them, no differently to before port knocking.

6. "This isn't going to catch on. It's not more secure and it wastes more resources. Why would this be any more secure than listening on a single port for the "unique knock sequence?" Any good admin knows the most secure system is one that is listening on as few ports as possible."

Missed the point completely. I will break it down; a. "This isn't going to catch on". Thanks Nostradamus, but it already has. b. "It's not more secure ..." Yes it is. Crudely, less open ports => more secure. c. "and it wastes more resources." - No. A watched series of ports takes barely more resources than `tail firewall.log|portknockingserver`, and many times less than are used when an attacker connects to an open port. d. "Why would this be any more secure than listening on a single port for the "unique knock sequence?" Because listening 'on a single port' would be either an open port, or opened by a port scan. e. "Any good admin knows the most secure system is one that is listening on as few ports as possible." Yay! you got one right. The word 'listening' is an unfortunate term for what port knocking servers do. 'Watching' would be better. They dont open any of the watched ports.

7. "i submit it could actually be less secure... 1. dos attacks! 2. sniff the port knocks"

No - DOS requires that you (the attacker) consume resources on the target box to a point where services are denied to legit users. If a vicious level of port scans cannot DOS the firewall, then a well implemented port knocking server will not be easily tipped over by this. It has been shown that even in the middle of a DOS attack, a port knocking implementation will still open the ports for legit users, however there is one situation where you can replay packets to prevent a valid user getting an open port. SPA solves this issue. Sniffing the port knocks only gets you an open port ... you still need all the skill/luck to break (say) ssh once you get an open port, so it is no less secure than a web facing ssh port. In fact some implementations close the port after x failed attempts, so basically you are wrong.

8. (in reply to the suggestion to use one-time port sequences) "If you're going to go so far as to require a one-use pad, then you can forget about the whole "port knocking" concept -- there's no stronger password than a 1-use password."

Missed the point. Port knocking mitigates zero-day security issues, like ping-of-death etc. Even the most simple port knock seq will protect you from portscan->automated hacks. No password - even shell=/dev/null - will protect you from that. The point is that of your ports are open, your pants are down.

That pretty much wraps it up.

MrKiwi,

M. Fioretti wrote:

On Sun, Feb 18, 2007 16:49:02 PM +1300, MrKiwi (mrkiwi@gmail.com) wrote:

...

...

...

Beware of the thread ...

http://slashdot.org/it/04/02/05/1834228.shtml?tid=126&tid=172

on Slashdot regarding Port Knocking - there are some good points, but loads and loads of misinformation and uninformed whining about Port Knocking lowering your overall level of security.

May we ask you to sum up in a few lines both the good points and the misinformed/whining ones?

[...]

That pretty much wraps it up.

MrKiwi,

Whoah! Thanks for the quick and very detailed answer. I look forward to read further comments to it from other expert sysadmins here. Me, I'll print it out and mull it over for 3/4 days to metabolyze all the concepts, so don't be surprised if you don't hear from me again on this topic soon, but it is really helpful.

Thanks, Marco

Oh - I`m no expert sysadmin, i just listen to lists like this and pick up what i can. This list (and many other resources like /.) have taught me a lot about filtering hype/FUD/misconceptions from fact/useful advice.

Remember that no good review of port knocking would be complete without a strong recommendation to read up on Single Port Authorization. (Authorisation for fellow Kiwis)

Regards,

MrKiwi