Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
The Internet

DSL Line Security--What Do I Need to know? 17

Posted by Cliff from the getting-informed dept.
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? "
This discussion has been archived. No new comments can be posted.

DSL Line Security--What Do I Need to know? More

DSL Line Security--What Do I Need to know?

Comments Filter:
  • 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.
  • 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.
  • After reading the ipchains howto and other faqs, I found a great website for firewalls. There is a "Firewall Design Tool" that helps you build a firewall startup "rc.firewall" script. The site can be found at:

    My only modifications to the script were to add a second subnet and put ip masq stuff in it.
    --S

  • 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
  • Deny everything. Here is an interesting hosts.allow file I have that fingers and logs all denied mischif (I catch a lot of portscans this way:)

    ALL: 192.168.1.10
    in.fingerd: ALL
    in.ntalkd : ALL
    sshd : ALL
    ALL : ALL@ALL : \
    rfc931 : \
    spawn ( /usr/bin/logger -p authpriv.alert -t TCPD \
    access to %s denied to %c ) : \
    spawn (/usr/sbin/safe_finger -l @%h | \
    /usr/bin/logger -p authpriv.alert -t TCPD) :\
    spawn (/usr/sbin/safe_finger abuse@%h | \
    /usr/bin/logger -p authpriv.alert -t TCPD) :\
    DENY

  • Well, it's a Mac, so Samba doesn't figure in, but AppleShareIP volumes might.

    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).
    --

  • 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.)

    --

Slashdot Top Deals

There are two ways to write error-free programs; only the third one works.

Close