I am glad some one asked if the browser is running on the server; I had that thought too. The problem could be something in between the actual client and the server. Additionally, this could be done without using any "malicious software", like a rootkit. Legitimate software could be configured to create this issue. Perhaps your client or server has a IPTables rule that is manipulating the flow of traffic.
You need to look into this from different perspectives. Capture some network traffic, preferably from a tap/span. Then repeat the browsing as you did before. You should also do a full portscan of both systems. You may find an extra, unwanted service running that is not shown in lsof/netstat, etc... Try to rule out the network and client. Perhaps boot a laptop from a live CD, and have it connected to the server via crossover cable, (start TCPDump on the laptop) and repeat the browsing just as before. You have a legitimate issue, you just need to continuously eliminate various possibilities. Also, how did you uninstall the other nginx? Doesn't apt/dpkg leave various files around that were install by a package when removing that package? Like data/conf files? For instance, when they have been modified from what was provided in the .deb? Do you have the other nginx .deb still on disk? On Thu, 2013-09-12 at 09:57 -0700, E Frank Ball III wrote: > On Thu, Sep 12, 2013 at 07:15:57PM +0900, Joel Rees wrote: > > > > > The lynx webrowser shows this as the first line of the webpages: > > > > Local on the machine in question or external? > > external. > > > > > IFRAME: http://122.226.137.123:1111/yixi.exe > > > > > > It also appears in downloads using wget. > > > "view source" in firefox or chrome show nothing amiss. > > External. I figure firefox and chrome discard the new line, since it's > not appropriate before the doctype. > > > > > It only appears on IPv4, not IPv6. > > > > Again, are the browsers local to the machine in question or accessing > > from the network? > > External. > > > > Okay, so, if it isn't something on an external box hijacking the IP > > address of the box in question, it's a local process or set of > > processes hijacking port 80 and trying unsuccessfully to be a > > pass-through proxy. > > Yes. The same as the rootkit in 64-bit squeeze last year. > > > > How much time/resources can you afford to spend on trying to pin the > > intrusion vector down? > > > > Although, I'd hesitate to use the box for anything important, even > > after a complete wipe/install, unless the BIOS can be safely restored > > from a write-protected backup image. And I'd try to be careful enough > > during the install that if the exploit were repeated, I'd notice > > immediately and thus be able to pin the thing more closely. > > > > Maybe build the server as a VM and take snapshots as you go. Or > > rebuild it on a different machine, with the old server reboot from a > > live CD before each major step and use the tools on the live CD to > > take the snapshots. > > > > -- > > Joel Reese > > > This is a KVM virtual machine in a datacenter. No BIOS. I can wait a > few days to rebuild. It's off right now, I'm not going to trust it for > anything. > > > E Frank Ball [email protected] > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/1379016049.25403.43.camel@Void
