This group should mostly be dealing with how web applications enable networking security issues that are otherwise not there. Everything is being tunneled over port 80 now so what does that enable and how do we fix it?

i would use fwknop (single packet authorization) which is an advanced form of portknocking. portknocking can be as simple as a script that sits in front of your sshd.

i had some recursive thinking the other day that led me to envision a future where even http was restricted behind a portknocker (because of the current day proliferation of web application attacks). for example, it would be similar to the CVV2 (3 digit number on the back of MC/Discovery/VISAs, or the similar 4 digit CID number on the front of AMEXes) on your credit card is a 3DES cipher of your card number and your banks give you that in the mail.

why couldn't banks just give out online banking cards that contain your private key to a portknocking system... every user could be on his/her own IP/Port or even something like a hidden Tor node. imagine taking the chroot/jail/grsecurity concept to the network level...

I have a few accounts on my SSH server set up with a password of "password", running a fake bash shell which logs any commands and returns an error message. Very few people actually attempt to do anything once they find an open account, so I wouldn't worry about it too much (unless your password is "password", the name of the user, or "test".)

takes 5 mistyped ones with my script, but it really isn't the best way to do things in the long run, if someone exploited that script you might have even bigger problems. A clever attacker could change his username to exploit the un-sanitized input from the authlog.

That was just an example, the real fix is for sshd to be changed to rate limit incoming connections and maybe work with pf to perma block obnoxious attackers.

the solution of limiting the connection rate is inherently flawed, it only limits the rate of 'acceptable' bruteforce, which will have a higher false positive effect (overcafeinated, sleepless admin is a good exemple of somebody who can look like a bruteforce :) when lowering the max-src-conn-rate

actually the only fun AND heavyweight option i have found is to deceipt & divert to either a blackhole route (for the quick and dirty), low interaction honeypot (LaBrea is an excellent tarpit for TCP) or for the real bored, a high interaction one, (linux disk image, regenerated every hour, with a uni-directionnal full logging system)

a small number of service (let's say just ssh and http/https) are opened in the legit subnet

the logical behavior should be to forcefully deny any other service at the firewall level. but we're not really logical.

we just NAT *everything else* to the honeypot *and* we insert each IP being NATed to the honeypot in a list (when if first implemented this it was for a IPTable configuration, so it was in fact handing the IPs to a perl script taking care of maintening a file list, and checking against it. slow if not in a ram tmpfs)

now back to the ssh bruteforce.

what's doing the NIDS in the meantime ? his work. monitoring packets, magically dissecting them, and plenty of other mem hungry stuff. but hey, what's this IP trying to connect with *12* different user on the ssh server ?
now the offender IP gets in the magic list, and all his bruteforce attempt (which we can stop. or not.) will get NATed to our counter measure host. if you are using LaBREA it will *really* slow it down. if you are using a blackhole route, well, it will be... blackholed (thanks captain obvious ! have this rock), and an high interaction one opens many fun possibilities (if it was a botnet, you now have a live agent to play with, if it was a 0-day (assuming *of course* it didn't target the real services, which statistically would be a slight chance), you have a new 0-day to play with, etc...

of course this is like using a full tank compagny to crush one student, but it has the advantage of taking care of network level attacks and plaintext applicative attacks on a early basis. and you could take care of the encrypted payloads by letting a box before the NIDS, and forwarding the plaintext to the server (varnish is quite a killer for reverse proxying)

i realize that it is clearly a heavyweight setup, but i think it is an interesting setup to deploy, and should prevent the majority of network based attacks. of course the standard security measures like patching, password strenght checking and the like are still necessary. one question that i am still on is that those stupid ssh bruteforce bot are *very* active. but since 4 years it's still the same users, and the same dictionnary password. wtf ?

could it be the same worm from the start ? that would be quite strange, the samples i have acquired having *no* payload at all...

changing the default port is not a solution to anything, and some services *have* to be generally available or they offer no value, such as OpenVPN and ssh, the goal is to secure the services you *have* to have out there.

No company of any size can lock down access services to just a subnet or two, doesn't work that way.

Ok, fact of the matter is people who are going to scan for SSHds to brute force are not going to scan 65535 ports on a host before moving on the the next one. They are just going to hit tcp/22. thats it. either you tell the world you are running an sshd and the version of it, and likely the OS as well or you don't.

I do not want to seem confrontational, I am just engaging a discussion of different opinions.

but your comment on " No company of any size can lock down access services to just a subnet or two, doesn't work that way."

Any company that can not control the presence of their infrastructure is doomed. Administration should not even happen remotely unless via VPN. When there is a will there is a way.

MAdhaTTer-240 Wrote:
-------------------------------------------------------
> Ok, fact of the matter is people who are going to
> scan for SSHds to brute force are not going to
> scan 65535 ports on a host before moving on the
> the next one. They are just going to hit tcp/22.
> thats it. either you tell the world you are
> running an sshd and the version of it, and likely
> the OS as well or you don't.

If your worried about being caught with an exploitable version of ssh by a bot, or just don't want to worry about your logs filling up, sure, go ahead and change the port and train your entire staff to modify every ssh client that they might use to get into your network with. But those are the *only* reasons to do it, security is not a reason to do it.

Any directed attack you're going to worry about is going hit more than just a single port, changing ports is not a security enhancement.

> but your comment on " No company of any size can
> lock down access services to just a subnet or two,
> doesn't work that way."
>
> Any company that can not control the presence of
> their infrastructure is doomed. Administration
> should not even happen remotely unless via VPN.
> When there is a will there is a way.

If your company needs remote access, and the source addresses of those connections are not known beforehand, the company will open up access from *any* source. That's how it works. You could try and blacklist the Ukraine, but in the end we all know blacklisting isn't security, it's convenience.

My company is only 5 people, but in any given month we'll ssh/vpn from Asia, Europe, and all over North America, there is no way to know what source network we will be coming from, so I have to have *some* service available from *anywhere*. Sure I could either use just VPN or just SSH, but both can be secured well enough with proper controls. Though using two methods of access leads to a slight theoretical decrease in security, in practice the value to our company in having the flexibility far outweighs that slight risk.

Security isn't shutting off services, it's managing the balance between risks and value.