2nd loopback interface for security testing on isolated systems?
I have a single computer which I connect to the internet via dialup. I use SuSEfirewall2. I would like to test my security with nmap, satan, cops ect. The problem is it is not realistic to do the test using the loopback interface because I have decided the localhost is safe. There are a number of programs that I have told to bind there open ports to the loopback interface. This means the program allow connections from the localhost but not from the outside world. Sendmail for one: If you turn sendmail entirely off then fetchmail does not work because it delivers mail by dumping it into port 25. But I do not need sendmail to listen to the outside world because I recieve mail via fetchmail, and I do not want to worry about sendmail exploits. Same with appache SuSE's info servers work by running appache. I want to review documention but see not reason to serve the outside world or worry about new appache exploits. So I have told appache to listen by binding to the loopback interface. Also I have told SuSE firewall not to protect from the internal network, and made the loopback interface my connection to the internal network. (I told it to trust itself.) Because of all this the results of an attack thru the loopback interface would not be realistic. I have an idea! Create a 2nd loopback interface, and treat it as an untrusted interface similarly to ppp0! Then I could tell nmap, satan, ect to run its simulated attack thru this new interface! Questions: Is this a good idea? (I only have 1 computer, and cannot run a test from the outside.) How would I implement it? What would be the proper ifconfig, route commands to setup such a test interface? Would there be a large penalty for setting up such an interface and letting it run all the time, so I could do testing any time after installing any new software perhaps? -- Paul Elliott 1(512)837-1096 pelliott@io.com PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117
Hello Paul Elliott, I cannot help you with your question but I want to make one remark: On Fri, Jan 25, 2002 at 02:46:49PM -0600, Paul Elliott wrote:
loopback interface because I have decided the localhost is safe.
Do not rely on localhost being safe. There has been a long discussion on this topic on bugtraq (around Mar 5, 2001, in case you want to look it up). The bottom line was that there are Operating Systems (including -- if I remember correctly -- Linux) which allow external access to the localhost interface. (This is restricted to machines on the same subnet of course, because 127.0.0.1 is not routed.)
world. Sendmail for one: If you turn sendmail entirely off then fetchmail does not work because it delivers mail by dumping it into port 25.
Use the mda option of fetchmail so at least there is no need to have sendmail listening on port 25. HTH Johannes
On Sunday 27 January 2002 20:42, Johannes Geiger wrote:
On Fri, Jan 25, 2002 at 02:46:49PM -0600, Paul Elliott wrote:
loopback interface because I have decided the localhost is safe.
I don't have any bright ideas for testing your firewall, from the same machine, although VM Ware uses dummy IP addresses for communication with hosts, perhaps UML to? The idea would be to run another copy of kernel, as a virtual machine, which communicates with host, over a private network. But can't you filter out packets based on interface -i ppp+ is any PPP interface for example. Then you can have high confidence by connecting to services which will cause packets that you block, for instance ident lookups when you connect to IRC, and querying an NTP or DNS server you will receive UDP response packets that can be logged and blocked.
Do not rely on localhost being safe. There has been a long discussion on this topic on bugtraq (around Mar 5, 2001, in case you want to look it up). The bottom line was that there are Operating Systems (including -- if I remember correctly -- Linux) which allow external access to the localhost interface. (This is restricted to machines on the same subnet of course, because 127.0.0.1 is not routed.)
Shouldn't the kernel rp_filter reject '127.0.0.1' spoofed packets coming in on other interfaces? fetchmail will actually fall back to using /usr/lib/sendmail, so you don't need to run the local SMTP server at all, for incoming email. Rob
participants (3)
-
Johannes Geiger
-
Paul Elliott
-
Robert Davies