Find the answer to your Linux question:
Page 2 of 2 FirstFirst 1 2
Results 11 to 15 of 15
i checked my passwd file, no irregular accounts in there other then the defaults and what i created. i've tried to connect to the port in question via web browser, ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Just Joined!
    Join Date
    Feb 2010
    Posts
    7

    i checked my passwd file, no irregular accounts in there other then the defaults and what i created.

    i've tried to connect to the port in question via web browser, it gets a 404

  2. #12
    Linux Enthusiast scathefire's Avatar
    Join Date
    Jan 2010
    Location
    Western Kentucky
    Posts
    626
    best bet would be to kill apache and scour your configs. they more than likely slipped an include somewhere to reload the program in case the system went down.

  3. #13
    Just Joined!
    Join Date
    Feb 2010
    Posts
    7
    Last night I got a ton of this...

    Feb 1 16:10:23 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:23 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:23 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:23 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:23 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:23 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:24 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:24 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:24 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:24 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:25 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:26 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:26 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53
    Feb 1 16:10:26 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 193.109.81.21#53
    Feb 1 16:10:26 server named[3403]: lame server resolving '102.157.53.206.in-addr.arpa' (in '157.53.206.in-addr.arpa'?): 206.51.26.10#53

    Followed up with a bunch of this....

    Feb 1 23:11:33 server kernel: ip_conntrack: VPS 119: table full, dropping packet.
    Feb 1 23:16:19 server last message repeated 6 times
    Feb 1 23:18:32 server last message repeated 3 times
    Feb 1 23:19:33 server last message repeated 3 times
    Feb 1 23:20:39 server last message repeated 5 times
    Feb 1 23:23:11 server last message repeated 4 times
    Feb 1 23:24:16 server last message repeated 2 times
    Feb 1 23:25:24 server last message repeated 3 times
    Feb 1 23:26:37 server last message repeated 4 times
    Feb 1 23:28:00 server last message repeated 5 times
    Feb 1 23:29:46 server last message repeated 3 times
    Feb 1 23:31:04 server last message repeated 3 times
    Feb 1 23:32:37 server last message repeated 3 times
    Feb 1 23:33:38 server kernel: ip_conntrack: VPS 119: table full, dropping packet.
    Feb 1 23:34:48 server last message repeated 5 times
    Feb 1 23:35:49 server last message repeated 6 times
    Feb 1 23:37:22 server last message repeated 6 times
    Feb 1 23:38:26 server last message repeated 3 times
    Feb 1 23:40:12 server last message repeated 2 times
    Feb 1 23:41:37 server last message repeated 3 times
    Feb 1 23:42:51 server last message repeated 9 times
    Feb 1 23:44:28 server last message repeated 6 times
    Feb 1 23:45:48 server last message repeated 5 times
    Feb 1 23:46:54 server last message repeated 5 times
    Feb 1 23:47:55 server last message repeated 3 times
    Feb 1 23:49:17 server last message repeated 4 times
    Feb 1 23:50:25 server last message repeated 4 times
    Feb 1 23:52:26 server last message repeated 3 times
    Feb 1 23:55:46 server last message repeated 4 times
    Feb 1 23:57:06 server last message repeated 2 times
    Feb 1 23:58:18 server kernel: ip_conntrack: VPS 119: table full, dropping packet.
    Feb 1 23:59:32 server last message repeated 4 times
    Feb 2 00:00:41 server kernel: ip_conntrack: VPS 119: table full, dropping packet.

    wtf does this mean? too many connections? this is very abnormal for my site to get this many connections at this time of night.

    The following command: cat /proc/net/ip_conntrack | wc -l
    Renders this: 51

    Followed by this command: cat /proc/sys/net/ipv4/ip_conntrack_max
    ...and that results with this: 65536

  4. #14
    Linux Enthusiast scathefire's Avatar
    Join Date
    Jan 2010
    Location
    Western Kentucky
    Posts
    626
    are you running a DNS server? the lame server is a server that is not an authoritative server. in other words, your dns server (aka BIND) queried those servers (xxx.xxx.xxx.xxx#53) for DNS resolution. Those two IPs are for Research in Motion, one IP address based in Ontario, the other is for the UK. They are easy enough to find on the internet.

    Its performing a reverse lookup, to the 206.52.157 network, which again, traces to Research in Motion.

    As far as the connection tracking issue, here is what one web site says about it:
    ip_conntrack: table full, dropping packet | Racker Hacker

  5. #15
    Just Joined!
    Join Date
    Aug 2009
    Posts
    83
    - running a 3 year old version of SMF,
    - not running any "early warning" system that could have alerted you of (pending) malicious activity,
    - making changes to the system without properly investigating things.
    Not good.


    Quote Originally Posted by Angersum View Post
    what else can I do?
    What I would suggest is to not focus on any single IP address and counter-measures or spurious log entries but instead create a "more stable" working environment for yourself and focus on the *whole* situation:
    - list all user, process and network information (last; who; \lsof -Pwn; \ps ax -o ppid,pid,uid,cmd; \netstat -anpe) and then
    - shut down all publicly accessible services (except SSH which you need to admin the server with). Listing processes again should show no further PIDs for publicly accessible services.
    - Note process details if any still exist then kill those.
    - Kill off any remote users that are still connected.
    - Raise your firewall to only allow access from and to your management IP (range).
    What I mean is that at this point website accessibility for users is, or should be, of no importance at all: only assessing system integrity is.


    Let's assert for now you can still trust your RPMDB and use it as a way to quickly assess basic file system integrity.
    - Running 'rpm -Vva|grep -v "^\.\{8\}"' will verify known files and only list changed ones for closer inspection.
    - Running 'rpm -qa --dump' should provide you with a list of all files the RPMDB knows about and running 'find / -xdev' the files on the file system. The difference between both results are the files the RMDB doesn't know about and until you have (visually) inspected those (or linked them to a "known good" manual installation) you can mark them as "suspicious".
    - Run all /var/log/ (or other commonly used locations) log files through 'logwatch' with "--range All" and no services disabled. Unless you ran a tight logrotate schedule the Logwatch report can provide you with clues about anything that happened. Especially (failed) recon attempts could be interesting in terms of timeline, entry methods and IP addresses.
    - For additional checks to run see the archived copy of CERT/CC Intruder Detection Checklist.

    If you post back please be as verbose as possible, meaning if you ran any other publicly accessible SW please mention it (anything PHP-based, any "web panel"), if you encounter files at least run 'stat' on them, if you run tools please also list versions and add anything else information-wise you think might help your case.

Page 2 of 2 FirstFirst 1 2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •