Wrong. There's a difference between the sshd master that listens and the individual sshd forks that spawn for each session. After you established a session, you can kill the master completely and still have your session. You just won't be able to create new ones.
An optimal RAID-5 set consists of 3 disks, 5 disks or 9 disks and so on. This is to keep the block size of a stripe (excluding parity) at 2^n so that common filesystems map 1:1 onto it.
To quote Greg Oster, the developer of RAIDframe, a software RAID implementation on NetBSD:
"The 'problem' with 4 disks is that you have (effectively) 3 data disks. Since most times you're doing a 'power-of-two' write (e.g. 16K or 32K), it's impossible to divide that power-of-two data by 3 and have a nice full-stripe write. That leaves you with doing partial writes all the time, and those are the ones that kill RAID 5 write performance."
Actually, you are wrong. In the good ol' times before this Kibi bullshit, capitalisation of 'k' and 'b' mattered unless you made it unambiguous by spelling out byte and bit.
I browse Slashdot with Javascript turned off since there's no need to turn it on here. Nice, old-fashioned passive/static "content" (I hate that word) only please.
I use Slackware tarballs to extract libs needed for Linux compatibility on NetBSD. This way I don't need to install a full-blown Linux tree including rpm tools when I just need some library.
Article mentions the remarker is providing "software". This is very likely a patch to Windows to intercept the calls to the chip fetching its stats, and provide false information back to the caller.
Uhh, this is a very, very ugly way to do things. You twist the semantics of the global namespace and potentially redirect all traffic to those domains to 127.0.0.1.
What if your users are developers running a local httpd?
If you want to block HTTP traffic, use an HTTP proxy. The proper way to implement ACLs is to return a code that indicates "denied", not return false information as if it were real. This only leads to headaches later, when noone thinks about this "solution" anymore and tries to debug a real problem.
In one way, this solution is slightly better than the stupid hosts-file-mangling you see everywhere because it's centralised. OTOH, it's just as stupid as that because it's like driving a screw with a hammer.
There is one case where fiddling in BIND is appropriate. This is cases like omniture.com. They smuggle data through DNS by requesting weird hostnames like [long encoded string].omniture.com. I saw this when browsing through ebay one day. In this case, you have to block on the DNS level, but not by falsifying the information.
I checked out which nameservers are authoritative for omniture.com. Then I checked which networks they belong to. Those networks I put in a blackhole clause in named.conf. So whenever I request something in omniture.com , at least I get a "server failed" which hints me to BIND, should I forget one day that I blocked them.
The well-known security adage "security through obscurity is no security at all" is certainly applicable to NAT. IPv6, whose biggest initial win is a significant increase of address space, has no concept of NAT since no additional security is gained."
I didn't say your ISP does NAT. I really meant the common-almost-everywhere scenario:
ISP ---- [public address] your router with NAT [RFC1918 net]
You said "My border gateway (linux box) does not accept packets for non-routable networks on the external interface". That's a property of the packet filter, not the NAT mechanism. If you had only NAT and no filter, someone at the ISP could setup a route for [RFC1918 net] via [public address] as a gateway and your router would route it. That's what I was saying, NAT without a filter isn't security.
Someone cracks a router at your ISP (not too improbable considering certain Cisco fiascos, right?) and sets up a route to your network. Now what? You NAT box suddenly makes your internal network "public" to the attacker.
NAT is not security. At the very least you're trusting your ISP to never get owned or be malicious. If you can live with that, fine. Just don't tout it as security please.
And with IPv6 and my/48 net, I already have 1,208,925,819,614,629,174,706,176 real addresses, publicly reachable.
What everyone seems to disregard is that you can't just take all possible IPv4 addresses and squeeze them unto different needs as you want. With each splitting of address space comes the problem of increasing routing tables in routers. IPv6 is not only about increasing the address space but keeping its fragmentation low so that routing tables are more efficient. That's why the smallest subnet in IPv6 is/64 and single customers get a/48.
Remember, there are 2^16 times as many/48 networks in IPv6 than there are single addresses in IPv4.
NAT is a *layer* of security, but not security itself.
It's not even a layer. It is nothing security-related. Security comes from the packet filter and the packet filter alone.
Without a filter, your NAT box happily routes traffic destined for the inner network - think rogue ISP or spoofed packets claiming to come from the inside. All that NAT does is rewrite addresses in packets. It doesn't block anything.
Of course, actually getting a packet destined for your inner network to your NAT box is not something any random user on the Internet could do. But "in 99% of cases it's not applicable anyway so it's secure" isn't security actually.
Slashdot Mirror
Because it comes out of Hollywood it must be a true and accurate depiction of how things will turn out, right?
_ robot
Read more: http://www.thebestpageintheuniverse.net/c.cgi?u=i
Excuse me? Where do you live where it _is_ a crime?
Speeding is a regulatory offense at most.
I pity you if speeding or parking violations are criminal offenses where you live.
..or a criminal's worst nightmare.
That's 100% correct. What I fear is just that the definition of "criminal" will change to include normal citizens pretty fast.
How's that for yet another look at it?
Speaking of redundant and useless actions...
No. Thanks for playing.
Anyone now how many packets a Linux router can forward per second?
:)
How many it may be, FreeBSD can do more.
Everyone use Google and wealth and wisdom will ensue!
I guess if they were, they couldn't be used to set TCP transmission records, could they?
Again, what a nice way to push people to 64bit and make everything look outdated that's been in use so far, when all you'd need is a non-sucking OS.
Wrong. There's a difference between the sshd master that listens and the individual sshd forks that spawn for each session. After you established a session, you can kill the master completely and still have your session. You just won't be able to create new ones.
Well, n being variable of course.
4 /19/0011.html
An optimal RAID-5 set consists of 3 disks, 5 disks or 9 disks and so on. This is to keep the block size of a stripe (excluding parity) at 2^n so that common filesystems map 1:1 onto it.
To quote Greg Oster, the developer of RAIDframe, a software RAID implementation on NetBSD:
http://mail-index.netbsd.org/current-users/2002/0
"The 'problem' with 4 disks is that you have (effectively) 3 data disks.
Since most times you're doing a 'power-of-two' write (e.g. 16K or 32K),
it's impossible to divide that power-of-two data by 3 and have a nice
full-stripe write. That leaves you with doing partial writes all the
time, and those are the ones that kill RAID 5 write performance."
From that I figured the 2^n+1 rule.
Actually, you are wrong. In the good ol' times before this Kibi bullshit, capitalisation of 'k' and 'b' mattered unless you made it unambiguous by spelling out byte and bit.
1kb = 1000 bits
1Kb = 1024 bits
1kB = 1000 bytes
1KB = 1024 bytes
I browse Slashdot with Javascript turned off since there's no need to turn it on here. Nice, old-fashioned passive/static "content" (I hate that word) only please.
Oh and BTW, thank you, http://www.noscript.net/
I'd want eight of them to put into a raid 5 array.
No you wouldn't. You would want 2^n+1 drives in a raid5 array to maintain at least some performance.
I use Slackware tarballs to extract libs needed for Linux compatibility on NetBSD. This way I don't need to install a full-blown Linux tree including rpm tools when I just need some library.
.tar.gz!
Yay for
Article mentions the remarker is providing "software". This is very likely a patch to Windows to intercept the calls to the chip fetching its stats, and provide false information back to the caller.
:)
But.. does it run under the Sony rootkit?
Uhh, this is a very, very ugly way to do things. You twist the semantics of the global namespace and potentially redirect all traffic to those domains to 127.0.0.1.
What if your users are developers running a local httpd?
If you want to block HTTP traffic, use an HTTP proxy. The proper way to implement ACLs is to return a code that indicates "denied", not return false information as if it were real. This only leads to headaches later, when noone thinks about this "solution" anymore and tries to debug a real problem.
In one way, this solution is slightly better than the stupid hosts-file-mangling you see everywhere because it's centralised. OTOH, it's just as stupid as that because it's like driving a screw with a hammer.
There is one case where fiddling in BIND is appropriate. This is cases like omniture.com. They smuggle data through DNS by requesting weird hostnames like [long encoded string].omniture.com. I saw this when browsing through ebay one day. In this case, you have to block on the DNS level, but not by falsifying the information.
I checked out which nameservers are authoritative for omniture.com. Then I checked which networks they belong to. Those networks I put in a blackhole clause in named.conf. So whenever I request something in omniture.com , at least I get a "server failed" which hints me to BIND, should I forget one day that I blocked them.
Read my post further down from the one you replied to.
someone at the ISP could setup a route for [RFC1918 net] via [public address] as a gateway and your router would route it.
There. To prevent that, you need a filter. NAT alone provides no security. Must have been the 45634576745764576th time now I said that.
Quick google for "nat is not security" came up with: http://safecomputing.umich.edu/tools/download/nat_ security.pdf
"Conclusion:
The well-known security adage "security through obscurity is no security at all" is certainly applicable to NAT. IPv6, whose biggest initial win is a significant increase of address space, has no concept of NAT since no additional security is gained."
I didn't say your ISP does NAT. I really meant the common-almost-everywhere scenario:
ISP ---- [public address] your router with NAT [RFC1918 net]
You said "My border gateway (linux box) does not accept packets for non-routable networks on the external interface". That's a property of the packet filter, not the NAT mechanism. If you had only NAT and no filter, someone at the ISP could setup a route for [RFC1918 net] via [public address] as a gateway and your router would route it. That's what I was saying, NAT without a filter isn't security.
Someone cracks a router at your ISP (not too improbable considering certain Cisco fiascos, right?) and sets up a route to your network. Now what? You NAT box suddenly makes your internal network "public" to the attacker.
NAT is not security. At the very least you're trusting your ISP to never get owned or be malicious. If you can live with that, fine. Just don't tout it as security please.
And with IPv6 and my /48 net, I already have 1,208,925,819,614,629,174,706,176 real addresses, publicly reachable.
/64 and single customers get a /48.
/48 networks in IPv6 than there are single addresses in IPv4.
What everyone seems to disregard is that you can't just take all possible IPv4 addresses and squeeze them unto different needs as you want. With each splitting of address space comes the problem of increasing routing tables in routers. IPv6 is not only about increasing the address space but keeping its fragmentation low so that routing tables are more efficient. That's why the smallest subnet in IPv6 is
Remember, there are 2^16 times as many
NAT is a *layer* of security, but not security itself.
It's not even a layer. It is nothing security-related. Security comes from the packet filter and the packet filter alone.
Without a filter, your NAT box happily routes traffic destined for the inner network - think rogue ISP or spoofed packets claiming to come from the inside. All that NAT does is rewrite addresses in packets. It doesn't block anything.
Of course, actually getting a packet destined for your inner network to your NAT box is not something any random user on the Internet could do. But "in 99% of cases it's not applicable anyway so it's secure" isn't security actually.
What you suggest as "choices" are nothing more than kludges which wouldn't be necessary if everyone had IPv6 and a publicly routable address space.
Pay for a shell account and provide services over a SSH tunnel? That's brilliant! Why get IPv6 when the "solution" is so obvious. Duh.
Pay for a real IP(v4)? Brilliant! We don't need plenty of IPv6 addresses for everyone when we.. uh.. can just buy IPv4 addresses.
Move to a "boutique" ISP to get "real" IP adresses?
Dude, what you list are problems that IPv6 will solve, not choices that make IPv6 unnecessary. I suggest you get a reality check.