DSL Line Security--What Do I Need to know?
Brian Alletto asks:
"I'm getting a DSL line installed in my apartment, with a dynamically allocated IP address, running on my Macintosh (Starmax 5500, MacOS 8.5.1). Are there any IP/DSL security issues I need to be aware of? "
Sorry to get anal, but I believe you mean NetBIOS not NetBEUI. NetBEUI is a non-routable, non-IP transport protocol that can't exist on the Internet. While NetBIOS is a session layer protocol/API that looks after name resolution and the encapsulation of Server Message Blocks (SMB). Also NetBIOS can use just about any transport protocol TCP/IP and NetBEUI included.
True, that's how it's done in Win95/98. In NT you have to disable the WINS Client(TCP/IP) for the interface connected to the Internet. In Network Propeties go to the bindings tab, change 'Show Bindings for' to Adapters, find your Internet interface and disable WINS Client listed underneath it.
However this can cause some problems if you need to use DHCP (DHCP needs WINS for some reason). In this case disable all services beneath WINS Client (NetBIOS, Workstation & Server) but leave WINS Client enabled.
If you use the same interface to connect to your LAN you will now find that you're not able to connect to resources on other computers. In this case I would add a second protocol for file and print sharing, like NetBEUI since it's not an Internet protocol and won't broadcast your shares to the world.
There are many things that can be done but I found that doing a simple thing like unbinding NetBIOS stops the script kiddies cold.
Same AC as above
If you're connecting a unix box to the Internet:
Run as few IP server services as possible. A good bet is: sshd, sendmail and httpd.
Don't run telnetd, ftpd, popd, imapd, or anything else that sends passwords in the clear.
Use appropriate conf files to restrict ssh access if possible.
Make sure you're running recent versions of sendmail, majordomo, etc.
Be paranoid. Configure your machine to send you email at the first sign of trouble. (Newer versions of FreeBSD do this out of the box; don't know about LiGNUx.)
It depends on the level of firewalling your ISP is going to provide. Some will block many of the DoS attacks such as smurf. Another question is how many PC's you are going to have connected - if you have more than 1 (like 3 all connected to a hub, where the DSL connection comes in) a smurf attack could bring that whole network to a halt. If you can afford a firewall put that before your network, otherwise there are probably some low-cost software firewalls for macintosh that you can use.
--onyx--
In the same DSL case?
Is a firewall the best solution? best security tips?
I'm thinking about getting DSL too, and have been wondering exactly the same thing, but sadly(?), i have no macs to worry about...
Well, that comment about Samba needs to be clarified. Many Mac users use Thursby's DAVE app, which is a CIFS client/server, so Samba shares *could* be an issue.
Also, by-the-by, AppleShare passwords are two way encrypted by default now (as of system 8.x, I believe, but certainly in 8.5 and later).
Hi.. a macintosh ought to be relatively safe from attacks. Most single-user operating systems are safe from destructive attacks- all you'd have to watch out for are denial-of-service attacks. Some of these, the IP stack is responsible for (bugtraq has had several 95/98/98se/2k exploits floating around recently), but some (smurf), you will lose the connection until it's over. Fortunately, though, DOS attacks oughtn't cause local data ruination; only connection-issues.
What ISP is that? All things considered, your friend should be getting a routed connection with a small subnet, which should, in effect, trash NetBEUI connections since they tend to hate working over multiple subnets. That is, unless you manually stick machine names in lmhosts...
True.
In fact, we had this same problem when we wired our ethernet thru fiber to campus. Bunches of script kiddies started leeching off of us. Here's the fix.
In the TCP/IP properties, make sure file/printer sharing is not bound. That is, under the bindings tab in the TCP/IP properties, uncheck the box next to file/print sharing and then reboot. Bam. No more broadcasting your shares out to the whole TCP/IP world.
Of course, that assumes your DSL blocks NetBEUI, which makes sense since it's non-routable.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
DSL is broadband ATM over the phone line. ATM operates at ISO layer 2, the data link layer. So the same security issues apply as would apply to an untrusted ethernet connection.
When you turn your DSL router on (or load the DSL driver for an internal DSL modem), the ATM connection is established to the TelCo's ATM switch. This basically involves an ATM synchronisation, which due to the nature of ATM may take a while (there is only one framing bit between each 53-byte cell!).
The Layer 3 (IP) connection is then set up over this ATM connection. This may be connection based or packet based, but is almost always connection based. Additionally, the actual routing of your IP that you "use" might be tunnelled over this link to your ISP.
In short, what all this means is that whether or not someone on the same subnet as you can get to your machine is dependant upon how the TelCo has set up their ATM switches and routers.
I have an xDSL connection to my TelCo (NZ Telecom), and the Nokia M10 router I have uses NAT and a tunnelled connection to the ISP (XTRA, a tightly coupled company) PPP server. My machine talks to a NAT interface 192.168.1.254/24, which gets translated to the external address (hydro.gen.nz), encapsulated over the IP link to the ISP (which uses the address range 172.30.254.1/16 to 172.30.1.1/16), which in turn is encapsulated over ATM and sent to the TelCo.
The router, by default, refuses all inbound connections, but incoming holes can be defined. I also use Linux 2.0 IP filtering and masquerading to provide IP service to the internal machines.
So in order to get to a port that I have not explicitly defined a rule for from outside (the M10 calls these "pinholes"), two layers must be breached - the Nokia M10 IP NAT and the Linux IP filtering. This gives a double layer of protection (two IP stacks from different vendors), at the expense of losing the ability to use call-back protocols that the M10 does not know about (like some IRC commands and ICQ, but standard mode FTP does work.).
I recommend this setup, as it delivers a very high level of security. If you don't allow any holes through the M10 and also filter incoming connections on the Linux box, the system is virtually inpenetrable.
If your provider isnt' filtering or routing right then you are basically on a network bridge, it will be just as if your computer were directly plugged into your providers hub.
This means
1) you can see other peoples network shares, and they can see yours.
2) you can use a packet sniffer to spy on others, probably including your ISP if they are that stupid, and others can do the same to you.
3) you will be open to more attacks since some really are only effective at high speeds. But it will raise your connection speed margin compared to the rest of the world, so it will be harder for people to simply flood you out.
just a warning, on my friend's dsl, the MS networking file shares are availible to other dsl users in his area, (under windows at least) so i'm guessing that samba shares would be too. i didn't notice if he was using virtuall private networking or not, but just thought i should let you know that.
the isp is visi.com with US West DSL service, Minneapolis/St. Paul area