|
|
||
Adding a User and Dial-Up—Day 36© Copyright Darrell Anderson. I’m finally being rewarded by my previous tinkering, side journeys, and exploring. Tinkering, side journeys, and exploring helps one develop system understanding. Understanding how a system functions helps troubleshooting and solving problems. As can be expected, my confidence grow as my explorations continue. I want to keep my primary box as clean as possible and proceed with various aspects only after practicing on my test box. The idea works well, although there are almost always some minor adjustments necessary when I finally try things on my primary box. That is to be expected because the two boxes are not identical nor am I capable of remembering everything I do on my test box. Nonetheless, what a nice feeling that I can make a mess at my test box but migrate that knowledge and experience to my primary box and everything works! I decided I had learned enough playing with user accounts and populating /etc/skel on my test box that I copied my /etc/skel files to my primary box. As I have mentioned, I use removable hard drive bays to swap files. Sure, a network would be nice, but one thing at a time. Swapping hard drives is hardly stressful. I copied those files so I finally could create a mortal user account on my primary box. The only time-consuming problem I encountered after creating that first user was correctly editing fstab so mortal users could mount and use my NT4 partitions. I never encountered this problem on my test box because I have no NT partitions installed there. I do have a FAT32 and MS-DOS partition installed and my test box fstab works fine for both root and mortal users. There are some peculiarities with enabling NT4 support in fstab, but some surfing and trial-and-error finally quieted the matter. Particularly useful in such efforts is the multi-user abilities of ’nix systems. No need for continual reboots! I logged in another X session as root and then toggled to and fro between the two sessions. I would edit fstab, type mount –a, then toggle to mortal user to test my changes. I can only imagine how long this would have taken had I been required to reboot with each change. I needed that first user account to start testing my dial-up. Despite using KDE 3.1.3 in Mandrake 9.2 and KDE 3.3.2 in Slackware, I decided to copy my Mandrake kppprc file rather than configure kppp by hand. There might be some configuration differences, but I hoped nothing serious. The idea seemed to work as kppp offered no error messages when started. However, I got no further than the initial message of trying to login to the network. The hand-shaking never completed. My first response was to try the root account. Sure, from a simple security perspective I doubt I’d connect to the outside world as root, but then again, as long as all ports are closed the danger is minimal. Nonetheless, because the setup is not yet in production I tried the dial-up with the root account. I needed to confirm whether the problem was related to permissions. I experienced the same result so the next thing I did was reboot into Mandrake 9.2. I dialed out with no problems using my normal Mandrake account. While I was online I checked my ports at a the popular testing site www.grc.com. All ports were closed, although the test “failed” because my computer responded to pings and queries. I don’t know much about IPTables, but that will be the only way I’ll be able to stop those problems. The ports were closed, however, and that is most important. I rebooted back into Slackware. Time to do things the old fashioned way: hunt-and-peck. I opened the KPPP dialer and began looking for oddities. I found the problem quickly. Somehow the tool was configured for script-based hand-shaking rather than PAP/CHAP. I don’t know how this changed when all I did was copy the configuration file. Perhaps somewhere from version 3.1.3 to 3.3.2 the configuration order changed of the items in that particular drop-down list. I then dialed out with no problems. I have not yet installed Firefox so I used Konqueror in browser mode. I revisited www.grc.com and was disappointed. Ports 37 and 113 were open! I was unconcerned because I knew what these ports were traditionally for. Port 37 is for time services and port 113 is for identification. Some IRC services use port 113. I don’t use IRC so I wanted that port closed. I could understand Slackware being packaged with port 113 open, but port 37? Odd. The trick now was to discover how those ports were enabled in the first place. I stay connected on the web and hoped that Google would be my friend. Searching the web often is challenging if one fails to supply the magical keywords. Although initially I found several discussions about both ports, I was not finding anything to help me close them. Eventually I did, and the secret was contained in /etc/inetd.conf. Still being new to Slackware I did not know in which file to look, but once I discovered this information I knew I was on my way. All I had to do next was add hash marks (#) to comment out those ports. There were two commands I instinctively tried to use while troubleshooting my open ports: ifconfig and nmap. When I tried the former I received a file not found message. Hmm, I knew that was nonsense! I typed locate ifconfig and found the file in /sbin Hmm. Seems like a path problem. On many systems mortal users are denied access to /sbin commands, but this is my system and my computer. I created a symbolic link to /sbin/ifconfig from within /usr/local/bin. The command is too useful as a troubleshooting tool. I wanted to use nmap to discover other open ports. Although I haven’t used nmap in a long time, the syntax is straightforward: nmap localhost. Nope, wouldn’t work. Hmm. A couple of seconds of thought and I headed to /etc/hosts. After converting my Windows version to ’nix format I had previously copied that file to my Slackware installation. When I went to preview the file I received a permissions problem. Hmm. Then I noticed that permissions were r-------- (400). Odd. How did that happen? So I toggled into a second X session (I’m no command line zealot) and opened the hosts file in Kate. Yup, everything looked okay. Then I changed the permissions to rw-r--r--. Thereafter the command nmap localhost worked fine. I will need to further adjust permissions to that file because I intend to surf exclusively as a mortal user and will need access to modify that one file on-the-fly. Nmap revealed only the two open ports. I knew port 6000 would not be open because I was using the -nolisten tcp option. CUPS was open on port 631 (Internet Printing Protocol) but only internally. I had learned about that potential problem a long time ago and had already edited /etc/cups/cupsd.conf. In the “Listen” section uncomment Listen hostname:631. Overall my dial-up test went well. Nothing unexpected except the two open ports and they are now closed. I would like to learn how to configure IPTables to create a “stealth” response, but I know that closed ports is just as effective. I don’t want to open the never-ending debate about closed vs. stealth ports! I now have my user account. Now I begin the often nutty journey of looking for directory and file permission problems. Finis. |
||