The Enemy Within: Firewalls and Backdoors

hrbrmstr writes "SecurityFocus is running an article on firewalls and backdoors on their InFocus site. They provide info on firewall types, backdoor classifications, some examples of real backdoors and tips on mitigating their use on your network." Some good topics explained for the beginner, and it's a nice refresher for the veteran admin as well.

Comments

Just remembered

[ATAMAH]

I loved the "Matrix reloaded" portrayal of a backdoor.

Re:Just remembered

[Anonymous Coward]

I was pretty sure they did it missionary style, but then again, I've only seen it the once.

All hail the pepper jack.

Re:Just remembered

[Anonymous Coward]

You know you're on slashdot when sex position posts get modded Informative.

Re:Just remembered

[SomeGuyFromCA]

Actually, the most common sexual style is ::drumroll:: doggie style.

That's where the man sits up and begs and the woman rolls over and goes to sleep.

Re:Just remembered

[Anonymous Coward]

nothing personal hear or anything, but how is "I liked a part of the matrix" insightful. Interesting maybe, but not insightful

Re:Just remembered

[bmwguy]

I liked it too. Now, whenever I hear about "backdoors," I will get that image in my head. NOO!

Re:Just remembered

[MrTangent]

It's really not that incorrect, given that the Matrix is a world built on metaphors. All the visual "consensual hallucinations" within the matrix are simply metaphors for coded actions. That is to say, the fight scenes are only visual representations of bits of code (code warfare?), along with everything else seen, felt, heard and experienced in the Matrix. The keymaker (believe was his name) was nothing more than a metaphor for an encryption specialist. I think if we approach the Matrix films from the vantage point of "All Is Metaphor" then the beauty of it becomes more readily apparent and acceptable; especially in the context of real life events. Nothing in the Matrix is as it seems, but is only contextual analogies of real life. It is binary, translated to a rich visual and aural consensual hallucination meant to enslave mankind and fool the mind (and it makes for more interesting cinematics than simply binary code everywhere). :)

Re:heh, 3Com

[Anonymous Coward]

So basicly you have FIREWALLED yourself from the REAL world. You now sit around, reading slashdot and writing in your /. journal.

Watch out - this guy is really serious.

Seriously a LOSER.

Bet you cant even hack your way out of a paper bag.

Re:heh, 3Com

[Anonymous Coward]

Either I'm having a really dumb day, or you missed a bit in your sentence there after the ()'s. What did you find out about the 3com?

Re:heh, 3Com

[ATAMAH]

Let me guess - you were treated for a misterious illness that makes you skip parts of sentences and skip over to the next thought ? :)

Good info

[rekkanoryo]

I had a basic idea of a lot of stuff here an some knowledge of some things, too. This was a nice crash-course.

Kinda makes me wonder, though, how often articles like this spawn ideas in the minds of the "wrong people," leading to attacks or attempts to attack. Anyone else ever wonder that?

Re:Good info

[fireman sam]

security through obscrurity does not work

Re:Good info

[Anonymous Coward]

I had a basic idea of a lot of stuff here an some knowledge of some things, too

It is good to have "some knowledge of some things". I'm glad the whole school thing worked out for you.

Re:Good info

[Anonymous Coward]

Whereas you have all knowledge of all things? I'm glad that deity thing worked out for you.

Re:Good info

[Anonymous Coward]

I agree, this kind of information will certainly make some people want to attack a particular security hole. However, as already stated, security through obscurity doesn't work, so who cares?

On another note, that kind of "Hey, a security hole! Let me try attacking it!" was exactly the key to what is today my carreer (no, a network security engineer, not a black hat you insensitive clod! ;-) 16 years ago. I got so "in" to cracking stuff that I was no longer interested in actually doing (juvenile) damage to a BBS or war dialing. I ended up asking for permission to do stuff, and next thing I knew I had a pretty cool job. I was making money doing what I had always done. There was no incentive to do damage, but there sure was incentive to find and prevent problems.

Ah, those were the good days. Now I'm a project manager, and although the pay is pretty good, there just isn't that satisfaction in doing my job anymore.

Re:Good info

[irc.goatse.cx troll]

Security through obscurity does work though, so long as its not the only layer.
An example would be lets say you're making your own home made cluster remote administrative tool for admining all of your servers from one console. What would be more secure:
A: Greeting the user upon connection with a description of the service, full protocol docs, source code, etc.
B: Sitting, waiting 5 seconds for the first command before dropping the connection. If client sends one wrong byte, instantly drop the connection and firewall their ip so that they cant get a single packet through.

Obscurity isnt security in itself, however it does make a nice addition to an already secure setup.

And if you think full disclosure means instant security, take a look at that opensource database thats had a serious bug in it for 8 years that was only found recently. I can't think of the name off hand, I believe it started with 'Inno'. Even though "thousands of eyes scoured the source code" it still didnt get noticed for eight years-- that is, noticed by anyone that went public with it.

Re:Good info

[irc.goatse.cx troll]

-replying to self because I left something out.-
I do agree that this kind of info should be made public, I'm just making a point that security through obscurity isn't universaly useless

Re:Good info

[jreilly]

Umm...innodb hasn't always been Open Source...the backdoor was discovered after the source was opened...

The rule

[Faust7]

Can your multiple-lines of defense truly protect your network from modern methods of intrusion?

Only if "modern" meant "known." Everything else is fair game.

Re:The rule

[lavalyn]

Only if "modern" meant "known."

Assuming you have a default ALLOW policy. I'd find it hard to attack an MSSQL server behind a firewall that autodrops all traffic to 1433/1434(udp). (Why I'd want an MSSQL server is another matter.)

It still doesn't stop attacks against kernel-level packet handling but it'll take down most unknown service-level attacks.

Re:The rule

[realdpk]

I'm going to assume that you allow access to 1433/1434 from at least *some* hosts.

So, you just have to hack those hosts, and then you're in.

Fireawlls are not the answer, really.. they mask problems. Firewalls should be the very last step in your security initiative.

Of course, I'll get replies to this about how this is just how it is done - well, too bad - it's not the best way to go and if you don't know it, you should. :)

Re:The rule

[Artifex]

Fireawlls are not the answer, really.. they mask problems. Firewalls should be the very last step in your security initiative.

Yes and no. If you rely solely on firewalls, yes, because firewalls just contain damage and prevent it spreading. You definitely still have to take care of the weak security on the affected machine(s). However, if you think of security as an ongoing effort (i.e. no "last step"), you'll see that monitoring your firewall may give you much quicker notification of abnormal activity.

Personally, I much prefer to be warned by port scans, etc., than to rely solely on hardening for protection from attacks. It's like having a fence around your house, with a gate in front, and having a burglar standing outside, rattling the front gate, yelling "hey, I'm about to try to break into your house!" He might get over the fence or through the gate, but you'd be awfully stupid, if you knew some burglers did that, not to at least have the wall and the gate.

Carrying the metaphor a little too far, of course, it's a heck of a lot easier to track the guy down and "remove the threat," if you know he's going to try something, and where he is, before he does tries it.

Re:The rule

[Anonymous Coward]

Personally, I much prefer to be warned by port scans, etc., than to rely solely on hardening for protection from attacks. It's like having a fence around your house, with a gate in front, and having a burglar standing outside, rattling the front gate, yelling "hey, I'm about to try to break into your house!" He might get over the fence or through the gate, but you'd be awfully stupid, if you knew some burglers did that, not to at least have the wall and the gate.

People scan for ports constantly. Do you really want to know about each and every scan? I get *WAY* too many scans to even care. Most companies don't care either.

Carrying the metaphor a little too far, of course, it's a heck of a lot easier to track the guy down and "remove the threat," if you know he's going to try something, and where he is, before he does tries it.

and what do you do if someone is spoofing the IP address? What if the person who is scanning you is a helpless victim of some ubercracker using their machine to conduct attacks?

Having a firewall is more like having the club on your car. Would-be car theives can walk by it all day long, look in the windows, kick the tires, etc., but it is enough of a deterrent that most theives would rather pick the car next to yours which is totally unguarded.

Re:The rule

[jschrod]

If you really have time to follow up port scans, you should get a life. Even at our small /29 net, we receive roughly 4000 scan attempts on a quiet day. 1000 of them seems to be connected to immediate probing of known vulnerabilities. (I don't know exactly because we don't take the time to look on them closely.) Almost all of them come from dial-up IP numbers of large ISPs.

I much prefer to find a balance between necessary security precautions (e.g., keeping automatically up to date with patches) and going on with our business - which after all pays the salaries of my staff. All our security would not help us if we spent too much effort there and I cannot pay the paycheck any more.

Re:The rule

[Telastyn]

Not exactly. Pretty much every method of intrusion is "known". I mean pretty much every modern [and likely 99% of 'new' attacks in the next 2 years] attack is of a known type. A buffer overflow is a buffer overflow is a buffer overflow, just different buffers.

If your multiple lines of defense are just string checking, yeah it's not going to be secure for new attacks. If the defense is against the type rather than the specific attack, you are much better off because the type is 'known' even if the attack isn't.

Re:The rule

[pascalb3]

Piggy-backing off of the last article, it is a matter of a well-rounded security policy. You need to know your network, systems, and requirements to truly have a good idea of what needs to be done where. This starts at the physical security level and covers everything, no matter how insignificant: segmenting user domains (so internal Bob has to go through an internal FW/IDS to access to reach internal Jane or internal server, either for normal operations or an attack); strong password enforcement; routinely wardialing your company for any rogue modems; implementing VLANs; DMZ; log servers; firewalls; IDSes; as well as many other measures.

Even if you have all this in place -- or want to put them in place -- you need to have an active and efficient system of gathering and analyzing the data. Once again, this requires the security and/or system admin to know their network in order to tune all of the systems to reduce the false pos/neg results. Depending how complex your network is, assigning compartementalized security personnel would be a good idea so that one person is responsible for one network/system area of the whole with a hierarchial system to the top security person looking at everything.

This model is rarely seen anywhere in the real world since (as usual) 99% of companies see outside threats as being the more serious of the two. This leaves one security person (or a dual role for a system admin) just securing external firewalls and DMZ systems while they should be focusing on 'can Joe from Receiving see/access the Accouting systems?' and other internally-related threats. Something to think about if you're in this situation.

layers

[smettler]

I wonder which layer model (iso, dod, other?) they took. Looks like iso/osi to me and if that's the case

>Packet filters [1]
> * Operates at Layer 3
> * Also known as Port-based firewalls
> * Each packet is compared to against a list of rules (source/destination address, source/destination port, protocol)

based on tcp/udp port numbers? that would be layer 4, right? Imho Layer 3 applies to ip-address only.

>Application-level gateways [2]
>
> * Operates at Layer 5
> * Application-specific
> * Example: Web (http) proxy

I thought the application layer is layer 7?

someone?

cheers
Sascha

Re:layers

[rekkanoryo]

You're right. OSI Layer 3 does not deal with port numbers. The Application Layer is the OSI model's Layer 7. Looks like someone forgot his/her coffee when writing the article, like I did reading it.

Re:layers

[Anonymous Coward]

tcp/ip network protocol stack traditionall has 5 layers... the make you learn the bullshit 7 layer one tho and assure us all that its going to take off....

Re:layers

[Anonymous Coward]

under tcp/ip stack there are 5 layers

port numbers are still layer 4 but application drops down to five

see.

Re:layers

[Talez]

The application layer is layer 7 but application layer and an application-level gateway are two seperate things.

Protocols such as HTTP and FTP usually start at the session layer (layer 5) which is what application-level gateways are working on. For you to manipulate sessions transparently you need to hijack the connection at the session layer otherwise you'd need special support for proxy servers.

That said, many applications usually include support for proxy servers anyway since transparent proxies are not particularly easy things to setup.

Eep!

[Faust7]

telnet some.insecure.host.org 1234

Crap, how'd they find m--I mean, that poor sucker.

Re:Eep!

[AndroidCat]

You mean some.insecure.host.org at 216.74.108.110? I hope that it's like example.com, and meant to be used like this. (Hmm, FTP server running there. :^)

Re:Eep!

[deadsaijinx*]

no, it's at 127.0.0.1 ... it's super easy to break in, I've done it before, and the poor sap didn't even realize it. muhahahaha, i am such a l33t h4x0r

Re:Eep!

[Mr2cents]

no, it's at 127.0.0.1 ... it's super easy to break in, I've done it before, and the poor sap didn't even realize it. muhahahaha, i am such a l33t h4x0r

Beware of this guy, man. I also hacked his computer and formatted his HD. He immediately retaliated by formatting my harddisk in return!

Re:Eep!

[Anonymous Coward]

I keep finding all these windows systems WIDE open at 169.254.0.0/16 it's ridiculous.

Stateful Packet Inspection recommended

[steveha]

The article is worth reading, but there was one comment that made me go "Huh?!?"

Stateful, multi-layer inspection firewalls
[...]
High level of cost, security and complexity

Pretty much all of Netgear's home routers have stateful packet inspection features. Some of them are quite inexpensive (how about US$80 for a model that even includes a print server!).

The great thing about stateful packet inspection is that you don't have to configure it. If you want to play some new game that does multiplayer play on the Internet through some wacky port, it will just work, and meanwhile if some random guy blasts packets at that port or any other they will bounce off. If you didn't ask for a packet, it gets turned away.

(If you ever serve as tech support for a friend or family member, be sure they buy a firewall/router with stateful packet inspection!)

Of course, that cuts both ways: any back-doors in your network will just work, also. Don't figure that just having a cool firewall/router with stateful packet inspection is a guarantee that you are secure. But it's a nice start, and it's what I recommend to anyone who has an always-on Internet connection.

steveha

Re:Stateful Packet Inspection recommended

[Anonymous Coward]

how about US$80 for a model that even includes a print server!

Rah-ha! Take that you lousy cracker!

Re:Stateful Packet Inspection recommended

[brett42]

I spent two years in a highschool cisco class, and in the 2 months before we started playing quake, I learned about network models. Basically, network operations can be divided into multiple layers, with each performing different functions. The layout of these devices seems to be based on one of these models, though I don't remember which. The stateful packet inspection you refer to would probably be part of the first device mentioned in the article, packet filters, which just operate on the network layer, not the other two.

Of course, somewhat intellegent packet filtering at the router beats the hell out of those "home firewall" programs that make pop ups every time you run a new program.

Re:Stateful Packet Inspection recommended

[AlCoHoLiC]

Allowing ALL ougoing and RELATED incoming traffic is hardly secure setup. Every fscking worm/backdoor is allowed to call home, replicate itself or even participate in DDOS network. I also doubt that netgear cares about actual packet payload (layers 4-7). I guess that they're using dynamic packet filter.

Re:Stateful Packet Inspection recommended

[steveha]

I spent two years in a highschool cisco class, and in the 2 months before we started playing quake, I learned about network models. Basically, network operations can be divided into multiple layers, with each performing different functions. The layout of these devices seems to be based on one of these models, though I don't remember which. The stateful packet inspection you refer to would probably be part of the first device mentioned in the article, packet filters, which just operate on the network layer, not the other two.

I'm sure you are right. I saw them use the word "stateful" and sort of overlooked that they were talking about looking at several levels of the protocol, which no doubt accounts for the "expensive" and "difficult" comments.

steveha

Re:Stateful Packet Inspection recommended

[pair-a-noyd]

"Every fscking worm/backdoor is allowed to call home"

Simple. Don't use Windows.. That's a Windows problem.
I quit using Windows in August of 2002 and have not had a single worm, virus, trojan, backdoor, hack, sneeze, fart, or burp since..

Re:Stateful Packet Inspection recommended

[vrt3]

I think you missed

• Layer 3 filtering
• Layer 4 validation
• Layer 5 inspection

I'm pretty sure the Netgear routers you talk about only handle layer 3, like linux' netfilter/iptables does. The expensive part is handling layers 4 and 5.

Re:Stateful Packet Inspection recommended

[baka_boy]

This is a Windows problem only as long as Windows rules to corporate and desktop market; if there were, say, 30% market share of Linux machines out there to worry about, there would be much closer to 30% of a share of virii, worms, backdoors, etc. for that market. So long as Linux, FreeBSD, et. al. are fairly unusual systems to find inside the firewall, they will be (somewhat) less commonly-targeted systems for network attacks.

It's an unpleasant side-effect of the "security does not come through obscurity" argument: since truly strong security is more or less impossible for fully-networked commodity workstations, the more popular an operating system or protocol server implementation is, the more likely it is to be hacked, cracked, and just generally abused.

I've seen this even within the microcosm of Linux servers; the one time I tried to put a relatively well-firewalled (but not, unfortunately, religiously-patched) Red Hat server out on the net, it was hit with a rootkit within a week. Once that was replaced with an OpenBSD system ru awanning the same services, (albiet with a somewhat more recent version of OpenSSH) I was free to check back no more than once every few days to make sure that everything was in order.

(Note: before anyone flames me for my sloppy sysadmin practices, please be aware of two facts: one, at the time, I was already working 40+ hours a week as a lowly coder, and was solely responsible for the design, development, deployment, and maintenance of the dynamic product support website whose server got cracked, and two, I've more than learned my lesson, and now know how to firewall, audit, and harden a system well enough to be back to the point of worrying about application, rather than network or OS-level, security. And, I no longer put anything running Red Hat anywhere near an open port and public IP address, unless I'm ready to wipe and reinstall at a moment's notice.)

Re:Stateful Packet Inspection recommended

[owenb]

there would be much closer to 30% of a share of virii

You mean 'viruses'. Look here

Re:Stateful Packet Inspection recommended

[Hobbex]

This is a ridiculous argument. Any worm worth two cents is just going to communicate out using port 80, and if the author is really clever it will do it by opening http pages using Internet Explorer so the traffic doesn't look different, and not even local application level firewalls or authenticated proxies can stop it.

Blocking outgoing traffic does nothing for security, and tons to block legitimate applications and the true power of the Internet (as opposed to the Web).

Re:Stateful Packet Inspection recommended

[nmg196]

The great thing about stateful packet inspection is that you don't have to configure it. If you want to play some new game that does multiplayer play on the Internet through some wacky port, it will just work

You're very confused. This behaviour is absolutely nothing to do with stateful packet inspection. *ALL* routers will behave like this if you enable routing of all outbound traffic - even really cheap and simple NAT firewalls (not really even a firewall). Allowing all outbound traffic means that any trojans you get though e-mail/floppy/open HTTP port etc etc mean that the trojans can phone home and start sending out personal information or attacking other systems. Hardly secure...

The particular Netgear firewall you mentionned (FM114P/FR114P) is one I've used at home. It's probably the least stable and most annoying piece of hardware I've ever used. If you read the forums on dslreports.com you'll see that most users are plagued with problems ranging from random lock ups (mine needs rebooting every couple of days) to it's inability to handle long URLs (causes lock ups) and it's susceptability to the common ping of death attack, which means anyone on the internet can lock up your router with a simple ping command. I've had most of these problems myself, and if you combine them with the poor performance (especially if WEP is enabled) and power supply problems, you end up with a pretty poor product where the only redeeming factor is it's price. I think Netgear have resolved a few of these issues with the latest firmware, but they should have got it to this stage BEFORE releasing it, not a year or two afterwards! Why it takes 12 minutes to copy a 100mb file across the network - when both machines are in line of sight with the router and have full signal strength is beyond me! That's only 135k/sec which is almost exactly 1Mbit - and it's supposed to be an 11Mbit network - not exactly fast!

Nick...

Re:Stateful Packet Inspection recommended

[steveha]

You're very confused. This behaviour is absolutely nothing to do with stateful packet inspection. *ALL* routers will behave like this if you enable routing of all outbound traffic

The last time I looked at a cheap firewall/router that did not have stateful packet inspection, I seem to recall that it had most ports closed. That if you wanted to run some wacky program on some wacky port (your new game, for instance) that you would have to fire up the web browser, go to the admin form, and open the port. And then that port would be open. All the time.

So, I'm confused. Am I wrong about how the non-stateful firewall works?

Allowing all outbound traffic means that any trojans you get though e-mail/floppy/open HTTP port etc etc mean that the trojans can phone home

Dude, check my comment about "Of course, that cuts both ways". I know they can phone home. (But I think most trojans phone home through the HTTP port, so most firewalls will let them do it.)

The particular Netgear firewall you mentionned (FM114P/FR114P) is [...] probably the least stable and most annoying piece of hardware I've ever used.

I'm sorry to hear that. I've had good luck with my Netgear. In fact I haven't had any trouble with any Netgear stuff I have bought (and I can't say the same about Linksys).

I haven't tested that particular model, however.

steveha

Re:Stateful Packet Inspection recommended

[nmg196]

OK, I probably didn't explain myself very well: A simple NAT firewall, such as that built into Windows XP and quite a few routers, will allow all outbound traffic by default. From the outside however, all ports that don't have an outbound connection will appear to be closed (as opposed to open, or non existant/stealth). "Closed" meaning that the computer actively sent back a packet saying that it doesn't accept connections on that port. Meanwhile, you can happily run games/P2P/ICQ etc without noticing that you're even behind a firewall - without SPI.

SPI works on another level - rather than forwarding connections, it actually analyses the raw packets and decides whether or not to forward them. It can even be set to be completely unresponsive on the ports that are not in use meaning that if no ports are open, there is no way to tell that there is a computer at that IP address. It can also do some clever stuff, like inspect the contents of packets and conditionally allow the traffic or perhaps open another port based on it's contents.

All I was trying to point out was that you don't need SPI to get the ease of use you were talking about.

Certainly some routers may require you to manually open outbound ports before something will work, but this isn't because they are (or aren't) SPI firewalls - it's more to do with the default configuration. Netgears allow all outbound traffic by default, but they could easily have been shipped to only allow HTTP, POP3 and IMAP4 by default, and block everything else.

The BEST feature of SPI firewalls is that *some* of them can be transparent. Meaning that if your firewall is protecting 30 machines, those machines can keep their real internet IP addresses and you just insert the firewall in the middle - no network reconfiguration required. eg, the Sonicwall Pro 230 does this. As far as I know, no NAT type firewalls can do this, meaning your internal servers all need to be moved to a private IP (eg 192.168.*.*) in order to work behind the firewall. If it breaks and needs to be removed, you need to either quickly replace it, or remove it and reconfire the IPs on every single machine behind the firewall.

Re:Stateful Packet Inspection recommended

[Stephen Samuel]

I think that you're still talking about a simple port filter. A stateful multi-layer protection would provide that sort of protection, but it would also want to know about your game. It might even know the protocol well enough to recognize a Packet Of Death and know to not allow it through the firewall.

It could also be configured to only allow game playing by certain characters, at certain times of the day (even if it does use port 80) and/or require you to provide extra authentication to go out.

For SSH, it might even demand your private akeys (ugh!) and inspect the traffic looking for BPN signs.

note: Most firewalls -- even the simplest ones recognize the FTP protocol and will allow the related data connections thru. Although this may technically make them multi-layer, I consider it a special case because FTP is so old and so widespread that it's almost stupid to not know about it.

Re:Stateful Packet Inspection recommended

[Anonymous Coward]

I never use Windows, but I still fart...should I see a doctor?

Re:Stateful Packet Inspection recommended

[wazlaf]

Don't figure that just having a cool firewall/router with stateful packet inspection is a guarantee that you are secure

ACK. Some guy recently broke into my computer and installed a root kit and other messy stuff. I noticed it because "ls" suddenly didn't know the -h parameter anymore. I think he managed to break in because my version of SSH was very outdated. A firewall was of no help here...

Re:Stateful Packet Inspection recommended

[antoy]

Simple. Don't use Windows.. That's a Windows problem.

It's actually a problem with most modern operating systems, including Linux. Any executable file that is run on Linux or Windows by default inherits all permissions of the user who runs it. So if your user account allows any kind of connection, the backdoor is free to use this ability.
The problem with Windows is that its sometimes too easy to get yourself a backdoor, and even in Windows XP the 'firewall' is just a packet-filter which will do nothing against trojans. I personally use Kerio Firewall, which tells me when a program tries to call home. Programs like Soundforge and Windows Media Player were often caught in the act (although they probably mean well :) Another easy trick is using the runas command to run untrusted programs in a sandbox account.

Re:Stateful Packet Inspection recommended

[MeNeXT]

I have moderator points and I'm about to post go figure...

This has nothing to do with thechnology but more to do with attitude, policy and productivity.

You see in most trades/proffessions you need to learn how a tool works before you are eveluated on the tool. After that you need to apply the tool to the trade, which means you need to understand the workings of the trade. This takes years.

Now, with computers, we have business that are trying to fit the trade to their tools. When that does not work and they encounter problems, they hire someone who knows one tool. They then try to force the tool into the business.

This will never work! You cannot make a general tool to fit every need and at the same time make this tool easy to use. A good example that I can bring up is for MS Word users. Placing graphics in word does not make word a publishing software. All it has done is waste your time and the other person who is to open the document. Word is made for typing letters when we use it for other things it becomes complex. IT DOES A POOR JOB and it costs you more time and money than buiying the right tool or asking someone who is in the trade.

Now before buying any software you need to identify what your needs are. Do you need to access files from home? Better yet why are you taking work home? How manyhours do you propose to work? If you wish to spend more time with your familly then mabye you should look at sleeping less because sitting in front of your computer is NOT familly time. In most cases this an ego issue (Look I can PISS farther than you!) an not a technologie issue.

If Linux can only STOP trying to be Windows then the virus issue will stay with Windows. We have seen on the server side that Linux has not followed in the Windows steps.

One last question why do you first start talking about the desktop and then give a server example?

Re:Stateful Packet Inspection recommended

[jafiwam]

Blocking outgoing traffic helps prevent the "meat" layer from being a problem, where users do stuff that cause problems on the network or with their computers.

For example, routing MS Gaming Zone to 127.0.0.1 via internal DNS did wonders for productivity around here. The same is true for any of the other 100% timewaster sites, Gator, porn, Yahoo, etc.

Sure a few people will figure it out, but those are on my staff. :)

Re:Stateful Packet Inspection recommended

[Garfunkel]

This is way late I know. But the argument of "Blocking outgoing traffic does nothing for security" is just wrong. Think SQL Slammer. If people had been blocking outbound udp1434, it never would have spread.

Re:heh, 3Com

[Anonymous Coward]

I remember the time when we found out that the 3Com switch / router / whatever (i can't remember so clearly now, it's been such a traumatic shock that i am still trying to forget and having mild success), and we were basically like "WHAT?!?!" and then all passed out.


I remember this time I was all drunk and busy trolling slashdot and I got to this article that was related to what I do for a living, only it was related in the most remedial of fashions and I was like "right on, I can troll this motherfucker like it ain't nobody's business, fo shizzle mah nizzle, and I may even get mod points cuz of the bullshit I'm about to spew."

Anyway, I was reading this mofo and I came across some whack job herion addict post that said some stupid shit and I read it and reread it and reread it, and was like "well, I'd troll this sumbith, but the wanker can't even write coherently". So I read it again and was basically like "WHAT?!?!" and then I was all passed out.

I like

[pair-a-noyd]

Smoothwall GPL 2.0 Beta 4 (mallard)
http://smoothwall.org/beta/

I put three nics in a Pentium 90 that I found on a trash heap. One nic goes to my RR cable modem, one nic goes to my switch and one nic is for my son's Playstation 2.
I can control every aspect of the firewall from any pc on the green nic. The firewall pc doesn't even have a keyboard or monitor.

I can VPN through it with ease and I have port forwarding from an oddball port number to port 21 for a private FTP so that RR won't find it.

It's really easy to use and so far I've had no problems.
Of course ALL the machine inside of it are Linux boxes and all of them are using iptables (w/shorewall) so everything is really secure..

For a super easy, very cheap and very fast firewall try floppyfirewall at http://zelow.no/floppyfw

No worries here...

Re:I like

[pair-a-noyd]

Um, well, internel security is not the issue. I'm just a cheap bastard. Hence the PC from the trash pile.
I drive around and rescue them, clean them up real nice, convert them to Linux based firewalls and resell them for $$$....

Now for the people that I sell them to, well headless *IS* a good deal for them, they need it that way..

Re:I like

[bloosqr]

Have you checked the power draw on the machine? Admittedly its a low end machine but I would guess that the power draw is significantly more than a generic ~$50 firewall/switch/router to the point where the ~$50 switch would pay for itself w/in a year or two..

-bloo

Re:I like

[Osty]

I put three nics in a Pentium 90 that I found on a trash heap. One nic goes to my RR cable modem, one nic goes to my switch and one nic is for my son's Playstation 2.

What was your reasoning behind adding a NIC specifically for the PS2? It should work fine just connecting to your switch, and assuming you have DHCP running for your internal network it won't even require any setup for the PS2. Plus, you can get an XBox as well and plug that into the switch, and have both running at the same time.

I'm sure you had a reason for that layout, I just can't figure out what it could be. Enlighten me?

Re:I like

[Anonymous Coward]

So he wouldn't have to buy a switch.

Re:I like

[pair-a-noyd]

Of course the power draw is more.
But the firewall is MUCH better.

Besides, you can add one or more DMZ nics in a PC.
And if you find a serious problem with your firewall, you just fix it. You can even totally change the software out and get very, very precise tunning of your iptables. I think they call it granular control..

No can do with a $50 bestbuy firewall/router... A $50 router is kind of like a having a Chihuahua guarding your home.

Re:I like

[fatwreckfan]

The idea of smoothwall is really cool. Is there software like that that I could install on a Redhat 9 machine? I have a system which I want to use as both a workstation and my firewall. I really like the remote administration functions of smoothwall, so I'd like to use that on the Redhat box. I'm currently using Monmotha's IPTables script.

Re:I like

[pair-a-noyd]

Several of the games did not like the firewall. There was *some* connectivity but not total cooperation between the PS2 and the firewall.

Several of the games want huge chunks of ports opened up. Uh uh. Not gonna do that. So I added the third nic as a DMZ (smoothwall calls it "Orange Zone") so that the PS2 has unhindered access to the web.

There are three nics,
red=nic to modem (dhcp)
orange= nic to PS2 - 192.168.2.1
green=nic to my lan - 192.168.1.1

The red zone is the nic that goes to the cable modem, it gets it's IP from RR's DHCP.

The orange zone nic is hard coded to 192.168.2.1 (by me) and the PS2 is 192.168.2.2 There are no port restrictions on it, it's raw and naked on the net, as it wants to be..
Since it's a PS2 it doesn't matter.

Smoothwall provides DHCP for the green zone so whatever I plug in to it works. Nice. People bring me PC's all the time to work on.

Another nice thing smoothwall does is take care of dynamic DNS for me, I have a freebee domain from dyndns.org so I can FTP to a private box on my lan from remote sites (while working) and I have accounts setup for my friends so they can ftp in too.

I hard coded one of my boxes to a specific IP then port forward from port XXXX to port 21 at my internal IP of 192.168.1.205. Only my friends and I know it's there and can access it. Very handy.

Veyr often I get somewhere and remember that I forgot something important! Bada bing! I can connect up to the house and get it... Smoothwall is VERY handy for my needs. I have no complaints about it...

Re:I like

[Artifex]

So he wouldn't have to buy a switch.

Except he says he has a switch, already:

One nic goes to my RR cable modem, one nic goes to my switch and one nic is for my son's Playstation 2.

He's assigning IP via DHCP either way, probably, and the switch would be easier.

There's only three possible advantages I can see to this setup.

• if he has so much traffic between those networked computers and the gateway he built that he's worried about saturating the segment between the switch and the gateway, or saturating the switch. Saturation shouldn't happen between the switch and the gateway, however, even if he's got a T1 or a 3MBps SDSL line, so unless he's saturating the switch itself with constant transfers between networked computers, it should be a non-issue.
• He might be worried about someone hacking into his son's PS/2 and then scouting around inside the network, but he doesn't have to have them on separate NICs to give them separate private IP space; he could always assign IPs by MACs, with one block for his machines and another block for his son. Or just assign them out "permanently." Or some other variation (DHCP is best in case he has guests who want to just plug in, or a laptop he takes to work).
• His son's PS/2 may be too far from the switch, but close to the gateway. This is probably the case.

So I'm also really curious as to why he chose this arrangement... if it's not the third reason, I hope he shares his reason with us, because undoubtedly I could learn from it.

Re:I like

[pyros]

But he already said one of the three NICs goes to a switch, and the poster you replied to included that in his quote of the original post.

Re:I like

[Artifex]

Several of the games want huge chunks of ports opened up. Uh uh. Not gonna do that. So I added the third nic as a DMZ (smoothwall calls it "Orange Zone") so that the PS2 has unhindered access to the web.

There are three nics,
red=nic to modem (dhcp)
orange= nic to PS2 - 192.168.2.1
green=nic to my lan - 192.168.1.1

Okay, I'm still a little confused. (Read my suppositions about your reason here, if you like)

Can you not assign more than one block to a NIC? Assigning them as two discrete /24s instead of one /23, of course. Or did you just want to physically isolate your DMZ as well?

Maybe you just wanted to play with 3 NICs in one box? You can admit it, I'd understand! I'd find that to be fun, too.

I've always thought it more technically freaky to do it all with one NIC in the gateway, and have the switch in the middle of the "star," though. Doing it that way means you can build smaller, even cheaper and lower-powered boxes if you need to. It works fine for PPPOE, even with Microsoft's ICS, but won't work for you, of course, because you can't let RR see your boxes or try to assign them IPs directly.

Re:I like

[zcat_NZ]

I hard coded one of my boxes to a specific IP then port forward from port XXXX to port 21 at my internal IP of 192.168.1.205. Only my friends and I know it's there and can access it. Very handy.


Nice, but I strongly suggest you use SSH instead, particularly since you're on a cable connection.

You can download a windows client called putty. It's a small, standalone .exe so you can easily grab it when you need it, and drop it in the trash when you're finished.

Re:I like

[pair-a-noyd]

"So I'm also really curious as to why he chose this arrangement... if it's not the third reason, I hope he shares his reason with us, because undoubtedly I could learn from it."

The PS2 did not like being behind a firewall. The game people say to open up huge blocks of ports to allow unsolicited incoming traffic. I don't like that concept.

If I open up 1000 ports (ports 6,000 to 7,000) plus a handful of other ports, and the PS2 is on the same zone as my other machines, well you get the picture.

I *THINK* that what was happening was that the PS2 would send data out through certain ports and when the other players would respond on those same ports, all was well. But I think the PS2 was LISTENING on other ports for incoming but unsolicited traffic. That traffic came in and hit the firewall, IP tables saw it as unsolicited and stopped it.

I could rewrite the IPtables if I were smart enough but I'm rather new to Linux, I've been a Linux user less than a year.
The EASY thing to do was to add a third nic that is just naked. It's unfiltered so all traffic that it needs gets through. So far it's worked well.

I *DID* try opening a few holes in the firewall at first when he was plugged into the switch with the rest of the house but I just did not like that option. I ran a seperate wire from his PS2 to the third nic.

His block of 192.168.2.xxx can NOT communicate with my block of 192.168.1.xxx nor can mine see his unless I open a pinhole in the orange, which would be pointless...

I decided to use DHCP on my side and the 192.168.1.xxx scheme since it is the most common one in use, making it extremely handy when other people bring other pc's and devices over for repair or fun.

On my son's side, the 192.168.2.xxx side I hardcoded the IP's because there is no DHCP served to the orange zone.. (Smoothwall people call the DMZ the orange zone)

Re:I like

[Osty]

I've never used Smoothwall, instead doing all of that by hand (setting up a firewall, DHCP; haven't bothered with dyndns though, since I used to have static IPs and now that I don't I haven't found a need to connect to my home PCs yet). The way I would've setup your topology would have been to set a given IP to the PS2's mac rather than just getting a random IP, and then setup appropriate firewall rules for that IP. The rest of the internal network would have its own separate rules.

Then again, I didn't want to add more NICs than was reasonably necessary (as another poster pointed out, you could've done all of this with a single NIC, but two NICs is the sweet spot IMHO). Maybe Smoothwall makes it more difficult to do this (can't assign specific IPs by MAC, perhaps? or can't assign specific rules to a given IP?) and so the third NIC route was the easiest method, or maybe you just wanted to play around. I don't know. Whatever works.

And just for kicks, my own setup looks something like this:

• Cable modem goes into a switch.
• My main linux box connects to the switch and does firewalling (custom iptables script) and NAT (custom iptables script) among other stuff (DHCP with IPs assigned by MAC and no dynamic IPs for unrecognized MACs, fetchmail and internal exim server with spamassassin through procmail, local cvs, ssh and sftp, etc).
• The second NIC in the linux box connects to another switch for my internal wired/wireless network.
• I have another linux box and my main XP desktop on the wired portion of the internal network, and my laptop on the wireless portion.
• And finally, the reason for the initial switch between the cable modem and the linux box is for my XBox.

Like you, I didn't want to have to putz around with opening ports for a gaming console, but I took a slightly different approach. I pay Comcast another couple $ per month for a second dynamic IP, and have the XBox directly online (no NAT or firewall to get in the way).

Re:I like

[pair-a-noyd]

Two confessions are in order.
1. I'm lazy. I have plenty of old nics laying around too. I'll get more elaborate with it another day.
Besides, I don't feel overly compelled to put much effort into it, he's moving off to college this fall.
This simple fix works. In two months he'll be moving out (Hooray!! Shhhh!! I didn't say that!!)

2. My son just got his Linksys adapter and was bugging me. This was the most easy and the fastest way to shut him up..

There! Now I feel better that the truth is out...

Re:I like

[Artifex]

I could rewrite the IPtables if I were smart enough but I'm rather new to Linux, I've been a Linux user less than a year.
The EASY thing to do was to add a third nic that is just naked. It's unfiltered so all traffic that it needs gets through. So far it's worked well.

Good reason. Easy is always good.
Someday, you might try to route the unfiltered block to the same NIC as the filtered block, just to see that it can be done, but no need to break what works, certainly.

The cool part about routing both that way is, if you or your friends want an unfiltered port temporarily, you just manually assign the box in question one of the IPs from he unfiltered block your son is using - you don't have to run another cable, or mess with anything else. Of course, maybe your friend likes to hog your bandwidth with p2p, in which case telling them it's all filtered is just fine :)

Anyway, I'm just glad you didn't hit me with "it's bad form to run a DMZ block and a filtered block on the same interface!" I'm sure some people think that's true, and there are cases when it's risky, but I just think about all those little Cisco routers sitting on T1s (or even higher) that have just one ether port off them and multiple assigned blocks, or one assigned block and also DHCP set up with private IP space, so I know that in practice a lot of DMZs aren't physically isolated - it can't be all that scary. :)

Re:I like

[pair-a-noyd]

That's an interesting setup too. I may play with something like that myself.
I also want to play with chained firewalls, that is one physical firewall going into
another one then into my lan. Like the mega-paranoid version..
Just for fun..

Re:I like

[Artifex]

There! Now I feel better that the truth is out...

Well, I have a confession to make, then, also, just so you don't feel bad:

Remember what I said about the PPPOE and ICS and a star config with one NIC on the gateway, and all that?

I actually ran that for a while when I was living with my parents, before moving out. It was dog-slow when they'd be on their box though, sometimes, because ICS isn't exactly very efficient, and bouncing it in and out across the same segment didn't help. Plus, they couldn't turn off their box, or I'd be screwed. Not to mention that I had to get a third-party PPPOE adapter to get it working, because the stupid spyware-laden CD that the ISP wanted us to use wouldn't work with ICS anyway. I moved out (got a promotion, moved out of state) before I put in a real router, but I bought a router and another switch before even getting DSL at my new place. Then when I moved back in (got laid off) I gave them the router and changed the layout of the network.

I wrote all that in case anyone out there is thinking of doing something similar. It's doable, but you're much better off either making a gateway or buying a cheap one (which also uses less power, is silent, isn't as likely to have parts fail, and has firmware pre-loaded) unless you're absolutely without funds. Did I mention that ZoneAlarm wouldn't work with ICS back then, either? :)

Re:I like

[Osty]

One problem: Putty will put keys in the registry (HKCU\Software\SimonTatham\Putty\SshHostKeys). You can easily delete that if you know that it's there. You could also hack the source code to put the keys somewhere else, or not store the keys at all (I've hacked the source code to do alpha blending, and while it wasn't the cleanest code base ever, it was understandable after a while). Anyway, my point is that if you're truly paranoid you'll have to do more than just delete the bin when you're done.

Also, you'll need putty's sftp client if you want to do it right. That's another exe you need to download. And don't forget to enable sftp on your server as well.

Re:I like

[Spacelord]

One problem: Putty will put keys in the registry

First of all, I don't see the problem about putting the *public* key of an ssh server in the registry ... it is called a "public" key for a reason.

Secondly, you can easily clean up everything putty has put in the registry by using the -cleanup switch. (e.g. putty -cleanup)

Re:I like

[Osty]

First of all, I don't see the problem about putting the *public* key of an ssh server in the registry ... it is called a "public" key for a reason.

Sure it's a public key, but do you really want people to know what hosts you've been ssh'ing to if you're doing this from someone else's machine or (worse!) a public machine? As well, if it's someone else's machine (my assumption is that's what you were talking about, else there'd be no reason to remove putty in the first place), be considerate and don't leave random crap in their registry.

Secondly, you can easily clean up everything putty has put in the registry by using the -cleanup switch. (e.g. putty -cleanup)

That I didn't know. I guess it's true that you learn something new every day. And I've been using putty for 3+ years!

Re:I like

[zcat_NZ]

Also, you'll need putty's sftp client if you want to do it right. That's another exe you need to download. And don't forget to enable sftp on your server as well.

I use scp for copying files. Usually between *nix boxes, but there's pscp (command line) and WinSCP (GUI) if you're on a windows box.

Does sftp do anything winSCP can't?

Oh, and if you're somewhere where you can't install software for whatever reason, there's a java SSH client too. This needs to be hosted from the same IP you're connecting to because of java's security model, which might be a problem for a cable-modem user.

Re:I like

[Osty]

Does sftp do anything winSCP can't?

I don't know. What I do know is that I like sftp because it's the familiar commandline ftp interface, yet more secure. I like things easy, so given the choice between learning how to properly use scp and using sftp which I already know, I choose the latter.

Re:I like

[LiquidShaneo]

Why did you go with Smoothwall over ClarkConnect? Both seem to be geared toward the same goal. I've been toying with doing this but haven't been able to decide which one to try. What are your thoughts?

Shane

Re:I like

[pair-a-noyd]

Honestly, because I discovered Smoothwall first.
I will end up trying out Clarkconnect sometime in the future, I evaluate lots of stuff because I get requests from people that have different needs.
I don't believe that there is ONE package that will suit the needs of EVERYONE. That "one size fits all" theory just never works out in actual practice...

What I would really like to find is a GPL firewall package that will also retrieve email, filter it for virus, then serve to the lan. I have M$ customers that could use something like that.

I suppose if it could strip HTML code from email and any attachment that's not a REAL jpeg, that that would catch a HUGE amount of it..

Re:I like

[pair-a-noyd]

Oh yes, and sadly, as a follow up,
ClarkConnect includes RAV antivirus. I just read that on the http://www.clarkconnect.org website.
RAV was recently purchased by M$. So much for security.
I won't use or recomend any products based on M$ and most certainly won't use and products produced or owned by M$..

Re:I like

[LiquidShaneo]

Dumb question time... I'm in the process of working on networking my PC's up at home (1 WinXP box, 1 Win 98 box, 1 Win2k laptop, and 1 Debian box). Would you go w/ a router (Linksys or similar) or use an old PC w/ SmoothWall? I'd like to also do printer sharing as well. Thoughts? Shane

Re:I like

[itwerx]

The reason for physical separation is that if someone breaks into a machine on the DMZ without physical separation you have no further protection - they can just add an IP from your private block and do what they want...
With physical separation (and a properly configured DMZ) they have a whole 'nother layer of firewalling to break through before they get to the good stuff.

Just my $1.50CND

Re:I like

[pair-a-noyd]

If you have an old pc to spare, go smoothwall. If you decide you don't like it, change it. There are a LOT of Linux based firewall packages out there for FREE...
Smoothwall (as most Nix FW paks) will run on obsolete hardware quite well. Mine is running on a Pentium 90mhz like a charm. There's a 500meg hard drive in there, it only needs 100megs but more is better because I setup a 300meg cache.

It also has the ability to use transparent anonymous proxy too... Another neat and handy feature...

Also, you could take an old pc and load a stripped down version of Linux on it and run CUPS http://www.cups.org/ on it. Then set all your PC's to print to the CUPS server via your lan. Hang as many printers on it as you like.

As a matter of fact, you could even share your printers with your friends. My neighbor can print to my laserjet with IPP. We both use Linux, CUPS and cable modems. Very easy to share my printer that way..
I don't keep the port open normally so he calls me when he wants to print and I open the port, he prints, I close the port back down..

Re:I like

[Anonymous Coward]

You run Windows XP and you're worried that an application stores the IP addresses and SSH PKs of machines you've been SSHing to in your registry? Um, could you please fuck off?

shit!

[lingqi]

ack; so much trauma i can't even finish a train of thought these days.

look what certain backdoors can do to you.

Egad ... VPN, just what our company uses. Hmm.

[zptdooda]

"When provided as a legitimate remote access tool for employees and business partners, VPNs can increase productivity, save time and reduce costs. When they are used to exploit gaps in the security architecture, they can have just the opposite effect."

Okay now I'm just a touch more concerned. I just signed off my work VPN connection half an hour ago, then read the linked article.

Perhaps I should direct someone on our company's network team to this article, just to be safe.

Re:Egad ... VPN, just what our company uses. Hmm.

[Anonymous Coward]

Perhaps I should direct someone on our company's network team to this article, just to be safe.

While you're at it, find an article where a hammer was used to hurt someone and forward it to your home builder. He'll appreciate it just as much!! Or maybe forward some tax fraud article to your accountants!! Or some Enron article to your omsbudsman!!!

how come...

[deadsaijinx*]

articles about network security always remind me of a poorly written tech based porno?

SecurityFocus says no MacOS EVER exploited once!

[Anonymous Coward]

Firewalls have NEVER been required to prevent remote exploitation on a Mac.

I find it both sad and amusing that people try to publish studies about this topic without first addressing the fact that there are more secure platforms for webserving.

It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.

The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on ample historical evidence.

In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely. Scan it yourself.

For years, except, for the last week, the army has always used MacOS and has never had a breakin on a Mac. Unlike their other MS defacements.

http://uptime.netcraft.com/up/graph?site=www.arm y. mil

That is why the US Army gave up on MS IIS and got a Mac for a web server.

I am not talking about FreeBSD derived MacOS X (which already had a more than a 30 explo its and potential exploits in BugTraq) I am talking about current Mac OS 9.x and earlier which are highly sophisticated abstract-OS models.

Why is is hack proof? These reasons :

1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for procces to process communication that is heavily typed and "pipe-less"

2> No Root user. All mac developers know their code is always running at root. Not hing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.

3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.

4> Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on Macs are not easily settable by users, expecially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.

5> Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by designof creating an executable file. The file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.

4> Stack return address positioned in s afer location than some intel OSes. Buffer exploits take advantage of loser programmers lack of string leng

Re:SecurityFocus says no MacOS EVER exploited once

[pair-a-noyd]

"It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet."

That's because there is a grand total of 1 (ONE) MacOS based webserver(s) on the internet.

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

A MacOS (NOT slow Mac OSX) can respond to (completely perform) over 25,000 individual unrelated actual SCSI block IOs per second PER connector on fibre channel cards (Astera Technologies (JNI), ATTO (Q Logic), and soon LSI.

thats per 2gigabit connector.

Can OS X, even latest OS X 10.2.6 match that speed? NO WAY!!! Not even its all-rewritten scsi code.

Why? Because unix is not a real time OS.

Apple can open files WITH INTERRUPTS DISABLED.

Apple can issue scsi IO requests and have them complete WITH INTERRUPTS DISABLED (Yes even PCI ISR)

Some Unixes allow pool-mode servicing too, but apple excels at REAL TIME os programming, and can swap between low level processes at ungodlike speed. (no kernel boundary issues).

Mac OS is slow and unusable. Not the classic mac.

The classic mac can even have virtual memory DISABLED allowing saving batteries by having drives get to spin down on laptops.... crappy OSX cannot have its vm disabled and eats up batteries.

The classic mac OS (still sold 9.2.2) can also pu t a machine into DEEP SLEEP and even have the motherboard and pci slots get ALL power cut (not merley low clock cycles, then wakeup pci cards from a deep sleep to save electricity. Even on DESKTOP g4s.

Can crappy OSX, even latest osx 10.2.6? No!!! It can not cut power to non-ATI-brand pci cards.

Mac OS is fast and capable of astounding feats of programming. Especially its SIMD on a dual g4.

you are a fool. Rad and learn a little. MacOS is awesome, thats why 85% of all google searches are from MacOS browsers and not OSX browsers!

e

remember

[djupedal]

Every ALLOW policy must be paired with an associated DENY policy...else your 'policy' is not one of coherent-level intent.

Re:heh, 3Com

[Anonymous Coward]

there really should be a special mod category for trolls that are worth reading.

Routers

[Zarxos]

Personally I don't see any use for software firewalls for the majority of home users. I have a Linksys router and it completely shields both of my computers from outside access unless I use port forwarding. This is much easier to configure and use than a software firewall, and if there is ever a port you need to open for whatever reason, just use port forwarding and it's done in 30 seconds.

Re:Routers

[thynk]

sonally I don't see any use for software firewalls for the majority of home users.

Kind of funny that this comes up right as I'm thinking that my hardware/router based firewall isnt' enough and that I need to back it up with a linux software firewall.

IIRC on the home routers, any program requesting a port to talk out of can recieve a request back on it. SO... your WORM opens up port n, sends the info, get's it's commands to try on your system, then sends off the next command it's done/how and waits for it's marching orders.

Re:Routers

[blix5]

I think the use of a firewall on a home pc, whether it be software or hardware, is important.

Most home users have something extremely valuable to a remote user - hard drive space. And considering that most end-user computers connected to the net are Windows machines, there are plenty of open and unsecure network shares just waiting to be used. (Not encouraging any snooping, but you can prove this yourself by scanning a range of UDP:137 ip's. If you do this, you'll probably raise someone's security flags, so don't.)

That's something to think about in addition to the usual trojan/worm/spam topics associated with intrusion.
I don't really go for the idea of being someone's remote file server.

Re:Routers

[raga]

SO... your WORM opens up port n, sends the info, get's it's commands to try on your system, then sends off the next command it's done/how and waits for it's marching orders.

To do this, the worm would already have to be on your disk. If your system is already infected, then all bets are off....

If Jane Q Public has a router that requires port-forwarding for external connections, and she takes other reasonable precautions to prevent an initial infection (re. downloads, email attachments etc.), she will be ok from 99.9% of the s'kiddies out there. Good luck with the remaining .1%!

cheers- raga

Re:Routers

[mosschops]

Personally I don't see any use for software firewalls for the majority of home users.

I'm still using a software firewall on my XP machine at home, despite being behind a Linux gateway machine using iptables.

Why bother? Spyware! I might be relatively safe from incoming attacks, but I'd also like complete control over outgoing too. I could configure iptables to do the same job, but it would silently block everything, and I'd like to confirm anything unusual (perhaps a web page is sourcing something from an unusual port). Of course, I set up rules for common permitted stuff to avoid being hassles all the time.

I suppose A software firewall can help reduce outgoing connection damage (spam, bots, ...) from virus attacks, but I'd certainly never rely on it.

Re:Routers

[demaria]

http://www.nwc.com/1223/1223f45.html

If you use IPTables on your linux box, you're not going to be doing much. IPTables is just a packet filter, and can't block access to individual applications.

Re:Routers

[Telastyn]

That's fine, personally I don't see a need for any firewall on my properly configured home machine. I understand the fact that nearly every home user will not be able to lock down their machine, but seriously, shouldn't they be locked down in the first place?

Re:Routers

[evilviper]

your WORM opens up port n, sends the info, get's it's commands to try on your system, then sends off the next command it's done/how and waits for it's marching orders.

And might I ask how you intend to prevent that?

Let's say the worm uses port 80. And let's also say that this program is perhaps a variant of something know, but has changed enough that IDS sigs don't detect it.

Now, how exactly do you think any firewall is going to stop this activity?

Re:Routers

[thynk]

Let's say the worm uses port 80. And let's also say that this program is perhaps a variant of something know, but has changed enough that IDS sigs don't detect it.

Now, how exactly do you think any firewall is going to stop this activity?

Well, personally, I tend to keep read the logs that my router sends. If I see unexpected activity, I do a little bit of research, and usually block the IP that the outgoing program is trying to send to. Having never been subject to a worm, I have been able to keep a nasty piece of spywear from reporting home on boot up.

Not a perfect solution by any means, and of course, it has to get out at least once before I can catch it. Maybe I need more of a life but I really don't care for my bandwidth and my net connection being used with out my approvial.

Yeah, I think I need more of a life.

Re:Routers

[evilviper]

You'd be better off running netstat once in a while, or, better yet, just leaving ntop/pktstat running on a machine... Those make for much better monitoring methods than looking through ever transaction...

Sunscreen

[Anonymous Coward]

A great firewall, one of the biggest mess-ups sun has ever done. Now it is given out for free, on the Solaris 9 media. Check it out. If you are considering running a PC/linux firewall, you would be MUCH better served spending the same cash on a Sun v100 and running sunscreen. Same cost, but the sunscreen option is vastly superior.

Re:Sunscreen

[Anonymous Coward]

The messup is in their mis-handling of it.

tip on mitigating backdoor use on your network . .

[Anonymous Coward]

. . . use Linux.

arf!

[Artifex]

Actually, the most common sexual style is ::drumroll:: doggie style.

That's where the man sits up and begs and the woman rolls over and goes to sleep.

If only I could do that self-licking thing, like they do afterwards. Why do they even bother with the middle?

SSH Tunnels

[rf0]

One thing which is handy for backdoor is SSH tunneling. A nice exaple can be found here Just replace port 110 with anything else and off you go

Rus

Re:SSH Tunnels

[Rob Riggs]

A more generic solution for getting around egress filtering is an SSH-based VPN.

For even more pertinacious network environments, one can use httptunnel or the more advanced desproxy

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

Firewalls have NEVER been required to prevent remote exploitation on a Mac.

Uh huh. Then why was I able to accidentally lock a Mac hard just by port scanning it? Mind you, I wasn't even *trying* to kill it - I was doing a security audit to see what it had open. This was back in the MacOS 9 days, when I was still a Mac admin. Thankfully, that nightmare is over.

Popups

[Anonymous Coward]

I actually like those popups. I can know which programs are accessing the Internet and can allow/disallow them at will. Programs like Gator and Comet Cursor and more.

Re:SecurityFocus says no MacOS EVER exploited once

[Feztaa]

Why is is hack proof?

Right. It's secure because they removed all the things that make a computer worth using. No command shell? How do you do remote administration? Bleh, i could go on, but I don't care.

its quite amusing that there are over 200 or 300 known vulnerabilities in RedHat over the years

I think you mean "200 or 300 fixed vulnerabilities". That's just how it goes, I guess. They find a problem, it is disclosed, and fixed. End of story. Unlike other OS's that try to hide all their problems instead of fixing them and being honest about it. Whatever.

--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.

Too stubborn, or too poor? I'd buy a Mac if I could, but I'm not a billionaire. Commodity PC hardware + Linux = cheap access to fun technology.

Re:heh, 3Com

[thynk]

there really should be a special mod category for trolls that are worth reading.

Pretty sure there is one, called +1 Funny, but you're right, that one does deserve something special. I think the mod system works well, but it's really outdated. Maybe I'll crank out some cgi over the weekend and host a public vote for new mod catagories for my web page... or then again, maybe not.

Re:I GO IN

[Anonymous Coward]

That Doors tribute to sodomy was the best.

Re:For more info...

[marcushnk]

hmmm unles you like to see pink pixels, I suggest you skip this link...

What about the end-to-end argument

[Anonymous Coward]

There can never be complete security unless its implemented at the end, for instance that firewall is only as secure as it breaks your internet connection.

A firewall program running on the PC is still not at the end, its between the application and internet.

Just install some anti-virus PCcillin and suddenly your LAN shares are disabled and no-one can connect to your ftp server. I spent an hour figuring out why the hell things didnt work on a friends PC, i was about to ask him call his ISP tech support and check if their ADSL modem do some NAT or acts as a firewall.

Pushing NAT solutions on customers is the standard these days it seems, charging a monthly-fee for every IP you need is also part of their business plan. Which system is of course optimized when it goes to administrative expenses so they get as much as possible (99.9% profit for every extra IP a sucker "borrows."

And no, if the ISP cant document their expenses, they have no right to take a monthly fee according to ripe 152

Re:What about the end-to-end argument

[retto]

nat is bad....yadda yadda yadda...IPv6 will solve the world's problems.....yadda yadda yadda....everybody gets an ip and a bright orgasmic future....something something something. It's late and I'm too tried to try

Re:tip on mitigating backdoor use on your network

[Anonymous Coward]

Or wear an anal chastity belt.

Most secure solution isnt simple, but its the best

[Zeddicus_Z]

1) Use both inbound and OUTBOUND ACL lists on routers, firewalls and other access control devices. Go with the highest level of restriction you can get away with, and log everyhing to a central point.

2) For services you must offer to internal users (www access etc), use good proxies and authenticate every connection.

3) Ensure all services/software products are up to date with security patches. This INCLUDES user workstations.

4) Keep track of security-related sites and lists, such as bugtraq, packetstorm etc.

5) IDS' inside your perimeter to detect anything you're missing. After all, no-one (and by extention, no-one's ACLs) is perfect.

6) Ensure you pay close attention to any remote-access you offer. Modem banks, VPN endpoints etc. Preferably these should also be access-controlled via ACL's of some sort.

7) Ensure you configure your software properly. Seems stupid, I know. But a perfectly secure (from a bugs point of view) mail server is suddenly a problem if you've forgotten to disable mail relay.

8) Ensure you have the right topology. There's no point in spending hundreds of man hours securing services, auditing router ACLs etc etc if theres fifteen different ingress/egress points to your network. The less, err, gresses you have, the more you can concentrate your efforts and thus use your time effectively.

Caveats: I may have missed one or two points in the above summary of practice, but hey - it's a friday arvo and I want to get my work finished so im not here late.

Also note that while the above list sounds relatively easy to implement, IT ISN'T. Be prepared for a lot of work if you want to do it right.

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

One thing it can't handle is 1gb and above of RAM on a switched gigabit network. Run it with 512Mb and the thing runs fine, upgrade to 1gb and it shits itself. Network throughput drops to about 10Mbps. The reason? With 1Gb of RAM virtual memory is FORCED to be disabled and can't be re-enabled. Seems that the pos can't keep up with gigabit network speeds without virtual memory enabled.

Had this problem at a large publishing house and spent days talking with Apple about it with no resolution besides Apple's suggestion to drop back to 512Mb. Yeah, its a top OS.

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

Mac OS is slow and unusable. Not the classic mac

It may not be unusable, but it's plenty unstable. "blah blah you run shitty apps whatever": I'm not going to waste my time rebooting every time some app -- well-regarded commercial titles with few to no viable replacements as well as shareware that the developer put fuck-all time into -- up and dies. Which, by the way, was far more frequent than expected.

"but no overhead! hardware performs seven thousand times better!" Wow, that's an excellent point. I also write all my apps in machine language by hand. I can never have too much performance!

"real-time os!" Yes, this is truly indispensible for all those times I use my Mac to control medical equipment and fly airplanes. For more realistic concerns -- say, audio -- OS X is just fine.

"os x doesn't cut power to pci slots!" If this makes you angry, then you need counseling. No, really. I'm serious.

"MacOS is awesome, thats why 85% of all google searches are from MacOS browsers and not OSX browsers!" Windows is awesome, that's why 92% of all Google searches are from Windows browsers!

Personally, I'm thrilled to be finished with OS 9.

Re:Most secure solution isnt simple, but its the b

[retto]

Of course, a network's weakest point is often the people who use it. Firewalls and security patches do not mean a lot if a user gives information out to anyone who calls their extension and acts like a manager from another department. Hardware is only part of the solution.

You just described DOS.

[Burning1]

...and based on what you've written, I'm willing to bet you've never run a network larger than the one in your home.

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

85% of google searches are from MacOS and 92% are from Windows? What does that leave for Mozilla?

Re:SecurityFocus says no MacOS EVER exploited once

[cloudless.net]

No command shell? How do you do remote administration? Bleh, i could go on, but I don't care.

I agree with most of your points, but the command shell is not necessary for remote administration. You can always use web-based admin tools, or remote control software such as VNC, Terminal Server, pcAnywhere.

Re:SecurityFocus says no MacOS EVER exploited once

[Feztaa]

I guess. I'd take SSH over webmin anyday, however.

Re:SecurityFocus says no MacOS EVER exploited once

[drsmithy]

[...] too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.

Well, I'm not "the linux community", but I'd like to see your MacOS 9 box serve up files for twenty thousand students and staff with decent performance and mantain an uptime greater than single digits.

Default deny

[MadFarmAnimalz]

They avoid immediate detection by well-configured firewalls, network & host IDS.

Hmm, well, not necessarily. I am thinking this is why there is such a thing as a default-deny firewall ruleset policy.

For example, you have a dns server and http server up and running on the standard ports, and anything else gets binned.

I'd say that's a fine example of 20-year-old technology (firewalls) catching a backdoor.

Something like Zonealarm for linux?

[jopet]

I wonder if there is some simple software for linux that alerts me every time a program tries to connect to the internet (outbound) and that allows me to allow or deny those connections. It should also detect new versions of the program using MD5 key or similar. Does such a program exist?

Re:Something like Zonealarm for linux?

[Alex Belits]

It will appear when the first spyware will be written for Linux. And will be used by people who install software that they can not trust.

Right now even the worst spyware offenders have clean Unix/Linux versions/equivalents, so it's pointless.

Re:Something like Zonealarm for linux?

[c0dd3r5]

It just so happens... as of about three days ago, my associates and I have been working on just such a program. It basically hooks into net/socket.c and, on receiving a socket request, blocks the requesting application until a userland daemon authorises it. The daemon automatically grants / denies requests to applications in its control list, and denies requests from unknown applications. We're about to starting working on the client which, when running, will receive information about the unknown app. and ask the user if said app. ought to be allowed to use the internet.
Obviously at the minute it's still heavily alpha. The kernel patch works, and applications can be made to block or allowed to run. I don't know if this has been done before, but work is continuing apace (cause it's still interesting and we haven't hit a brick wall yet). I hope to have gotten something resembling a client working by this evening, but since we're pretty much messing around at this stage it'll probably be a couple of weeks before any files are available for download.
As for authentification, MD5 summing was one of our thoughts, but it would be a little heavy to sum the application every time it requested a socket, so at the moment we're just basing it on inode / dev_no which, although not impossible to fake, seems like a good starting point.
I'd be interested to know what people thought about this; whether any such applications already exist and what features it ought to incorperate. If it turns out people are interested, I'll try making the patches and source files available, but I can't recommend installing it into a kernel which you're actually trying to use - suggest UML or similar virtual machine.

Re:Something like Zonealarm for linux?

[autechre]

I think it sounds interesting. Of course, I am biased, but I think a good way to get developer attention would be to submit this to freshmeat (if you haven't already).

Another interesting idea would be to expand this to work on a NAT gateway, dynamically adding iptables/pf/etc. rules for individual machines or entire subnets. Or maybe even go further and do traffic analysis at higher levels ("disallow all traffic of this type (Kazaa, etc.) from this subnet"). Of course, this is getting way ahead, and I also don't know if software to do any of this already exists (for *nix). I mean, I know such filters exists, but I don't know if dynamic configuration does. Again, bias (they employ me), but you may want to search freshmeat.

The other poster has a good point about traffic being denied while you're not there to observe it, although I wouldn't see that as necessarily a problem (the idea of this application is that you don't want surprise traffic getting through). If the daemon has good logging, and the config file can be edited, then you could take care of this remotely if it became a problem in a specific case.

Re:Something like Zonealarm for linux?

[Vainglorious Coward]

Interesting. Have you considered creating this as a module that could be used from iptables?

Re:Something like Zonealarm for linux?

[c0dd3r5]

The idea of dynamically adding rules to iptables is appealing. This is an application level filter, effectively, and it can't as such mangle packets or silently drop them as iptables can. Nor can it do half of the other neat stuff that iptables does.

The poster below suggested making this a module of iptables, but I don't think that would be particularly easy as iptables would have trouble causing the applications themselves to block - the packet has long since disassociated with its sender. I think, though, that it would make a useful partner to iptables. The ideal would be to have something like 'deny all' as your basic firewall setup, and let this punch the requisit holes as your applications bind sockets. I've yet to discover, though, how this might affect performance.

As for adding it as a project, I'm considering it. There's an awfully long list of firewall projects on freshmeat, but none of them seem to do quite what this does, so it might be worth a go.

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for procces to process communication that is heavily typed and "pipe-less"

Remember, you can't carjack a brick either.

The whole article describes:

[Alex Belits]

1. What firewall software pretends to do (as opposed to what it actually accomplishes).

2. How to become a perfect target of DoS attack through paranoia (imitation of any intrusion-like activity will make the supposed origin unable to access you).

3. How to defend yourself when you have already lost, and are for all practical purposes as good as dead.

Everyone seems to be missing the point

[scottme]

I am not enough of a security geek to fault this article on any technical detail, but surely the main message is that no matter what technical measures you take, any dumb user can totally subvert all your efforts by inadvertantly, unwittingly, or even maliciously running code on a personal system inside the secured network that opens a tunnel to the outside. Hence the title of the article.

The concluding sentences contain the main learning point, as I see it: you need a way to identify all connections down to the source (user).
And you need to make sure that all those dumb users know you're watching them and that you will hold them accountable for breaches of security that they initiate.

Or is all that so obvious that no-one has felt the need to point it out?

Re:Everyone seems to be missing the point

[Zeddicus_Z]

Actually, thats not exactly correct.

Using restrictive ACL's on your outbound interfaces, you can kill connectivity for most types of malicious connections. For protocols you MUST run - say HTTP, outgoing SQL, outgoing SMTP and the like - you *proxy* every single connection, and ensure each connection is authenticated.

The beauty of this solution is two-fold. First, it blocks off almost every type of malware connection you're going to see from exiting your network to $SKIDDIOT on the outside. Secondly, those smart enough to use something that can a)use a port such as HTTP's TCP80, or b)encrypt while doing a, are not a problem if you're using decent proxy software. By definition, proxying requires that the proxy machine be intimately familiar with the protocol being proxied. As such, it can recognise the data within thing such as FTP and HTTP requests being proxied through it and (heres the interesting part...), BLOCK connections it does not recognise as being legitimate. BAM, no more netcat over port 80.

Of course, if your malware is controlled via web interface and thus uses legit HTTP protocol commands, you may have a harder time of it.

Re:Everyone seems to be missing the point

[graf0z]

There are two facts which seem to be contrary (but aren't):

• If there is _any_ way to commuticate to the outside world, an intruder can (steanografically) tunnel information though this way. There is software to tunnel ip(sec) over icmp, http, smtp, dns. There is _no_ way to stop it.

• The more You restrict connections from inside to outside (by proxies, authentication etc) the fewer intruders will have the knowledge how to smuggel information out. Particulary trojans are (nowadays) too dumb to pierce well-crafted firewall/proxy concepts.

So the more You work on jailing, the less will be able to escape.

btw: the ip-over-dns stuff is really useful: there are lot's of (hotel/airport) wlans, where anyone can use a dns-server which resolves exterior zones ... nothing more needed.

Re:Everyone seems to be missing the point

[n3m6]

and these days with programs like http-tunnel you can use whatever program you want to use from a proxied HTTP connection sitting inside a 'secure' zone. i was just using Kazaa Lite just today in my office. wonder if my sysadmin knew.

Mod Parent Up (n/t)

[theTerribleRobbo]

As per subject.

Not only that but..

[Anonymous Coward]

1) Load Balance the Mac Box
2) Provide detailed analysis from the Web Logs in charts and graphs
3) Provide the serving of ASP, XML pages
4) Run a SQL server on it.
5) Prove that the Mac are not only a business system but also prove that Mac servers have any sort of OS based encryption for logins.

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

2> No Root user. All mac developers know their code is always running at root. Not hing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.

This is the dumbest thing I have read all week. Possibly all year. There is no root user. Wait, I mean we are all root users. yep, that's why it is so secure. Chit, look how secure Windows 95 is if you don't believe me! Good job, ace. Now go don your black turtleneck and suck on some blueberry ice pops.

Firewall Systems Considered Harmful

[Alioth]

I would write a long rant about firewalls and people thinking, "Oh, it's OK, we have a firewall" and not dealing with internal security, but this article does it adequately:

Firewall Systems Considered Harmful

I do not think it is pointless ..

[jopet]

It would be easy to convince some linux user to run a program that has been modified to do spying. Any game, tool or other program will do. This need not be distributed by a "spyware" vendor - it could all kinds of paths to get on somebody's computer. And clearly, if such a protection program only gets developed after the first such trojans appear, it will be too late. Another point is that one might want to prevent programs from building a connection that are not spyware - there are dozens of reasons why you might want to do this. So really, I do not think it is pointless at all. It is a level of protection that is - if you are right and there is no such thing - clearly missing with Linux.

Re:I do not think it is pointless ..

[Alex Belits]

Things like ZoneAlarm are in most of the situation a kind of a cure that is far worse than a disease that it is supposed to cure. There are many programs that have absolutely legitimate reasons to talk to the network, and most of them are not interactive. I don't think, a user will be happy to see hundreds of "fetchmail called from cron called from init is trying to ACCESS THE INTERNET -- allow (Y/N)?" when he wakes up after scheduling mail download every ten minutes and leaving it running for the night. Games, browser plugins, etc. mostly are designed to talk over the network, so just allowing/denying them something would be pointless. And, of course, package management should not be mixed with this -- if the user runs something that modifies executables that he runs, he has a larger problem on his hands than some unrecognized network connection.

What user should do is to avoid installing untrusted things in a way that they can access something that he does not want to be accessed by others. File permissions and users exist for a reason, and network connections from unprivileged ports and without authentication are not supposed to be trusted within the network in the first place.

One can justify tools that restrict network connections/packets made by certain "unprivileged" users (and that is already supported by netfilter), and make wrappers that run some applications as different users, in chroot, etc. , but those things should be configured once at the time of installation, and should not require manual intervention just to pass a packet. There is absolutely no reason to imitate the behavior of consumer-grade software, made to mitigate the existing abysmal security design of systems where such things are used.

Transparent firewalls

[nmg196]

While it's on topic, I've always wondered how many people use transparent firewalls. I work for a small web development company in the UK and as such we have about 30 IP which host a few public facing webservers as well as our mail and stuff. We decided to use a transparent firewall (ie, one that lets us keep our 30 real IP addresses on the machines which are public facing - rather than 192.x or 10.x addresses) so that if there were any problems with it, we could just remove it (physically) and everything would still work. No network reconfiguration required.

But it seems that it's quite uncommon for firewalls to even support this feature and even less common for people to actually use it in this mode. Is there a reason that more firewalls don't support this functionality, or are there good reasons not to configure your network like this?

A major problem we would have if we used something like a Cisco PIX is that we wouldn't be able to see the websites we are hosting. The domain would map to a normal internet facing address, yet we can't see those addresses from the LAN (they don't seem to apply the port mapping to connections that have come from the LAN - so we'd need to look at them on their internal IP or something).

How many people actually use transparent firewalls? Or how do you get round the problems above if you're a web hosting company and you don't have a transparent firewall? Do any decent firewalls (apart from Sonicwalls) actually support this?

Nick...

Re:Transparent firewalls

[Zeddicus_Z]

I suspect you haven't actually tried to implement a PIX yet. The Cisco PIX (at least, the low-end 506 we have) *does* support what you're talking about - although what you're talking about isn't really a transparent (also known as *bridged*) firewall.

Setup the PIX. Use static maps for the IP addresses, so your webservers etc are behind the pix but using the public IP's. When an internal machine tries to connect to the IP address of your website (say 210.20.38.129), the request is forwarded to your default router (border router usually, unless you're on a larger network). The router gets the request, goes "hey, im responsible for that IP. It should go *HERE*" and fowards it back to the webserver *through* the PIX. At no point does the PIX attempt to map the IP address of 210.20.38.129 to the MAC addy of your webserver for the internal connection. Only after the connection has bounced off the border router does the PIX go "hey, incoming *external* request for 210.20.28.129. I've got a static route for that. I'll send it to $webserver". And your connection works.

Now, if you use a domain name for the request (as most people do when using a web browser), your internal requests will first bounce off your internal DNS. And that's where the problem is. Your internal DNS is configured to point www.myinternalwebserver.com to 192.168.0.129 (or whatever the machine's internal interface is) instead of the public IP address. If it was pointed at the public address, your machine would get said address returned to it after doing the DNS lookup and follow the steps in the paragraph above. Namely, the req bounces off the border router.

As a side note, transparent firewalls are synonyms for bridged firewalls. I.e. it's impossible to actually gain network connectivity to the firewall because for all intents and purposes, it's setup to act as an intercept on a peice of cat5, not as two interfaces seperating two network segments. Think of it as tapping a Cat5 cable and trying to ping the tap itself. Not going to happen, as neither the bridged firewall system (or the tap, per example) have interfaces with an IP address.

There's a guide floating around the net on how to implement bridged/transparent firewalls using OpenBSD if you're interested. It can be found at http://ezine.daemonnews.org/200207/transpfobsd.htm l

Re:Transparent firewalls

[nmg196]

You're right - I haven't actually tried, I was just repeating what I'd been told by our firewall supplier (who may or may not be particularly knowledgeable).

The other criteria which I forgot to mention is that we also need VPN support. Can a bridging firewall support VPNs when, it doesn't actually have an external facing IP of it's own? Presumably it would have to create a virtual IP address and use that for the VPN?

I don't really want to try building one myself using BSD, as then it would be my fault if it didn't work :)

Nick...

Re:Transparent firewalls

[feepcreature]

All firewalls I know of can behave "transparently" as you have described it - basically like a normal router, but also filtering undesired traffic.

There is no requirement for a Checkpoint/1 or Cisco PIX firewall, for example, to use private addresses on the inside, and translate them into public addresses on the way out. It's just a question of how you configure the system.

On the one hand, you could have your public addresses "on the inside of the firewall", with one address being the firewall's "inside" interface and the default route out to the internet for your servers - allowing for the network and broadcast addresss, that leaves 29 usable addresses for systems inside your firewall. You would probably use a private address for the outside interface, but you'd sort that out with your ISP. No address translation required. Like your sonicwall, perhaps?

On the other hand, you could configure your public addresses as a pool on the firewall, and have it translate them into private addresses on the way in (and public addresses on the way out). And you could have a 1:1 or a 1:Many mapping. But you don't HAVE TO do any of this.

On the third hand, you could split the 32 addresses, use Network Address Translation for some of them, and route the rest transparently through the firewall.

In any of these cases, you can also apply whatever rules you want to each of the addresses.

Or am I misunderstanding your question?

Re:Transparent firewalls

[Zeddicus_Z]

Bridged firewalls support VPNs, in that they'll pass VPN traffic. however, as they have no IP addresses, you can make them endpoints for the VPN tunnel. What you'd have to do is setup a 2nd host inside the bridged firewall, and use that. Keep in mind however that anyone who can authenticate to your VPN is treated as an internal user. So, if you have business parter type companies connecting, its best to keep a close eye on VPN traffic coming OUT of your VPN endpoint and into your internal network.

Re:Transparent firewalls

[feepcreature]

Can a bridging firewall support VPNs when, it doesn't actually have an external facing IP of it's own? Presumably it would have to create a virtual IP address and use that for the VPN?

That probably depends on the firewall. Can't speak for Sonicwall. But there will certainly need to be a public address somewhere on the firewall.

I know that in routing firewalls, VPNs have been set up to publicly addressed inside physical interfaces. I've heard reports of problems using virtual interfaces for this, with some makes/models/versions.

Bridging mode, well, I don't know.

Re:Transparent firewalls

[MadHungarian1917]

Use the fixup DNS command on the PIX to address the RFC1918 address inside registered address outside problem You of course will need DNS service on both networks i.e. internal dns serves the 192.168.x.y network and the external dns server knows about the public addresses. Your inside DNS is configured as a forwarder so that queries which it cannot resolve directly are punted to a external DNS server which can resolve them and the FIXUP DNS takes care of the issues with the payload.

Re:Transparent firewalls

[BigBadBri]

Our Lucent 501 can.

It's not as clever as a Checkpoint, but for a bridging firewall it's quite neat.

Re:Transparent firewalls

[MeanJeans]

With the PIX, if you have a DMZ interface, you could put your webserver in the DMZ with a private address (192.168.X.X), and you would use the "alias" command to map the public address of the server that is in DNS to the actual private address on the server.

This would allow you to hit your webserver by name from inside your network.

If you do not have a DMZ interface, you can NOT use the "alias" command to map the public IP to the internal private IP as the PIX does not support IP redirection.

Re:Transparent firewalls

[nmg196]

Actually I've only got the Cisco PIX 501, so maybe that doesn't support bridging mode. I can't find anything in the docs about how to configure this.

Re:Transparent firewalls

[Zeddicus_Z]

You're not after bridging mode, as the PIX wont do bridged. What you want are static routes pointing at the public IP of your machines. This, in conjunction with having your internal DNS point at the public IPs for the domains you're hosting instead of the internal ones, will ensure it all works.

hmm, that's FUD

[DrSkwid]

1. how do you know?
2. your computer != all non windows setups
3. 10 Months is not a long time
4. Robert Morris

Re:hmm, that's FUD

[Gunzour]

hmm, that's FUD

Kind of like the web site in your sig?

Re:hmm, that's FUD

[pair-a-noyd]

I have 7 PC's here at home, all of them are Linux.
I have ONE laptop from work that has Windows on it. I only fire it up when I *HAVE NO CHOICE*....

I *USED* to be 100% Windows here, at home and work. I work on Windows computers for people, professionally. I'm IT..

It's not FUD, it's FACT.. I know it from experiance.
I've worked on computers for a living since 1981 and "played with them" since 1978. I didn't just fall off of the turnip truck...

does anyone know how secure smoothwall with ports

[Anonymous Coward]

80 and 21 forwarded to a windows 2000 sp3 updated iis5.0 webserver ?

The real victim...

[Anonymous Coward]

Correct me if I'm wrong, but I believe that's Bill Gate's machine...

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

110%. Like those jocks who always give 110%. Same ignorant bullshit.

great!

[jopet]

as you have guessed from my initial post, I am glad to hear about this! Certainly a very important contribution. As I am more an Linux end-user than a developer I cannot help much with ideas - except that there might be situations where a progam wants to establish a connection, but the user is not logged in or no interactive session exists. It might also be that a program running under root establishes a connection, but this was triggered by some other user. On many desktops there is usually only one user active ... it would be good to be able to optionally "route" all permission requests to the interactive session of that user. Also it is probably not easy to get a client going for X and text-only users.

Re:SecurityFocus says no MacOS EVER exploited once

[ldspartan]

I concur. I had the unfortunate experience of deploying a MacOS 9.x based webserver running a compute-intensive webapp, and it worked so poorly that it was actually unusable. The http server software (AppleShareIP) didn't stay up, and when it died it would do so silently. It also allowed no way to set custom error pages which were direly needed, and the lack of preemptive multitasking failed miserably to utilize the abilities of the dual 600-ish MHz machine.

And yes, all of this was running on the fastest machine you could buy from Mac at the time, with around a gig of RAM.

--
Phil

Re:does anyone know how secure smoothwall with por

[spaic]

It's as safe as windows 2000 sp3 with updated IIS 5.0 listening on port 80 and 21.
ISS related exploits

Re:SecurityFocus says no MacOS EVER exploited once

[Anonymous Coward]

Right. It's secure because they removed all the things that make a computer worth using.

Ah..., what makes a computer worth using is userful, powerfull applications. The Mac has had plenty of those over the years, some of which went on to fame and glory on other platforms, like Microsoft Excel which started on the Mac.

How do you do remote administration?

Both apple and 3rd parties have provided a number of remote administration capabilities over the years. That sort of thing doesn't require a command line. You're showing limited imagination, or ignorance.

I think you mean "200 or 300 fixed vulnerabilities".

No, he got it right in sense: 200 or 300 vulnerabilities. Just because a fix was made available or later integrated into the release doesn't mean that people actually use it. "Unpatched Red Hat server gets hacked" is at the level of generic news. Why? Because those "fixed" vulnerabilities haven't been patched on the system that matters: the one in use thats getting hacked.

That's just how it goes, I guess. They find a problem, it is disclosed, and fixed. End of story. Unlike other OS's that try to hide all their problems instead of fixing them and being honest about it. Whatever.

Its hard to tell who you're trying to slam here, (Microsot? Apple? HP? SCO? Red Hat?) but I'll guess its Apple. If that is so, you have no idea what you are talking about. Apple has an extensive, publicly available support database and patch system. They were doing that long before *nix was a twinkle in Linus's eye. If the only basis for your slam is that they don't provide source code, then I think that you are going to be in for a life of disapointment: few vendors outside of the niche Linux community do, and few Linux vendors have survived over the years. If Linux is going to be a commercial success it will need vendors selling software for it. Very few of those will provide source code except under what are likely to be very limited and expensive circumstances.

I'll assume that when you way "Whatever." that's just shorthand for "I don't know what the hell I'm talking about and dont care to know whatever could be known from a visit to 2 or 3 web pages."

Too stubborn, or too poor? I'd buy a Mac if I could, but I'm not a billionaire. Commodity PC hardware + Linux = cheap access to fun technology.

Used macs good enough to decrease your ignorance about classic MacOS can be had for $10-25. Even Macs in that range can run Linux or *BSD.

iMacs or eMacs can be found for prices that are very competitive with all but the cheapest white box PC prices and will run MacOS X for the same type of "fun technology." They also have a wide variety of commercial desktop applications and games.

Bleh, i could go on, but I don't care.

You don't know, either.

Kind of an interesting combination: you don't konw (ignorance), you don't care (apathy), but you go out of your way to slam Macs. I suppose thats because some uncharitable words were said about Linux, apparently the love of your life. Well, someday you will wake up and realize that Linux is just like any other OS - it is flawed. It has bad breath, its ill-tempered, and a little unsociable. It's user friendly, but its pickly about its friends.

Never troll a troll, kid

[Anonymous Coward]

It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.

But you can DOS an OS 9 or earlier based web server by making 2 requests at the same time.

A good example

[Metuchen]

If they want to see an example of a real backdoor, they should see the one on my house!

Re:SecurityFocus says no MacOS EVER exploited once

[Lost Engineer]

Port scan? It's easier than that. I once accidently started the re-imaging program on a Mac at work which completely locks the machine while it is imaged. Fortunately, I happen to have a CD-R that I created by accident one time (with a Mac no less) that is guaranteed to crash any iMac just by putting it in the drive. Worked like a charm, and I kept my documents from being imaged over.

The more you tighten your grip...

[fizbin]

Using restrictive ACL's on your outbound interfaces, you can kill connectivity for most types of malicious connections. For protocols you MUST run - say HTTP, outgoing SQL, outgoing SMTP and the like - you *proxy* every single connection, and ensure each connection is authenticated.

This is, so far as I can tell, standard industry practice in certain places, and I'll tell you the result: everything gets tunnelled over HTTP.

When people have some brand new protocol (say, when Microsoft was developing SOAP), they'll make it so that it tunnels over HTTP. When some random company designs the protocol that their new data appliance uses to call home for updates and instructions, they'll tunnel it over HTTP. Eventually, every possible bit of functionality will be tunnelled over HTTP. Those trying to secure the network will have gained nothing except extra bandwidth and protocol overhead.

Face it guys - you're shooting yourselves in the foot here over the long term. When employees with the purchasing power and authority to place a machine on the network cannot get the network administrators to open up necessary port access (and if it's too much of a hassle to deal with the network security guys, then that's just as bad), you have the situation where network security will be circumvented.

Network security only exists with the active cooperation of informed employees; pretending that it's a purely technical problem that fancy network hardware can solve is just wishful thinking.

This article is missleading.

[Erris]

You say the article was about, "How to defend yourself when you have already lost, and are for all practical purposes as good as dead." I agree, the artilce is very defeatist. What really bothers me, though, is a missatribution of the cause of defeat.

This piece of balance was less than objective:

Chances are significantly higher that in most organizations a hacker will have a much easier time finding an un-patched Windows or *nix system to exploit than they will an un-patched and/or misconfigured piece of perimeter networking/security equipment.

Why do people equate M$ security and code quality with what is available in the free software world? There are far fewer means to break into a machine running free software than there are ways to break into a M$ box. In fact, there's hardly a Microsoft box out there that's not already owned by Gator or some other perverse spyware. I've never heard of a free software based DDoS attack, and it's not because there are not enough Linux boxes in the world to muster a few hundred if indeed the Linux boxes were as fragile as their M$ counterparts.

The defeatist attitude the article is really dealing with is, "My desktops are insecure and there is nothing I can do about it." It's not true and it's a disservice to perpetuate the attitude. As you note, the cures they offer are worse than the dissease.

Re:This article is missleading.

[Alex Belits]

It's not as much the problem that there are a lot of insecure desktops as that those insecure boxes are trusted just because they are behind some firewall. If the trusted boxes are known to be insecure, the sysadmin has two choices -- replace them with something more secure, or make them untrusted. Trying to secure a Windows box running Outlook and with the user that can install software and doesn't know spyware or trojan from a legitimate software is a waste of time, and trying to mitigate the consequences of such a box being compromised is much more difficult than either replacing it (face it, Solitaire is not a work-related application, and users have no business exchanging Word documents with embedded macros), or establishing a draconian policy of what users should install. Regardless of this, there is absolutely no excuse for treating every Joe Schmoe desk jokey's box as trusted -- they potentially can be just as hostile as any other boxes at the other side of the firewall. There are plenty of ways to restrict access within the company's LAN and use reasonable access/password/encryption policies. Then firewall will become what it is really good for -- a tool used to prevent the waste of address space, and to provide an additional layer of security that in no way should be treated as absolute or reliable.

Also the sysadmin should not try to prevent users from INTENTIONALLY installing backdoors, compromising their own boxes or sending company's information outside -- when that happens he is guaranteed to lose because the only way to stop that is by never letting the employees to leave their offices until the rest of their lives. As long as some packets are allowed to leave the network, they can be used for backdoors. If the company pulls the plug on its border router, same user will use his memory and scraps of paper as a "compromise mechanism", and both of those things are not supposed to be the responsibility of the sysadmin in the first place.

Instead of playing cat and mouse games with users sysadmin should spend the same time developing and implementing a reasonable security policy, or at least installing patches for known vulnerabilities. And CEO should think more about how to stop antagonizing employees to the extent that they sabotage their computers, intentionally install backdoors and send confidential information outside rather than how to waste few more tens of thousands on yet another firewall "solution".

Bits go in. Bits go out. That's what networks do.

[aphor]

The real problem here is that these Security Focus people are still trying to design a harder eggshell. Any "barrier" must allow some traffic through, or it will break the network. You cannot install a barrier that understands how to distinguish between good and bad traffic. It is not a closed problem. It is an open-ended problem. It isn't about computers or technology. Its about people and subversion. The answer is too difficult for most people: trust is arbitrary and inherenly flawed, but it is absolutely necessary for human interaction. The technology just fools us into thinking we can control things like a vending machine. The problem seems to be transparent because we can see lots of stuff on the inside of technological subversion, but at the bottom is void: trust is arbitrary and error prone.

The real answer is that we must do what we are already doing, willingly, instead of reluctantly as we do now: accept subversion as a part of the system. We must understand that we created the space-time in which the subversion is manifest. It must be percieved as the limits of our power. Once that is understood, it is also understood how to coexist with limited power. This is the fundamental social problem: being with others. Consider that the subverion is another feeling person expressing their limited power outside the scope of our limited power. Take compassion on that person if they do not know the suffering they cause will come back to them. Do what you can, each as individuals, to absorb the effects of those bad effects so that they do not become causes of other bad effects.

Recurse your awareness; avoid recursing your (or others') mistakes. Security does not exist. Only fools really believe in it.

Re:Most secure solution isnt simple, but its the b

[timeOday]

But at that point there's a serious question as to whether all that security is paying for itself.

Call up a company, promise them anonymity, and ask them how much hackers cost them last year, and they'll throw out some exorbitant figure. The best indicator to their *real* losses, though, is how much they spend on computer security, which in the view of computer security experts is never "enough" - i.e. the computer security experts overestimate the problem.

sorry didn't mention it's part of my job

[zptdooda]

Didn't make it clear that part of what my company pays me for is to investigate a broad range of risks.

We have a enterprise risk management area. And it's been about three days since I've talked with our company's compliance chief/ombudsman. There's a lot of peer review here - I help with that too.

Otherwise I'd agree with you - it wouldn't be my place.

Did you RTFA?

[Raedwald]

I put three nics in a Pentium 90 that I found on a trash heap [to create a firewall]. ... It's really easy to use and so far I've had no problems. ... and all of them are using iptables ... so everything is really secure.

I've done something similar. But did you RTFA? It's point was that backdoors are often not blocked by firewalls because firewall policies on outgoing connections are usually permissive. What matters, in the context of this article, is what your iptables restrict, not whether you have them at all.

Re:Did you RTFA?

[pair-a-noyd]

Did you RMFP? In case you didn't notice, and not to flame, but I mentioned that all my boxes are running Linux. No backdoor concerns here.

Now if I had some Windows machines on the lan then I *would* have cause for concern.
But of course I *don't* have any windows boxes so I sleep really well at night..
Really well...

Re:Did you RTFA?

[Anonymous Coward]

>but I mentioned that all my boxes are running Linux. No backdoor concerns here.

Now, for the record let me just say that I love linux, but give me a break....so you are saying that there are not, nor ever will be a backdoor concern with linux???

Re:Bits go in. Bits go out. That's what networks d

[pair-a-noyd]

Been smoking with the Dali Lama again eh??

Thanks god!

[miguelanxo]

I've been waiting for years to be mentioned in slashdot! Just as desproxy goes 3 years old, it deserved the right to be kept in the cyberspace for ever... And, just to be honest, I don't remotely think of desproxy as being as advanced as httptunnel.

Egress suggestions?

[menscher]

Ok, so everyone knows our ingress filters should only allow specific ports (22, 25, 80, etc) that we need public access to, and RELATED/ESTABLISHED connections. But what about egress filters? I don't have a clue what can be reasonably blocked, other than perhaps requiring the "from" IP to be mine or broadcast (to prevent sourcing an IP-changing DoS attack).

Anyone have suggestions?

Re:Egress suggestions?

[Meat Blaster]

If you're shielding Windows: I'd block the various Windows ports (137-139, some others introduced with Windows 2000 that I forget) unless you're using file/printer shares over the Internet. There may be other programs that leak packets out without your knowledge that you'd like to stop as well, although these are most easily identified with firewall software on the machine that raises an alert when traffic is attempted that you didn't explicitly allow (Norton's firewall seems to do alright.)

Re:Bits go in. Bits go out. That's what networks d

[jayrcee]

This is why we need the to mandate the implementation of RFC3514 right a way. It would sure make firewalling a lot easier.

"High school Cisco class"??

[Atario]

Whyyyy, you whippersnappers got it too easy. When I was in high school, we had to take BASIC classes on an old IBM System/34 with eight terminals! And Pascal on PCs with mono green monitors and two floppies (what's a "hard drive"?), or the sooper-dooper CGA one (four colors that we don't get to choose? THANKS!), if you were lucky! Aaaaand we liked it!

We didn't have no fancy-dancy Cisco classes (for two years, no less!)! If we wanted to learn about hardware, we had to scrounge around behind the local ComputerLand for junked parts, and we'd cut our hands on the broken circuit boards and CRTs! We'd be networking-ignorant morons with bloody shredded hands and we'd say "Ohhhh noooo, maybe this wasn't such a good idea", but it was TOO LATE! Aaaaand we liked it!

Living in a Past that never happened...

[Anonymous Coward]

Where to start? I'm a former mac lover. Seriously addicted to the kool-aid.

Mac classic webservers are not secure, merely obscure. To the best of my recollection, those rewards for hacking into web servers for classic mac were often collected - bugs were fixed, but budgets were reduced. In short, to say that there have been zero successful attacks is wrong.

There are some good ideas and approaches in the classic mac os, but it's time is long past. Just ask Apple.

I can appreciate where you're coming from, but really, it's time to move on. You're the only one staying behind...

I could not disagree more

[jopet]

On the contrary - the point is that there is usually no way how to know if you can trust a program or not. If I download a game, I want to play the game, but I might not want the program to send info to some server. it is therefore legitimate to restrict (or explicitly allow) the program to do that. This scheme should rather be extended. A program should also be optionally denied to do other things, e.g. modifiy the hard disk outside a specific directory. I.e. a dynamic and individual "sandbox" for programs which I have different levels of trust in. This would not force me to use only a very limited number of programs (which of the freshmeat programs are you really sure you can trust?) but at the same time minimize the potential desaster, should this really be malicious software. So having options like this is the property of a system with better security, and this seems to be the rare case where I have additional security under Windows.

Re:I could not disagree more

[Alex Belits]

All of those things related to accessing the user's files can be accomplished by running those programs as separate user -- this is why modern systems automatically update X cookies when the user successfully authenticates with su. This is a sufficiently isolated sandbox to run untrusted things.

With the network I don't think, there is anything that should be done except disallowing some users to use the network (or talk to anything other than a predefined list of hosts) _before_ some programs will be run under their userids. And netfilter already can do this.

Re:I could not disagree more

[jopet]

why? this would mean that you have to build many users that are not here for users but for programs. Effectively you misuse a security mechanism for something else, because there is nothing else there. Why is it so hard to adopt the thought that programs have rights that you can manage? This would be a natural extension to rights for users and files - rights for executables, stating what ressources they can and cannot access. I would expect a conservative attitude like this from hard-core Windows users ("user ids? we dont need that for the home edition ...")

Re:I could not disagree more

[Alex Belits]

why? this would mean that you have to build many users that are not here for users but for programs. Effectively you misuse a security mechanism for something else, because there is nothing else there.

This is precisely the purpose of this mechanism. "Users" in Unix never were supposed to directly correspond to people.

The problem with "just ask the user" is twofold. First, user usually can't determine if a program should be allowed to read any particular file in the first place. Should Mozilla be able to read /etc/passwd? /home/luser/.gtkrc? I know that it should, but how would the user know? And how will he be able to answer all those questions in the first place? Second, it's impossible even to find out if there is a user at the console to ask him -- where is he anyway if the box has 7 virtual consoles, 10 ssh sessions, and two local X sessions? And where is the "user" who will tell if, say, http server can respond to something (few hundred times a second)?

Why is it so hard to adopt the thought that programs have rights that you can manage?

Because "rights" can be only defined as attributes of an object. "Program" is not really such an object, it can call other programs, and no one would know which rights should be applied to what they do. User however can only be changed if the program called other setuid programs (that are supposed to manage permissions by themselves), or the original user is root (that no untrusted program should run as). This means that once something is started as some user, it can't gain another user's access no matter what. On the other hand, any program can at least copy itself, hide its name from monitors, etc. -- those things are not reliable, and can't be used as the base for restrictions.

Creating the lists of programs that _can_ access certain files and network will be a horrible mess -- first of all, it will be a giant list in any reasonable system, and second, any program that may be used with pipes or any other kind of modularized work may happen to end up potentially reading and writing any file on the system. Interpreters, including shells and perl, will be yet another can of worms -- though single executables, they may run all kinds of programs, and are usually called from other programs (CGI scripts and mail/news/http clients, to name just a few examples of programs that are hardly supposed to be "trusted") so their access can be only based on the userids. One can argue that there should be a "token" that kernel passes to everything called from a program, and that should be an object that permissions are attached to. I wholeheartedly agree with this, and can name two such tokens that exist already -- it's userid and group.

his would be a natural extension to rights for users and files

Files have no rights -- they have permissions, users have rights. This means, there is nothing attached to the file that "allows" it to access anything, only allows certain sets of users to access this file.

- rights for executables, stating what ressources they can and cannot access.

Executables have nothing that ties rights to them -- when called by different users they are supposed to be treated as those users. It would be ridiculous to create an additional layer of permissions that breaks the existing two (Unix permissions and ACLs). It will be something like, "this file can be read by all users in group staff, however everyone can run grep on it" -- what will in effect make it world-readable. Or, worse, "this file can _not_ be grep'ed by anyone" (and then someone/something will simply rename grep).

would expect a conservative attitude like this from hard-core Windows users ("user ids? we dont need that for the home edition ...")

This is just the opposite kinf of problem -- having versions of Windows where userids don't exist, makes it impossible to use them for uses that would make sense in Windows (like running the a

big deal

[DrSkwid]

because if you'd actually learned anything in the same 20 years that I've been working in IT it is that there is no "magic platform" that's invulnerable to sloppy coding be it windows, linux, AIX, plan9, OpenBSD or whatever.

Go read Security Focus and count the number of "Design Errors"

Here's one from today's front page :

Linux Kernel Privileged Process Hijacking Vulnerability **

> I have 7 PC's here at home, all of them are Linux.

Your cock waving has no effect I'm afraid.

> It's not FUD, it's FACT.. I know it from experiance.

If I can restate your premise :

-----
"Every fscking worm/backdoor is allowed to call home"
Simple. Don't use Windows.. That's a Windows problem.
-----

It's not even factual let alone borne of experiance [sic].

It's about a firewall rule. And it sounds like a simple NAT. It doesn't even have anything to do with Operating Systems

>I quit using Windows in August of 2002 and have not had a single worm, virus, trojan, backdoor, hack, sneeze, fart, or burp since..

I've been using Windows since 1987 and have never suffered from any of those things.

> I didn't just fall off of the turnip truck...

Nope, sounds like you stayed right on the top of the pile

** A vulnerability has been discovered in the Linux kernel which can be exploited using the ptrace() system call. By attaching to an incorrectly configured root process, during a specific time window, it may be possible for an attacker to gain superuser privileges.

The problem occurs due to the kernel failing to restrict trace permissions on specific root spawned processes.

This vulnerability affects both the 2.2 and 2.4 Linux kernel trees.

Re:big deal

[pair-a-noyd]

Go ahead and try my box then...

Re:Transparent firewalls - OBSD+PF+BRIDGE

[Anonymous Coward]

Try OpenBSD[1] in Bridge mode - PF[2] on the interfaces. If your tired of the console, add a third (or more) NIC for your logging network - just don't include the NIC in the bridge.
[1] www.openbsd.org
[2] www.benzedrine.cx

Canadians..

[Anonymous Coward]

With all apologies to my Canadian friends (most of whom have laughed when I've told this joke:)
Why do Canadians do it doggie style?

So they can both watch the hockey game.

Again, sorry.