DSL Line Security--What Do I Need to know? 17
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? "
run few services: only sshd, sendmail, httpd (Score:1)
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 all depends... (Score:1)
What should be done to secure linux boxes? (Score:1)
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...
Re:shared files (Score:1)
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).
Macintoshes ought to be safe! (Score:1)
Re:shared files (Score:1)
Re:shared files (Score:1)
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.
Re:What should be done to secure linux boxes? (Score:1)
My only modifications to the script were to add a second subnet and put ip masq stuff in it.
--S
Network layers in consumer DSL (Score:1)
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.
All kinds of problems! (Score:1)
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.
shared files (Score:1)
Re: Which ISP is it? (Score:1)
Re:run few services: only sshd, sendmail, httpd (Score:2)
ALL: 192.168.1.10
in.fingerd: ALL
in.ntalkd : ALL
sshd : ALL
ALL : ALL@ALL : \
rfc931 : \
spawn (
access to %s denied to %c ) : \
spawn (/usr/sbin/safe_finger -l @%h | \
spawn (/usr/sbin/safe_finger abuse@%h | \
DENY
Re:shared files (Score:2)
I've haven't seen Mac networking in a loong time, but in the old days, AppleShare passwords were clear text over the wire unless you used an authentication plug-in. Best bet, however, would be to disable the AppleShare extension, or just make sure you are using AppleTalk rather than TCP/IP. (The DSL bridge will block all non-IP traffic, if I understand correctly.)
Likewise with NT (or Unix/Samba) - if you can't firewall, you probably want to at least disable the filesharing interface on the DSL side (unbind the WINS client in NT).
--
Re:shared files (Score:2)
Well, the DSL 'modem' is actually a bridge, so I guess it's possible that NetBEUI packets could be sent out to the DSL subnet.
I asked my ISP (FirstWorld), and here's the answer I got: "Generally, anything bridged across will be stopped at the terminating end
as we only allow IP traffic from there." (I guess by terminating end, they mean the other end of the DSL line, so you're probably OK.)
--