On 8/21/12 8:20 AM, lina wrote: > On Tuesday 21,August,2012 02:52 AM, Joe wrote: >> On Mon, 20 Aug 2012 23:56:42 +0800 >> lina <lina.lastn...@gmail.com> wrote: >> >>> On Monday 20,August,2012 11:45 PM, Mika Suomalainen wrote: >>>> On 20.08.2012 18:38, lina wrote: >>>>>>> How do I know who has this IP address? why s/he didn't change? >>>>>>> >>>>>>> You probably don't. I don't understand this second question. >>>>> The second question is that for those days, the attacker should >>>>> think of renew its ip address. not from the same one. >>>> >>>> But we don't know is the attacker a person or a program, which is >>>> running without knowledge of the owner of computer. >>> Yes, it's more like a program. but the owner in this long period has >>> never shutdown the computer, just a bit surprised that it keeps the >>> same ip address. >>> >>>> >>> >>> >> >> A DHCP client will normally remember its IP address, even if the lease >> has expired, and on the next connection will request it again. If the >> server hasn't issued it to anyone else, it will normally comply with the >> request. Both server and client can be configured not to do this, but >> in a Windows network it will probably happen to avoid too much need for >> scavenging out-of-date DNS records. Assuming the link between DNS and >> DHCP has been set up properly. >> >> Or it may be a configured reservation in the DHCP server i.e. some form >> of server itself. Or the client can be explicitly configured to request >> that address, when it is available, but there's very little reason to >> do that when a reservation is a guaranteed method. >> >> Even if the attacker in this case is a human, it may be difficult or >> impossible to override the network policies. Configuration of >> networking is limited to people with admin credentials, unprivileged >> users cannot even issue a DHCP renewal request other than by rebooting >> the machine. >> >> The quick answer here is to try: host <IP address>, which will turn up >> the hostname of the offending machine if the local DNS server is >> properly set up. Or to at least gain the MAC address of the machine, try >> inserting an iptables rule on your machine to log incoming ssh >> connections. > $ host 172.21.48.161 > Host 161.48.21.172.in-addr.arpa. not found: 3(NXDOMAIN) > > Nmap scan report for 172.21.48.161 > Host is up (0.0021s latency). > Not shown: 991 filtered ports > PORT STATE SERVICE > 80/tcp open http > 135/tcp open msrpc > 139/tcp open netbios-ssn > 443/tcp open https > 445/tcp open microsoft-ds > 515/tcp open printer > 3389/tcp open ms-wbt-server > 5357/tcp open wsdapi > 49154/tcp open unknown > > Thanks, I have drop it in the iptables. [snip]
In general RETURN is more useful than DROP when you have the choice. http://www.chrisbrenton.org/2009/07/why-firewall-reject-rules-are-better-than-firewall-drop-rules/ http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject But since it is a local machine causing the problem, it should be possible to go through the network administrator and contact the owner of the offending machine directly. Regards, /Lars -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50332dd8.5040...@gmail.com
