On Wed, 2005-07-20 at 16:15, Mike McCarty wrote: > Scot L. Harris wrote: > > >On Wed, 2005-07-20 at 14:25, Mike McCarty wrote: > > > > > [what should I do?] > > BTW, should probably have mentioned my setup. I have one (1) > computer running FC2 with a fixed IP address, connected to a > router (D-LINK) set up to accept DHCP connected to a DSL > modem (SPEEDSTREAM 5100) to an ADSL. Good standard setup. > That is a wonderful site. > > Results from scan of ports: 0-1055 > > > 0 Ports Open > 1 Ports Closed > 1055 Ports Stealth > --------------------- > 1056 Ports Tested > > > NO PORTS were found to be OPEN. > > > The port found to be CLOSED was: 113 > > Apparently, 113 is used for some old e-mail query/response. Since > that port is closed, I'm probably ok on that score. > Port 113 is suppose to be used for ident services. RFC 1413 provides the details. This should not be a problem, however your router should stealth this port as well. Have seen this before. Depends on the router implementation. Not sure why they don't stealth that port as well as all the others. The only thing this does is let someone know that there is a machine at your IP address. They can then waste additional time trying to see if there is any other ports open at that address. If port 113 did not respond at all then no one would know there was a computer at your IP address. > How do I check that port? I guess I could just stealth it on my router, > if I poked > around some. Actually, since I'm behind my router, I'm not even really > looking at > my machine. I'm looking at the firewall in my router. > Correct, this is a port that is closed on your firewall, not your computer. To run a full test against your systems you would really need another system on your LAN running nmap or nessus to run a full port scan. > I used the default. The output from iptables is rather long, so I won't > post it here, > but how do I check exactly what is open? The output is a little confusing. > service iptables status should list the current rule set that is running. If you have the default and have not opened any ports then it should be relatively short. One grip I had was in past versions of FC ntp would cut holes in the firewall when it started. Not sure this is still the case or not. I suspect other applications cut their own holes in the firewall also. IMHO this is a bad thing. The firewall should have one place to open up ports and that should be under the admins control. Not some program that happens to get installed and started at boot time. > >Run chkrootkit and rkhunter, setup tripwire and review the reports > >daily. Monitor your log files and check netstat periodically for > >anything strange. > > > > > Hmm, I seem not to have chkrootkit, rkhunter, nor tripwire installed. > Believe you should find these in extras or in the base install. I know tripwire is in extras. > I don't know how to "lock down" iptables, but if no ports are exposed, > how can > anything get in? Except by doing something like overflowing my browser > buffer on a request I make (or email buffer, etc.)? I've got Java and > Javascript > disabled. OTOH, I have heard of "evil" .png problems. I do accept images. > If you have the default iptables rules then things should be blocked from getting in. Additional steps can be taken to have iptables limit what can go out of your system. Only those applications that you use that need network access should be allowed out of the system. Very few people actually take this step. But doing this would likely prevent you from inadvertently downloading some script, png, or executable and running it on your system. Such a piece of code would then establish a connection from inside your network to an IRC channel or some other server where the hacker waits for his payload to call home. He then has a shell on to your system through which additional programs can be downloaded and run possibly allowing escalation of privileges on your system. If your iptables blocks outgoing ports it becomes much more difficult for such code to call home and initiate the next step in compromising your system. > My browser reports that localhost refused the connection. > The find (ghastly idea to search the whole system) did not > find anything, after about 20 minutes. :) But it proved that you did not have that file on your system. :) >From what you have described you are fairly well protected. Just think of security in layers, router/firewall, iptables, selinux, strong passwords, disable services, etc. -- Scot L. Harris webid@xxxxxxxxxx We are not a loved organization, but we are a respected one. -- John Fisher
