Software :: Hardware :: Network/Basic
Network/Advanced :: Security and Users :: System :: Misc ::
Network/Basic
The ADSL module is explicitly used for PPPoE implementations of DSL. This is a fairly common implementation in Europe, and has been catching on with certain ILEC vendors such as SBC in the US as well. PPPoE (RFC 2516) is a method for transmitting point-to-point protocol (PPP) over ethernet. This allows vendors to take advantage of a number of pre-existing utilities for PPP (authentication, for example). The question I've heard muttered more than once is "Here you have a perfectly good ethernet connection, why downgrade your capabilities by embedding PPP inside Ethernet?" That's a paraphrase - the people I heard were much ruder about it. But anyway, this type of DSL connection requires a username and password. Additionally, you need to identify the NIC (usually eth0 in a system with one Ethernet interface). There's a default idle time before disconnect of 60 seconds (the connect time is VERY fast, so usually it's not a problem). The Activate firewall option blocks ALL incoming packets. This may be problematic for such services as IRC, ICQ, AIM, assorted file sharing services, and so on. I'm not sure what's up with Dial on Demand for an ADSL connection, since I was under the illusion that ADSL is an always-available service, not metered by time. I am probably mistaken. Finally, although your system should pick up it's Name Servers at login from the ISP's DHCP server, you can enter the Name Servers manually here if you so desire. They're only available when Dial on Demand is active.
German T-DSL is very similar to the ADSL setup previously described. T-Online is the number one (and possilbly ONLY) service provider in Germany. It's DSL implementation requires some additional configuration fields. Since SuSE is German by origin, it makes sense that it provides a configuration tool for the big local provider. A sideline note: The number two network source of attacks on my servers is T-Online (or rather, it's customers). I give very high marks to the T-Online Abuse Team for their quick responses to my reports of odd activity originating from inside their netblocks.
The module providing Hostname & DNS configuration is simple, yet important. The hostname is the single name by which the computer is known. This is separate from the domain in which the machine exists. Taken together, the hostname and the domain make up a Fully Qualified Domain Name (FQDN), which describes a machines location in the Internet hierarchy (for machines with DNS entries, and routable IP addresses). The FQDN is used within a LAN as well. Usually hostnames are chosen based on some theme or another (norse gods, cyberpunk literature and rock music/artists are popular), and within the limits of policy and configuration, can be almost anything. For the domain name, it should be the domain path to your machine (if you're on a network). Otherwise, it can be virtually anything, but should exist. I've used bogus.com quite often. Below you can configure your DNS servers (If you don't get server information from a DHCP login). The domain search items are a list of domains to which are postfixed onto names prior to searching. So if I were to type ping ghastly, the resolver would first append orbdesigns.com to create ghastly.orbdesigns.com, then query my first nameserver (a local box) to see if that name resolves. It just makes it easier to use hostnames only in a LAN.
Modem Configuration starts off with autodetection of a modem... something I don't have on this system. However, the alternative is Manual Modem Setup. The screen at left shows the modem configuration screen that's used whether for manual or (to the best of my knowledge) automatically configured modems. The device name is a default (in reality it's a link to a serial port file, like /dev/ttyS2 (== COM3)). Dial prefix is usually only needed when getting through a PBX, but it's also handy to reconfig in a laptop when hotel hopping, and the outside line number keeps changing. Standard modem configuration features (tone v. pulse, etc.) round out this module. No, I don't know if they're configured for handling some kinds of so-called WinModems - it appears from the online documentation deep in the SuSE site that they do not.
Start/stop services (inetd) provides service activation and top-level control for services that are monitored by the inetd server. SuSE is a standout in that it hasn't made the transition to the newer xinetd server. Wait, let me backup. inetd and it's newer cousin xinetd provide a wrapper for services that can be offered over the network. For example, instead of the FTP daemon listening on port 21, inetd listens on the port, and starts the server up when service is requested. This has some distinct advantages in memory usage, especially if you have need to provide a number of services, but those are all used sparingly. Additionally, calls to specific services can be monitored by the tcpd access control facility, as demonstrated in the following inetd.conf line. This access is configured by making modifications to /etc/hosts.allow and hosts.deny (type man hosts.allow for more information)
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Returning to our main goal here, sure, we can turn on inetd, but not on "default" terms, without us knowing what's being enabled, neh? So I select On with custom configuration... and click Next. From the image you can see there are at least a few services active by default, none that I'd choose, that's for sure. Things I'll turn off without asking any questions: telnet, login, talk, ntalk and finger. Taking a brief glance at hosts.allow and hosts.deny, I'm glad to shut everything down - it's not secure by my book. Now, looking at the services that are available to run under inetd, I see none that I need right now. I will give them a big bravo for providing choice in FTP servers, with wuFTP, ProFTPd, and the standard ftp server, all protected by tcpd (once configured properly). Mmmm. For the time being, I'll choose the Back button, and change my selection to Off, don't start inetd. I don't need anything there. And a prime rule of administering a box that hppes to be secure is Don't Run Any Services You Don't Use.
ISDN configuration permits setup of auto-detected ISDN expansion cards, or manual selection and configuration of cards if the auto-detect routine fails. Of course, for me it fails, since this VMware setup doesn't provide virtual ISDN cards, so far as I can tell. This is an important configuration option, as ISDN is much more prevalent in Europe than here in the states. The dialog provide card and protocol configuration settings Once the card's setup and theoretically initialized, SuSE provides an extensive (and impressive) list of regional ISPs for ISDN service in it's major markets: the Czech Republic, Germany, the UK and the USA. Once that's selected (if your provider is shown in the list), then you're prompted for the dialup number and user information necessary for connection. Finally, there are provisions for automated dialback, timeouts, firewall, IP settings and more. I'd love to provide more thorough testing of this feature, since SuSE has clearly put a lot of thought into covering all the bases. Input from readers for this section would be appreciated.
The final module in this section is Network card configuration. The radio buttons at the top of the dialog (shown at right) permit switching between interface configuration and hardware configuration. The latter allows selection of the device and number, the kernel driver module (which can be selected from a list in a sub-dialog), as well as setting module parameters if required by your specific hardware. The Interface portion of this YaST2 module is used to set up the IP address and subnet, as well as hostname, nameserver and routing data, just as when configuring the network for the first time during installation (the module is the same).
Software :: Hardware :: Network/Basic
Network/Advanced :: Security and Users :: System :: Misc ::
All Content Copyright © 1999-2001 Brian P. Bilbrey.
This, like all the other ODTL reports, is a purely personal and subjective report of my experiences with the software and/or hardware in question. If you try this at home, your results may match mine exactly. Alternatively, following these steps might make the neighbor boy start sleeping with sheep, cause your toaster oven to become Internet-connected, (then be hacked by some kid in Pasadena who lights your house on fire with it), and finally, may turn your low fat milk sour and chunky just as you raise the carton to your lips. YMMV, Caution Advised.
