security primer...
- Thread starter octane
- Start date
I like that one... Covers the basics without too much FUD but still informs about basic misunderstandings, like in the intro, it says: "Unfortunately, this comforting theory overlooks the fact that most of the time, hackers don't try to attack your computer or your network because you are who you are."
However, the article is _wrong_ in one part. It says: "Ideally, your firewall should have DMZ capabilities. A DMZ or de-militarized zone is an area of your network that is isolated from the firewalled computers and that can be connected directly to the internet. This is the place where you will place all your public servers and computers : it is not protected but, in case something goes wrong, the computers that contain your sensitive data are safe."
Why is this wrong? Because you also connect YOUR 'protected' computer to this demilitarised server. You upload and download files, you connect to it using SSH or something else. If this server has been cracked without your knowledge (and the article rightfully mentions that this one is _not_ protected by the firewall), the hacker can use this machine to connect to the other computers or to listen in on what users (like yourself) do on the server. A hacker could even install a trojan on this server that answers your requests instead of, say, the FTP service. It'd say 'hello' to your FTP client, it'd let your client enter user name and password and then either pass this information to the real FTP service or just quit your connection. Then it would write your user name and password to a file the hacker can access. Or it could automatically publish the info to another site where the hacker (or anyone, really) has access to.
I know, I'm adding a little FUD here myself, but I think it's important NOT to hose your security this obviously.
However, the article is _wrong_ in one part. It says: "Ideally, your firewall should have DMZ capabilities. A DMZ or de-militarized zone is an area of your network that is isolated from the firewalled computers and that can be connected directly to the internet. This is the place where you will place all your public servers and computers : it is not protected but, in case something goes wrong, the computers that contain your sensitive data are safe."
Why is this wrong? Because you also connect YOUR 'protected' computer to this demilitarised server. You upload and download files, you connect to it using SSH or something else. If this server has been cracked without your knowledge (and the article rightfully mentions that this one is _not_ protected by the firewall), the hacker can use this machine to connect to the other computers or to listen in on what users (like yourself) do on the server. A hacker could even install a trojan on this server that answers your requests instead of, say, the FTP service. It'd say 'hello' to your FTP client, it'd let your client enter user name and password and then either pass this information to the real FTP service or just quit your connection. Then it would write your user name and password to a file the hacker can access. Or it could automatically publish the info to another site where the hacker (or anyone, really) has access to.
I know, I'm adding a little FUD here myself, but I think it's important NOT to hose your security this obviously.
scruffy
Notorious Olive Counter
If you're going to run a publicly accessible server, then it is very important to put that server in a DMZ, and not in the internal network - for precisely the reasons you state. If you are going to offer public services, then there is a chance your server will be cracked. If this happens, you want your internal desktop computers to still be protected by the firewall, not only from the outside world, but also from your own (now hostile) public servers. That's precisely what a DMZ is for.
A Firewall with a proper DMZ setup will create three isolated areas - the external network, almost completely untrusted; the internal network, pretty much trusted; and the DMZ network, sort of semi-trusted. Then you can define exactly what traffic is allowed where: internal network -> external network is probably mostly OK; external network -> DMZ is mostly not OK, except for one or two services you want to allow; DMZ network -> external or internal network is definitely not OK, and should immediately set off alarms - the servers shouldn't be making outbound connections at all.
So, yes, the most secure setup is not to offer any publicly accessible services at all. But if you _are_ going to offer public services, then your public server(s) had better not be in the same firewall 'zone' as your private computers. You want your firewall to protect the servers as much as possible - only allow access to defined services. But the really important thing is to recognize that even so, your servers might be compromised, and on no account to let them get at the truly important resources that live in other parts of the network.
A Firewall with a proper DMZ setup will create three isolated areas - the external network, almost completely untrusted; the internal network, pretty much trusted; and the DMZ network, sort of semi-trusted. Then you can define exactly what traffic is allowed where: internal network -> external network is probably mostly OK; external network -> DMZ is mostly not OK, except for one or two services you want to allow; DMZ network -> external or internal network is definitely not OK, and should immediately set off alarms - the servers shouldn't be making outbound connections at all.
So, yes, the most secure setup is not to offer any publicly accessible services at all. But if you _are_ going to offer public services, then your public server(s) had better not be in the same firewall 'zone' as your private computers. You want your firewall to protect the servers as much as possible - only allow access to defined services. But the really important thing is to recognize that even so, your servers might be compromised, and on no account to let them get at the truly important resources that live in other parts of the network.
uoba
Re: member
It's great that such talk is within the main macosx.com forum, since if it was pushed into the Network thread, those who run servers out of curiosity or just starting out, would easily miss such vital information. (Hence, don't bounce this thread over there then!)
The more users come to (start-out-with) OSX, the more security issues arise (well, unless we believe that the only people migrating to OS X are Unix geeks
).
The more users come to (start-out-with) OSX, the more security issues arise (well, unless we believe that the only people migrating to OS X are Unix geeks
).
bbloke
Registered
As we're on this sort of topic, some general points are:
1. Don't run any services you won't use
2. Use a firewall
3. Use a virus scanner
4. Sit behind NAT, if you can, and don't have your router respond to pings
5. Don't enable the root account, use sudo (or sudo -s) instead
6. Choose passwords carefully, keep them secret, and ensure they are a good mix of characters
7. Download and install Security Updates promptly
8. If you run services you for which you want to restrict the availability (i.e. not make them totally publicly accessible), edit the /etc/hosts.allow file; this can also be made service-specific ("wrapped").
9. /etc/sshd_config can be edited to only allow certain users remote (ssh) access to your machine, if you don't want all users of your Mac to have the ability to connect remotely.
10. Check for spyware and keystroke loggers using things like MacScan (http://macscan.securemac.com/)
There are probably more points too!
1. Don't run any services you won't use
2. Use a firewall
3. Use a virus scanner
4. Sit behind NAT, if you can, and don't have your router respond to pings
5. Don't enable the root account, use sudo (or sudo -s) instead
6. Choose passwords carefully, keep them secret, and ensure they are a good mix of characters
7. Download and install Security Updates promptly
8. If you run services you for which you want to restrict the availability (i.e. not make them totally publicly accessible), edit the /etc/hosts.allow file; this can also be made service-specific ("wrapped").
9. /etc/sshd_config can be edited to only allow certain users remote (ssh) access to your machine, if you don't want all users of your Mac to have the ability to connect remotely.
10. Check for spyware and keystroke loggers using things like MacScan (http://macscan.securemac.com/)
There are probably more points too!
scruffy
Notorious Olive Counter
K, I'll try. This is good practice for me, since I'm studying this stuff, I need to be able to express it clearly without the technobabble too...
Basically a firewall (a hardware firewall, that is, with multiple network ports, not the software firewall in the OS) lets you define exactly what sort of network traffic to allow, to and from where, filtering both by the physical network port, and by the IP addresses of the messages. Good ones will usually also let you define certain sorts of traffic that will be logged, or generate alarms sent to your e-mail address or whatever.
So, a basic firewall setup looks like this:
Internet --------- Firewall --------- Internal Network
And you'd have rules that allow only for outgoing traffic like:
- allow http requests from the internal network to the internet
- allow e-mail requests from the internal network to the internet
- deny everything else
In practice, a lot of people just allow all outgoing traffic - that's not actually such a good idea, but not really relevant here.
Ideally, for best security, you shouldn't be running any servers - if you do, there's a chance the server will be hacked, since it provides a way of remotely accessing the computer. If the server is hacked, the attacker could not only get information directly from the server, but also use it as a launching point for attacks against your private computers.
If you are going to run servers, you have to keep that in mind. So, not only do you need to defend your private computers and your public servers from the internet, but you also have to be ready to defend your private computers from your public servers. So, if you put your servers on a separate network (i.e. to communicate with the internal computers, the DMZ - server network - has to cross the firewall from one network interface to another), the firewall can restrict that traffic too.
Now you can add another rule or two:
- deny any requests from the DMZ to the internal network, and raise an alarm if they happen.
- deny any requests from the DMZ to the internet, and raise an alarm if they happen
Cause servers have no business making outward connections, so if it happens you know something's up
Basically a firewall (a hardware firewall, that is, with multiple network ports, not the software firewall in the OS) lets you define exactly what sort of network traffic to allow, to and from where, filtering both by the physical network port, and by the IP addresses of the messages. Good ones will usually also let you define certain sorts of traffic that will be logged, or generate alarms sent to your e-mail address or whatever.
So, a basic firewall setup looks like this:
Internet --------- Firewall --------- Internal Network
And you'd have rules that allow only for outgoing traffic like:
- allow http requests from the internal network to the internet
- allow e-mail requests from the internal network to the internet
- deny everything else
In practice, a lot of people just allow all outgoing traffic - that's not actually such a good idea, but not really relevant here.
Ideally, for best security, you shouldn't be running any servers - if you do, there's a chance the server will be hacked, since it provides a way of remotely accessing the computer. If the server is hacked, the attacker could not only get information directly from the server, but also use it as a launching point for attacks against your private computers.
If you are going to run servers, you have to keep that in mind. So, not only do you need to defend your private computers and your public servers from the internet, but you also have to be ready to defend your private computers from your public servers. So, if you put your servers on a separate network (i.e. to communicate with the internal computers, the DMZ - server network - has to cross the firewall from one network interface to another), the firewall can restrict that traffic too.
Code:
Internet --------- Firewall --------- Internal Network
|
|
DMZNow you can add another rule or two:
- deny any requests from the DMZ to the internal network, and raise an alarm if they happen.
- deny any requests from the DMZ to the internet, and raise an alarm if they happen
Cause servers have no business making outward connections, so if it happens you know something's up
If you _read_ the user's post again, you'll see that there is no problem to be solved. At all. Blaming me for a problem that isn't there and afterwards making fun of me is not appreciated on my side. You might notice that there is no winking smiley in this post. (And, yes, I _have_ seen yours, but that doesn't make your post any less offending to me. Stay away from that in the future, please.)