http://www.mozy.com/Ralph Shumaker wrote: > James G. Sack (jim) wrote: ..
>... Maybe there's some other place deep in the admin >> interface to keep those from coming through? >> > > I don't know about that. I still cannot access it since disabling those > services. I don't know why, unless those were services being supplied > by the DSL modem to *my* computer. Got any ideas how to get back in? I thought you said it fixed itself? Starting from # ifconfig eth0:0 192.168.1.99 ifconfig -a (to verify the 192.168.1.99 alias) ping 192.168.1.1 if that works, browse to http://192.168.1.1/ > Is this where I should call dslextreme? I'm reluctant to offer advice, since if your admin interface is no longer accessible, it may be my prior suggestion to disable http on the Access Control—Services page that seemed to disable the admin interface. In self-defense, though, I _would_ call that behavior a bug, and maybe that is worth a call to them. If you are bothered by the garbage it seems to be leaking through, another option is to get a cheapie residential gateway and put it between the DSL modem and your computer(s). > >> Here's some other things you may find interesting: .. >> or, if you like wireshark, possibly better is >> wireshark -nr tcpdump.save >> > > No manual entry for wireshark > Hmmm > http://en.wikipedia.org/wiki/Image:Wireshark_screenshot.png > Oh, now *that* looks kewl! It's like my tcpdump formula, but in > progress of accumulation. > > But you used it as a command line. Is that preferable? Not specifically preferable, but it is easier to give a sample command line than to give a gui procedural recipe. OTOH the Wireshark gui does provide some visual context and feedback that may help with setup operations -- possibly making it easier to find the right filter syntax. Wireshark really shines in post-capture data analysis, eg showing "conversations" and relations. The post-capture filters are pretty powerful detective tools for reviewing lengthy capture data. The example I gave before illustrates that both tcpdump and wireshark use the same binary format for saving capture data to file. > > Oh, this is interesting (I wonder if it's actually down or has something > to do with the services that were disabled in my DSL modem which locked > me out of it since I haven't even tried yum since then): > (Creating this prompt on Sat Aug 16 at 10:33:24.) > # yum info wireshark > Loading "fastestmirror" plugin > Loading mirror speeds from cached hostfile > * updates: mirror.stanford.edu > Could not retrieve mirrorlist Nah, that's a (too common) repository problem. Usually temporary. .. >> There's not much you can (easily/safely/reasonably) do about unsolicited >> probes -- those _are_ (typically) the bad guys. Seeing the stats and >> sources is mildly interesting. >> > > OK, if I understand correctly, there's no harm in letting my computer > respond to port probes as long as I have no vulnerable services running? What I meant is that you can't do much about probes arriving at your public IP. That your DSL modem doesn't allow you to filter out those things you don't want is a deficiency of the modem, IMO. I believe your computer may not actually be doing any (real) responding, it should be ignoring them. It would only respond by virtue of running a service whose job is to respond. > > Would there be any harm in having my computer drop all port probes > except for services I want running (like ntp)? Would that even do any > good, as in less visible being less vulnerable (like camouflage, like a > white moth on white tree bark)? If scans of a certain port, say 1026, > on sequential IP addresses is done to merely identify IP addresses that > answer back, wouldn't it be better to *not* answer back? Is that what > iptables is? (man iptables Description doesn't answer this for me, tho, > it probably would if I understood it better). Ahhh, ok, if I understand correctly, you are distinguishing between a policy of REJECT vs DROP. A REJECT is like a negative ack, whereas a DROP returns nothing at all to the sender. Normally firewalls use REJECT on the inside (LAN) and DROP on the outside interface, just so there is less visibility, as you say. For the packets that your DSL modem is allowing through, the response would be dependent on the behavior of your computer, which is probably running iptables. I do believe the default configuration would be to REJECT rather than DROP, so your concern seems justified. I believe if you want to change a default policy to DROP, you may need to add explicit rules for proper behavior of some protocols. Of course you could also add explicit DROP rules for those garbage packets (which makes the most sense to me, if there are only a few). ==> I'm a little rusty, so perhaps someone else will step in with firewall configuration suggestions for your PC. I keep forgetting what OS you are running, but I believe it's some fedora. What do you get for # service iptables status or if that fails, try # iptables -L > > Or should I set up a secure honey pot for them to waste their time on? > Maybe make it look like a juicy whendoze machine that only answers back > something akin to "error reading drive C:". :)) Well, I would not recommend running a honeypot except in a secure(!) dmz, on a sacrificial host, and only if you have quite a bit more expertise than I do. .. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
