The hurting sales I can accept, but I don't buy the line about "spoiling it for everyone else". The only way you would find out the ending is if you were looking for it.
How? If you're going to do it by making all traffic pass through the firewall, you could do it more easily and securely by physically isolating the server. Though I still don't see how not being to access server B from server A is a risk when server B is publicly accessible.
What I meant is that if the rootkit's sophisticated enough to avoid detection by my non-firewall measures, it's likely to be sophisticated enough to avoid detection by the dedicated firewall.
I can't imagine a real enterprise adding 20 mac minis to 50 x86 desktops. There are policies and things, if you did switch it would be the whole lot, and it would be a long term thing.
The point is that html supports this handy thing called links. You have made good use of them, but the article submitter could have done so. If the average slashdotter is going to have to use google to find out what it is (and judging by the number of "what is it" posts, in this story they do) then the submitter should include a link to the relevant result.
We believe in free speech. Free speech doesn't mean anything unless it includes the right to say unpopular things. On the incitement of hatred, for the overall good of us.
Huh? USE=-static set, just emerge zlib, takes maybe 20 minutes on a slow system, and there you are. And it will be a faster version. The linux scheduler is good enough that if you run it at nice 19 the compile won't affect your use of the system.
I haven't used Python or OCaml, but if either of those languages can produce C-style.lib's,.dll's,.so's,.obj's, whatever, then they'll work as well from C.
Python can't, at least without embedding the python interpreter in the dll.
What's more, you say that C can work with (at least as a library) every other language out there. So what's the problem with a small C-language interface that just calls the Python function and returns the result?
Any language supports calling C libraries from that language. You have to, because for many things the only library available is in C, and there are millions of C libraries. Not so many support calling that language libraries from C - why would they? A big part of their attractiveness is their extensive standard library.
For zlib it would be too slow. This is an incredibly low level library. It's used in networking, so it has to run on routers. It's used in png, so anything that displays graphics has to be able to run it. There's really no alternative to C/C++, it needs to be crossplatform, complieable, and run on embedded systems. Maybe OCaml since that's compilable, but even that might have too much overhead, plus not so many coders know it.
Or maybe they've put the effort in to actually get the two working and compatible?
It can be done. I'm writing this on a slackware system that uses emerde. I can emerge or use gentoo binary packages for programs, and I can use slackware packages. The two fit together perfectly, the programs update the "database" of each packaging system from the other one. Although it would be harder with the more complex rpm and deb, I don't think it's impossible.
The interesting thing will be if it's there before release. Put it out on gnunet or freenet or something so you're untraceable, and there you go. I want to see someone do that, just because of the ridiculously ott "security".
I don't look down on people who read and enjoy the books. However, if you think it will somehow be better because you were up at midnight getting it as soon as it was released, you're an idiot.
Erm, if you don't want to know the plot, DON'T GO LOOKING FOR A LEAKED VERSION. They're not going to "ruin the plot for the rest" when they post the last chapter online (it will happen).
Will enterprise users really want support for hundreds of architectures? Enterprises tend to have lots of servers the same, and strict EOL policies. It's home hobbyists that will have 400 sparcs, mips and alphas from various ages. If the users demanded it it wouldn't be too hard to add support back in, but I don't think for this kind of market they need to support unusual hardware.
They don't fit, you're going into the person next to you's space, unless you're in the lucky position of having two seats for everyone on the bus (not normally the case in the morning rush hour).
Why? That will only inconvenience legitimate users. Any hacker smart enough to get into a secured system can easily get past any firewall you try.
Provide some protection against DOS attacks?
Better done on an application-by-application basis. You can use a separate device, but doing it in specialist fashion on each application server is probably going to be more effective.
The external internet facing interface on the perimiter firewall port forwards web and https to the apache-DMZ and smtp to the mail-DMZ. This firewall is configured such that none of the DMZ's can contact the other or the "internal" network and vice-versa
Sounds more like a router to me. Are the networks physically separate? If so, you don't need a firewall, just don't have anything route between them. If not, how are you sure the firewall can't be bypassed?
plus the traffic to and from each network is only allowed on their appropriate ports
This is the part I'm criticising. Why is that necessary? Presumably the only think listening on the apache server is apache, so it wouldn't matter if you allowed traffic to other ports because they'd be nothing listening. Ditto allowing non-25 traffic to the mail servers, it wouldn't matter because there's nothing else listening on them.
This firewall also performs flawless prioritisation, bandwidth limiting and spamd blacklisting.
All useful things, but the device doing them doesn't have to be a firewall.
However if I had set these machine up like the story, the apache machines would be running local firewall processes which would likely get MODIFIED by the successful attacker, who would then move on to exploting other machines or even just performing DoS, flooding, etc.
How would the apache server help them "explot" other machines? As for DoS, you're only any better if your firewall can handle a DoS better than the other machines. If so, why not spend the considerable cost getting beefier other machines?
Security is about layers. This guy thinks it's a good idea to remove the strongest layer, which he considers a crutch.
It is all too often a crutch. It may appear the strongest layer but it isn't, it's merely the outermost layer. People think it's security by itself, you don't need any more layers. Of course adding a firewall to a network won't make it any less secure, but often the effort spent on the firewall would be better placed elsewhere.
What does server B have that would let you compromise it? If it's not something necessary, why is it running? If it is something necessary, you can't firewall it off.
No, but if you don't need network access you should tell it to only listen on unix domain sockets and not public tcp. If you do need network access, you don't want to firewall it off.
1)I don't think anyone's dumb enough to open something just because. If they're opening something they're going to want it usable, so they would open it in the firewall as well.
2)Anyone smart enough to do that is easily smart enough to get past any firewall.
Why is their visibility a problem? If they are running services that you want accessible, they need to be visible. If you don't want people to access the services, turn them off, then the machines aren't vulnerable.
Slashdot Mirror
The hurting sales I can accept, but I don't buy the line about "spoiling it for everyone else". The only way you would find out the ending is if you were looking for it.
How? If you're going to do it by making all traffic pass through the firewall, you could do it more easily and securely by physically isolating the server. Though I still don't see how not being to access server B from server A is a risk when server B is publicly accessible.
What I meant is that if the rootkit's sophisticated enough to avoid detection by my non-firewall measures, it's likely to be sophisticated enough to avoid detection by the dedicated firewall.
I can't imagine a real enterprise adding 20 mac minis to 50 x86 desktops. There are policies and things, if you did switch it would be the whole lot, and it would be a long term thing.
The point is that html supports this handy thing called links. You have made good use of them, but the article submitter could have done so. If the average slashdotter is going to have to use google to find out what it is (and judging by the number of "what is it" posts, in this story they do) then the submitter should include a link to the relevant result.
We believe in free speech. Free speech doesn't mean anything unless it includes the right to say unpopular things. On the incitement of hatred, for the overall good of us.
Huh? USE=-static set, just emerge zlib, takes maybe 20 minutes on a slow system, and there you are. And it will be a faster version. The linux scheduler is good enough that if you run it at nice 19 the compile won't affect your use of the system.
No, they don't use "viral" open source. They're happy to take advantage of bsd-licensed code, like zlib, libpng, or the bsd tcp stack. And why not?
Python can't, at least without embedding the python interpreter in the dll.
What's more, you say that C can work with (at least as a library) every other language out there. So what's the problem with a small C-language interface that just calls the Python function and returns the result?
Any language supports calling C libraries from that language. You have to, because for many things the only library available is in C, and there are millions of C libraries. Not so many support calling that language libraries from C - why would they? A big part of their attractiveness is their extensive standard library.
For zlib it would be too slow. This is an incredibly low level library. It's used in networking, so it has to run on routers. It's used in png, so anything that displays graphics has to be able to run it. There's really no alternative to C/C++, it needs to be crossplatform, complieable, and run on embedded systems. Maybe OCaml since that's compilable, but even that might have too much overhead, plus not so many coders know it.
It can be done. I'm writing this on a slackware system that uses emerde. I can emerge or use gentoo binary packages for programs, and I can use slackware packages. The two fit together perfectly, the programs update the "database" of each packaging system from the other one. Although it would be harder with the more complex rpm and deb, I don't think it's impossible.
The interesting thing will be if it's there before release. Put it out on gnunet or freenet or something so you're untraceable, and there you go. I want to see someone do that, just because of the ridiculously ott "security".
I don't look down on people who read and enjoy the books. However, if you think it will somehow be better because you were up at midnight getting it as soon as it was released, you're an idiot.
Erm, if you don't want to know the plot, DON'T GO LOOKING FOR A LEAKED VERSION. They're not going to "ruin the plot for the rest" when they post the last chapter online (it will happen).
Why? How is it any worse to read if someone else has already read it?
Will enterprise users really want support for hundreds of architectures? Enterprises tend to have lots of servers the same, and strict EOL policies. It's home hobbyists that will have 400 sparcs, mips and alphas from various ages. If the users demanded it it wouldn't be too hard to add support back in, but I don't think for this kind of market they need to support unusual hardware.
They don't fit, you're going into the person next to you's space, unless you're in the lucky position of having two seats for everyone on the bus (not normally the case in the morning rush hour).
Exactly. They are, as the author says, a crutch. If your network can be hurt by that "background radiation" you've got deeper problems.
Why? That will only inconvenience legitimate users. Any hacker smart enough to get into a secured system can easily get past any firewall you try.
Provide some protection against DOS attacks?
Better done on an application-by-application basis. You can use a separate device, but doing it in specialist fashion on each application server is probably going to be more effective.
Can't use that on the bus. I realise americans may not understand what one of them is.
Sounds more like a router to me. Are the networks physically separate? If so, you don't need a firewall, just don't have anything route between them. If not, how are you sure the firewall can't be bypassed?
plus the traffic to and from each network is only allowed on their appropriate ports
This is the part I'm criticising. Why is that necessary? Presumably the only think listening on the apache server is apache, so it wouldn't matter if you allowed traffic to other ports because they'd be nothing listening. Ditto allowing non-25 traffic to the mail servers, it wouldn't matter because there's nothing else listening on them.
This firewall also performs flawless prioritisation, bandwidth limiting and spamd blacklisting.
All useful things, but the device doing them doesn't have to be a firewall.
However if I had set these machine up like the story, the apache machines would be running local firewall processes which would likely get MODIFIED by the successful attacker, who would then move on to exploting other machines or even just performing DoS, flooding, etc.
How would the apache server help them "explot" other machines? As for DoS, you're only any better if your firewall can handle a DoS better than the other machines. If so, why not spend the considerable cost getting beefier other machines?
Security is about layers. This guy thinks it's a good idea to remove the strongest layer, which he considers a crutch.
It is all too often a crutch. It may appear the strongest layer but it isn't, it's merely the outermost layer. People think it's security by itself, you don't need any more layers. Of course adding a firewall to a network won't make it any less secure, but often the effort spent on the firewall would be better placed elsewhere.
What does server B have that would let you compromise it? If it's not something necessary, why is it running? If it is something necessary, you can't firewall it off.
No, but if you don't need network access you should tell it to only listen on unix domain sockets and not public tcp. If you do need network access, you don't want to firewall it off.
2)Anyone smart enough to do that is easily smart enough to get past any firewall.
Why is their visibility a problem? If they are running services that you want accessible, they need to be visible. If you don't want people to access the services, turn them off, then the machines aren't vulnerable.