Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Re:screen (Score 2, Insightful) 307

RTFM.

That's why you set a screen password. Control + A, : password ENTER

The attach cannot proceed without typing the password. The password cannot be changed (for an already running session) without attaching first.

From the screen man page:

password [crypted_pw] Present a crypted password in your ".screenrc" file and screen will ask for it, whenever someone attempts to resume a detached. This is useful if you have privileged programs running under screen and you want to protect your session from reattach attempts by another user masquerad- ing as your uid (i.e. any superuser.) If no crypted password is speci- fied, screen prompts twice for typing a password and places its encryp- tion in the paste buffer. Default is `none', this disables password checking.

So what does screen actually do to protect the programs inside? I mean with the privileges to attach the screen and not knowing the pw, you usually also have the privileges to debug the bastard and skip the pw check altogether.

Comment Re:encryption alone (Score 1) 660

is not the whole solution.

How true. In transport crypto is almost futile nowadays (original SSH was deployed on coax ethernet networks where anybody could see your pw, today it's another story).

Authentication crypto has the burden of certificate management (do you verify fingerprints of each https site you visit?)

In the light of botnet compromises, crypto achieves precisely nothing (bot controlled agent can do/see exactly the same stuff as local user).

Consumer crypto has mixed success stories (see GSM and satellite TV smartcards).

Static data crypto (on-disk) brings key management hassle (crypt the daily backup, but backup the keys to a different place) and opens a field for legislative battles (i give my disk key to my lawyer).

Finally, crypto of any kind itself is hard to get done right and bad crypto is worse than no crypto (Debian openssl epic fail). It requires powerful hardware. And of course, some enlightenment of the staff, tighter procedures, etc.

So crypto deployment is always to be weighed against these (and other) downsides.

Comment Re:On Which Planet? (Score 1) 460

I drop them at my firewall too.

If a public traceroute server is tracing to a private block, it won't be my private block, but some other use of the same range.

The point of that exercise is to see that not all of the routers are so vigilant. Plus there's things like source routing, ipip tunnels, and what not, all of those just begging you to abuse them. On some broadband/cable ISPs you can target your neighbor victim directly if you are lucky. Some time ago there was a presentation about hijacking cisco vpns (i can't remember more about it) ... point being that there are lots of unforseen ways to sneak into 'private address space'. A pure NAT router (without fw or source route checks) will just route packets to 10.0.0.0 like any other ones.

Most devices that do NAT would have to be specifically configured to allow this, by default they have an inbound deny rule. Even if they do, you've lowered your attack surface to things local to your ISP's router.

I don't know what is the status quo of today but about a year ago I was still seeing ISP's giving out routers will very sick defaults. Wifi-able ones with even criminally sick defaults. Want free 'net? Go to some apartment building and ride someone's well-NATed connection.

Say I have 200 PC's behind a NAT box. Six of them have remote vulnerabilities. How can somebody in North Korea exploit those?

Well he can try one of the hacks above, maybe he gets lucky. If not, then the packet was dropped, which is a work of a firewall, not a NAT. He will then proceed to zombifying one of your secretarys' boxes (or worse, one of your executives' laptops) and then pwn the target from there, because the internal network will be insecure and open. What you should do is to put all devices that can't defend on their own onto a separate network segment and place at least a very restrictive firewall between that network and the rest of the world, including your corporate internal network. If you've already done that, then good work! You don't need NAT anymore, except if your ISP is not willing to give you enough IP.

but also introduces a complexity in address rewriting and therefore might introduce a whole bunch of security issues on its own.

That's plausible. Do you happen to know of any examples?

Just google for 'nat vulnerability linux' for some. No piece of code is perfect and I would be very surprised if address rewriting ever worked flawlessly. In fact, Linux might be on the better side due to FLOSS, many commercial boxes might be even more emental-ish.

And of course the N:1 property alone of the NAT opens its own field of problems.

Quite so. But that doesn't mean NAT doesn't add to the total security.

It hardly does in the light of the hassle, the inherent issues, and potential can of worms effect.

Such an admin will then be horrified by the mere thought of having IPv6, since that would put all of his naked boxes right on the evil Internet without the condom of NAT, OMG!

And IPv6 has an abysmal adoption rate...

Well this is going to be a "me" comment; I have adoped as early as circa 2000 (I still got the ip6.int file from those days ;), and it hardly can be any problem today for a determined person. If your ISP sucks at IPv6, pick anoter one or dig a tunnel. Besides the original statement was not concerning IPv6 as such, but the fact that its implementation will expose the network to the 'net and thus drop any hopes for NAT being a security measure. North Korea can suddenly connect to your microwave, scary eh?

Actually there is one more common mentality problem here: "my OS supports ipv6, but i dont have ipv6 connectivity, so i need not bother with securing ipv6. right?" ... wrong. ;)

Most client boxes run absolutely no services (maybe ssh), even windows can have a great deal of its server capability disabled.

When you say 'most', Windows is usually what exists as 'most'.

Yes and I still think most if not all of the dangerous stuff can be turned off. You don't necessarily need a firewall/antivirus to survive on the 'net with windows, and some 5 years back I successfully managed a handful of XP laptops that way. We eventually bought stuff from symantec, but that was more on the grounds that we hired a lot of people and we could not afford to enlighten every computer user anymore.

Further, service exploits were the music of the early 2000's, by now almost all of the services can withstand direct exposure to the Internet (with the exception of silly newcomers)

That's not so. Nearly every month, on Patch Tuesday, Microsoft puts out a bulletin about new exploits available to remote unauthenticated users. Go check out the US CERT archive to see for yourself.

True. I guess I was not thinking of Microsoft servers when I wrote that sentence. Their stuff is 2000-ish anyway. ;)

"A very large security threat". Absolutely. That doesn't mean remote exploits are no longer a problem. Check our your Snort logs - people don't just do that because they feel like wasting bandwidth.

Yes you have a point here. Remote exploits are a problem, but the proportions have changed during the last 10 years or so. Remote attacks are now just a momentary spike in the much larger volume of indirect attacks. With spike I mean the majority of the remote attacks are either (1) ssh brute force scans - that's not a remote exploit of the service but of its ill configuration (weak pw) OR (2) the exploit wednesday following the patch tuesday ;)

Comment Re:Don't say "NAT" (Score 1) 460

You can. I can. Aunt Myrtle can't. I for one am glad that most home users are behind NAT these days. It's better than nothing.

No. Aunt Myrtle is fine at her home with the modem in BRIDGE mode and with the default settings of her vi$ta PC. (Just as she clicks on the bench icon in the network setup wizard.)

And probably she's far better than a lot of the corporate users with their own "professional" IT staff.

Comment Re:On Which Planet? (Score 2, Insightful) 460

That's great - your network is properly configured. Most aren't.

NAT isn't required, it just makes up for poor administration.

Bah. You just gotta love that attitude. Actually the most plain view of the NAT security is not the inbound firewall but the persumably unroutable private block that's behind it. "We can't do our work properly so we stick our gear where they can't attack it. After all, our network has private addresses so the evil asian guys can't get to it. Right? RIGHT?" Wrong.

Wrong in oh so many ways.

First off, private addresses are NOT unroutable, they just happen to be dropped on their way through your ISP (if they do their job properly). Just try a traceroute to a private address and see how far the trace gets. (And try it from a public traceroute server ;) Try putting a server on the other side of your beloved NAT and you might just discover that you can ping into your private network.

Second, even if this works as advertised it does not pose any great advantage over a stateful firewall. To the contrary, NAT not only tends to fuck up many L4 protocols, but also introduces a complexity in address rewriting and therefore might introduce a whole bunch of security issues on its own.

The third problem is the NAT admin's typical mentality. People tend to satisfy themselves with such a global protection shield (tm) and neglect going into the detail of securing their private network properly. "LAN hosts" are often left with their own firewall off, with simple or even default admin passwords, a lot of non-pc appliances (printers, phones) left to their own fate etc. That just makes a perfect base for the all-or-nothing principle, which goes so against any security reasoning. Such an admin will then be horrified by the mere thought of having IPv6, since that would put all of his naked boxes right on the evil Internet without the condom of NAT, OMG!

Finally AND MOST IMPORTANTLY please ask yourself how much of the total security is provided by blocking inbound traffic. Most client boxes run absolutely no services (maybe ssh), even windows can have a great deal of its server capability disabled. Further, service exploits were the music of the early 2000's, by now almost all of the services can withstand direct exposure to the Internet (with the exception of silly newcomers). The real security threat comes from outbound connections, people going to nasty sites, or people going to legit sites (banks) with silly passwords, flipped staff, and so on and so on. The vast majority of compromised zombie machines is on broadband, which means a router with NAT or "stateful firewall".

Comment Re:Those security warnings remind me of... (Score 1) 432

Exactly. I have observed many times how even technical support people, admins, etc., that should be skilled at this, just dismiss any dialog window with the OK button without even reading it. You can't then wonder that the browser's security warnings are treated the same way. Hiding the OK button in dust like it has been done in FF3 is just futile.

Comment lockout equals DoS (Score 1) 553

TFA suggests countering brute force attacks with lockout mechanisms. I'm sure the users will be happy about not being able to log in just because their password was recently brute-forced. Any lockout mechanism is vulnerable to DoS, please remember that forever. And don't argument with IP address restrictions.

Slashdot Top Deals

No directory.

Working...