View previous topic :: View next topic |
Author |
Message |
mattwood2000 Tux's lil' helper
Joined: 13 Apr 2005 Posts: 146
|
Posted: Fri Oct 02, 2009 8:23 pm Post subject: Have I been hacked??!! |
|
|
Hi guys, I run a Gentoo server on my home network - it acts as the bridge between my FiOS router and the rest of my network - it provides DHCP for the intranet and SSH access both on the WAN and LAN using public key authentication on a upper port.
I came home this afternoon and noticed my work computer had lost its exchange connection...which sometimes happens, so I didnt think much of it. I released and renewed the IP address, but the connection did not restore. I then did the usual debugging steps - ping and hostname, ping and IP, etc. Nothing was working so I tried to log into my server normally via SSH, but to my surprise, my key was refused!
I ran nmap on my external dnydns hostname and my internal server IP and got this strange output:
Code: |
Interesting ports on 192.168.0.1:
Not shown: 986 filtered ports
PORT STATE SERVICE
17/tcp closed qotd
21/tcp closed ftp
22/tcp closed ssh
23/tcp closed telnet
25/tcp closed smtp
80/tcp closed http
110/tcp closed pop3
143/tcp closed imap
256/tcp closed fw1-secureremote
264/tcp closed bgmp
443/tcp closed https
1080/tcp closed socks
1723/tcp closed pptp
10000/tcp closed snet-sensor-mgmt
|
Definitely not stuff I'm normally running! I tried logging in via SSH from two separate computers using my public key stored on my thumb drive...no go! So in a panic I went into the basement and stupidly rebooted the computer. Back upstairs, I released and renewed the IP address and tried logging in again, and still no go! So I brought my monitor downstairs and logged in. Nothing seemed out of the ordinary. My lastlog didn't show anything strange. I had some remote login's but nothing I can't verify.
When I went back upstairs I tried logging in again, and this time I was able to do so via SSH. When I did another nmap, I got my usual output:
Code: |
Interesting ports on 192.168.0.1:
Not shown: 997 closed ports
PORT STATE SERVICE
53/tcp open domain
139/tcp open netbios-ssn
445/tcp open microsoft-ds
|
Any ideas? Is my paranoia warranted? |
|
Back to top |
|
|
cazort Guru
Joined: 19 Sep 2004 Posts: 343 Location: Lancaster, PA
|
Posted: Fri Oct 02, 2009 8:49 pm Post subject: |
|
|
These results strike me as really weird and would raise some suspicions.
Did you run nmap with the exact same command line, in each case? I notice that the remainder of the ports are reported as "filtered" in one case but "closed" in the other. In some cases, though, this can be an artifact of running a "half-open scan", because this can't detect the difference between a filtered and closed port.
If you ran nmap the same way and got different results, and the ports were really being filtered on the box when it was not doing what you expected...and you had not set up the box to filter the ports, then...it's a sign someone may have set up their own firewall on the box (and was sloppy in that they set it up differently from yours which allowed you to see the difference you specified).
The response in the first case does not mean that the box was actually running those services...but it's weird that those ports are "closed" whereas the others are filtered.
---
What was the level of security on this machine? How many services were running on it? How diligent were you about security on it? I had a gentoo box on the open internet for years and it was constantly under attack by automated scripts, but I never had any trouble because I was moderately paranoid about how I set it up. If you compile with pie, the worst that will usually happen with buffer-overflow attacks is crashing your box or usually just some service on it. _________________ Alex Zorach | Teacology | RateTea | Why This Way |
|
Back to top |
|
|
mattwood2000 Tux's lil' helper
Joined: 13 Apr 2005 Posts: 146
|
Posted: Fri Oct 02, 2009 8:59 pm Post subject: |
|
|
Hi cazort, I also found these strange addresses in my /var/log/messages log right after my reboot
Code: |
Oct 2 15:51:20 woody-server named[2624]: network unreachable resolving 'cmtu.mt.ns.els-gms.att.net/AAAA/IN': 2001:503:ba3e::2:30#53
Oct 2 15:51:21 woody-server named[2624]: network unreachable resolving 'cmtu.mt.ns.els-gms.att.net/AAAA/IN': 2001:503:231d::2:30#53
Oct 2 15:51:23 woody-server named[2624]: network unreachable resolving 'cmtu.mt.ns.els-gms.att.net/AAAA/IN': 2001:503:a83e::2:30#53
Oct 2 15:51:24 woody-server named[2624]: network unreachable resolving 'cbru.br.ns.els-gms.att.net/AAAA/IN': 2001:503:a83e::2:30#53
Oct 2 15:51:25 woody-server named[2624]: network unreachable resolving 'cbru.br.ns.els-gms.att.net/AAAA/IN': 2001:503:231d::2:30#53
Oct 2 15:51:29 woody-server named[2624]: network unreachable resolving 'xbru.br.ns.els-gms.att.net/A/IN': 2001:503:a83e::2:30#53
Oct 2 15:51:30 woody-server named[2624]: success resolving 'xbru.br.ns.els-gms.att.net/A' (in 'att.NET'?) after disabling EDNS
Oct 2 15:51:32 woody-server named[2624]: success resolving 'cmtu.mt.ns.els-gms.att.net/AAAA' (in 'att.NET'?) after reducing the advertised EDNS UDP packet size to 512 octets
Oct 2 15:51:38 woody-server named[2624]: success resolving 'cbru.br.ns.els-gms.att.net/AAAA' (in 'att.NET'?) after reducing the advertised EDNS UDP packet size to 512 octets
|
To answer your question, I used the exact same nmap command - "nmap -sS ip_address".
I'm pretty good with security or at least I thought...although I might have made the cardinal mistake by always logging in as root...I don't login as any other user since most of what I do requires root privileges anyway.
I recently started to setup apache2 and subversion for web access to repos's, but I never finished and apache2 isn't in the default runlevel, but I can't remember if I left it running the last time I was working on it...maybe a bad setup might have allowed access somehow (with recent useradd additions)?
*edit*
I guess these lines in my /var/log/messages aren't that suspicious...bind is doing what its supposed to do, but for some reason couldnt resolve those...althought, I don't think I had any web pages open or connections going to those addresses, so these could be suspect. |
|
Back to top |
|
|
user124 Tux's lil' helper
Joined: 02 May 2002 Posts: 86
|
Posted: Sat Oct 03, 2009 5:56 pm Post subject: Re: Have I been hacked??!! |
|
|
mattwood2000 wrote: |
I ran nmap on my external dnydns hostname and my internal server IP and got this strange output:
|
might it be possible that your dyndns provider returned your old ip? |
|
Back to top |
|
|
mattwood2000 Tux's lil' helper
Joined: 13 Apr 2005 Posts: 146
|
Posted: Sat Oct 03, 2009 7:23 pm Post subject: |
|
|
I thought about an IP conflict, but I ruled that out when I nmap'ed my internal IP 192.168.0.1 which I have bind/dhcpd running on and still got the same strange port listing. |
|
Back to top |
|
|
mattwood2000 Tux's lil' helper
Joined: 13 Apr 2005 Posts: 146
|
Posted: Tue Oct 06, 2009 12:06 am Post subject: |
|
|
Ok got an update on this. I found the strange ports open again when I nmaped my network this evening. So this time I controlled my fit of rage and didnt reset the server or anything. I brought the monitor down and logged in as root.
I ran "who" which showed only myself logged in. My lastlog did not show anything out of the ordinary either. I ran iptraf and logged what was going on and found a bunch of activity on 169.254.1.xxx addresses. I've attached the logfile to this post. Is this activity normal?
I tried a couple of the random addresses - especially ones close to the end of the log and there was some strange facebook crap. http://69.63.176.170/ showed "I'll find something to put here." but tracert traced it back to the facebook domain. As far as I know none of my computers were on facebook...I asked other people in the house and no one was on facebook at the time this went down...strange.
Also what I found strange was that if I ran "nmap -sS localhost" or "nmap -sS 192.168.0.1" from the server itself, the normal port listing showed up. Only from other computers on my network which had IP addresses assigned to them by the server did I see the strange port listing.
After rebooting the server, the same addresses were still there. I also rebooted the FiOS router and still the same addresses. Then just like that, I was able to log in again via ssh and the strange ports disappeared!
Something is definitely messed up.
Any suggestions?
Thanks, Matt.
Code: |
Mon Oct 5 19:26:53 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.188; echo req
Mon Oct 5 19:26:53 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.191; echo req
Mon Oct 5 19:26:53 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.192; echo req
Mon Oct 5 19:26:53 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.193; echo req
Mon Oct 5 19:26:53 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.196; echo req
Mon Oct 5 19:26:53 2009; UDP; eth0; 46 bytes; from 169.254.1.185:51413 to 169.254.1.255:5000
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.149; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.152; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.153; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.156; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.157; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.158; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.161; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.162; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.163; echo req
Mon Oct 5 19:26:54 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.166; echo req
Mon Oct 5 19:26:54 2009; UDP; eth0; 56 bytes; from 169.254.1.185:7500 to 169.254.1.255:7500
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.209; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.212; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.213; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.216; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.217; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.218; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.221; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.222; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.223; echo req
Mon Oct 5 19:26:55 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.226; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.179; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.182; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.183; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.186; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.187; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.188; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.191; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.192; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.193; echo req
Mon Oct 5 19:26:56 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.196; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.239; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.242; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.243; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.246; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.247; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.248; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.251; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.252; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.253; echo req
Mon Oct 5 19:26:57 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.0; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.209; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.212; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.213; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.216; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.217; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.218; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.221; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.222; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.223; echo req
Mon Oct 5 19:26:58 2009; ICMP; eth0; 28 bytes; from 192.168.1.7 to 169.254.1.226; echo req
Mon Oct 5 19:26:59 2009; TCP; eth0; 44 bytes; from 192.168.1.7:35285 to 169.254.1.13:443; first packet (SYN)
Mon Oct 5 19:26:59 2009; TCP; eth0; 44 bytes; from 192.168.1.7:35285 to 169.254.1.16:443; first packet (SYN)
Mon Oct 5 19:26:59 2009; TCP; eth0; 44 bytes; from 192.168.1.7:35285 to 169.254.1.17:443; first packet (SYN)
Mon Oct 5 19:26:59 2009; TCP; eth0; 44 bytes; from 192.168.1.7:35285 to 169.254.1.20:443; first packet (SYN)
Mon Oct 5 19:26:59 2009; TCP; eth0; 44 bytes; from 192.168.1.7:35285 to 169.254.1.21:443; first packet (SYN)
Mon Oct 5 19:26:59 2009; TCP; eth0; 44 bytes; from 192.168.1.7:35285 to 169.254.1.22:443; first packet (SYN)
...
...
...
Mon Oct 5 19:29:58 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.240; timestmp req
Mon Oct 5 19:29:58 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.69:80; first packet
Mon Oct 5 19:29:58 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.126:80; first packet
Mon Oct 5 19:29:58 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.148; timestmp req
Mon Oct 5 19:29:58 2009; TCP; eth0; 44 bytes; from 192.168.1.7:35286 to 169.254.1.173:443; first packet (SYN)
Mon Oct 5 19:29:58 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.185; timestmp req
Mon Oct 5 19:29:58 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.203:80; first packet
Mon Oct 5 19:29:58 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35285 to 169.254.1.208:80; first packet
Mon Oct 5 19:29:59 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.55:80; first packet
Mon Oct 5 19:29:59 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.101; timestmp req
Mon Oct 5 19:29:59 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35285 to 169.254.1.119:80; first packet
Mon Oct 5 19:29:59 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35285 to 169.254.1.164:80; first packet
Mon Oct 5 19:29:59 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35285 to 169.254.1.181:80; first packet
Mon Oct 5 19:29:59 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.203; timestmp req
Mon Oct 5 19:29:59 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.216; timestmp req
Mon Oct 5 19:29:59 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.119; timestmp req
Mon Oct 5 19:29:59 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.126; timestmp req
Mon Oct 5 19:29:59 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.208:80; first packet
Mon Oct 5 19:30:00 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.205; timestmp req
Mon Oct 5 19:30:00 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.101; timestmp req
Mon Oct 5 19:30:00 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.119:80; first packet
Mon Oct 5 19:30:00 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.164:80; first packet
Mon Oct 5 19:30:00 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.181:80; first packet
Mon Oct 5 19:30:00 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.203; timestmp req
Mon Oct 5 19:30:00 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.216; timestmp req
Mon Oct 5 19:30:00 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.119; timestmp req
Mon Oct 5 19:30:00 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.126; timestmp req
Mon Oct 5 19:30:00 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.208; timestmp req
Mon Oct 5 19:30:00 2009; UDP; eth0; 46 bytes; from 169.254.1.253:46779 to 169.254.1.255:5000
Mon Oct 5 19:30:00 2009; UDP; eth1; 328 bytes; from 0.0.0.0:68 to 255.255.255.255:67
Mon Oct 5 19:30:01 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.205; timestmp req
Mon Oct 5 19:30:01 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.164; timestmp req
Mon Oct 5 19:30:01 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35285 to 169.254.1.173:80; first packet
Mon Oct 5 19:30:01 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.55; timestmp req
Mon Oct 5 19:30:01 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.173; timestmp req
Mon Oct 5 19:30:01 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35285 to 169.254.1.178:80; first packet
Mon Oct 5 19:30:01 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.69; timestmp req
Mon Oct 5 19:30:01 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.178; timestmp req
Mon Oct 5 19:30:01 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.181; timestmp req
Mon Oct 5 19:30:01 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.208; timestmp req
Mon Oct 5 19:30:01 2009; UDP; eth1; 59 bytes; from 192.168.0.47:63761 to 192.168.0.1:53
Mon Oct 5 19:30:01 2009; UDP; eth0; 70 bytes; from 192.168.1.7:23896 to 71.250.0.12:53
Mon Oct 5 19:30:01 2009; UDP; eth0; 124 bytes; from 71.250.0.12:53 to 192.168.1.7:23896
Mon Oct 5 19:30:01 2009; UDP; eth0; 81 bytes; from 192.168.1.7:1134 to 71.250.0.12:53
Mon Oct 5 19:30:01 2009; UDP; eth0; 97 bytes; from 71.250.0.12:53 to 192.168.1.7:1134
Mon Oct 5 19:30:01 2009; UDP; eth1; 533 bytes; from 192.168.0.1:53 to 192.168.0.47:63761
Mon Oct 5 19:30:02 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.164; timestmp req
Mon Oct 5 19:30:02 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.173:80; first packet
Mon Oct 5 19:30:02 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.55; timestmp req
Mon Oct 5 19:30:02 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.173; timestmp req
Mon Oct 5 19:30:02 2009; TCP; eth0; 40 bytes; from 192.168.1.7:35286 to 169.254.1.178:80; first packet
Mon Oct 5 19:30:02 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.69; timestmp req
Mon Oct 5 19:30:02 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.178; timestmp req
Mon Oct 5 19:30:02 2009; ICMP; eth0; 40 bytes; from 192.168.1.7 to 169.254.1.181; timestmp req
Mon Oct 5 19:30:05 2009; UDP; eth0; 56 bytes; from 169.254.1.185:7500 to 169.254.1.255:7500
Mon Oct 5 19:30:05 2009; UDP; eth1; 70 bytes; from 192.168.0.47:63118 to 192.168.0.1:53
Mon Oct 5 19:30:05 2009; UDP; eth0; 81 bytes; from 192.168.1.7:10459 to 71.250.0.12:53
Mon Oct 5 19:30:05 2009; UDP; eth0; 97 bytes; from 71.250.0.12:53 to 192.168.1.7:10459
Mon Oct 5 19:30:05 2009; UDP; eth1; 310 bytes; from 192.168.0.1:53 to 192.168.0.47:63118
Mon Oct 5 19:30:05 2009; TCP; eth1; 64 bytes; from 192.168.0.47:49342 to 69.63.176.170:80; first packet (SYN)
Mon Oct 5 19:30:05 2009; TCP; eth0; 64 bytes; from 192.168.1.7:49342 to 69.63.176.170:80; first packet (SYN)
Mon Oct 5 19:30:05 2009; TCP; eth0; 46 bytes; from 69.63.176.170:80 to 192.168.1.7:49342; first packet (SYN)
Mon Oct 5 19:30:05 2009; TCP; eth1; 44 bytes; from 69.63.176.170:80 to 192.168.0.47:49342; first packet (SYN)
Mon Oct 5 19:30:05 2009; TCP; eth0; 46 bytes; from 69.63.176.170:80 to 192.168.1.7:49342; FIN sent; 5 packets, 427 bytes, avg flow rate 0.00 kbytes/s
Mon Oct 5 19:30:05 2009; TCP; eth1; 40 bytes; from 69.63.176.170:80 to 192.168.0.47:49342; FIN sent; 5 packets, 413 bytes, avg flow rate 0.00 kbytes/s
Mon Oct 5 19:30:05 2009; TCP; eth1; 46 bytes; from 192.168.0.47:49342 to 69.63.176.170:80; FIN acknowleged
Mon Oct 5 19:30:05 2009; TCP; eth0; 40 bytes; from 192.168.1.7:49342 to 69.63.176.170:80; FIN acknowleged
Mon Oct 5 19:30:05 2009; TCP; eth1; 46 bytes; from 192.168.0.47:49342 to 69.63.176.170:80; FIN sent; 7 packets, 651 bytes, avg flow rate 0.00 kbytes/s
Mon Oct 5 19:30:05 2009; TCP; eth0; 40 bytes; from 192.168.1.7:49342 to 69.63.176.170:80; FIN sent; 7 packets, 621 bytes, avg flow rate 0.00 kbytes/s
Mon Oct 5 19:30:05 2009; UDP; eth1; 62 bytes; from 192.168.0.47:62629 to 192.168.0.1:53
Mon Oct 5 19:30:05 2009; UDP; eth0; 73 bytes; from 192.168.1.7:36108 to 71.250.0.12:53
Mon Oct 5 19:30:05 2009; UDP; eth0; 89 bytes; from 71.250.0.12:53 to 192.168.1.7:36108
Mon Oct 5 19:30:05 2009; UDP; eth1; 302 bytes; from 192.168.0.1:53 to 192.168.0.47:62629
Mon Oct 5 19:30:05 2009; TCP; eth1; 64 bytes; from 192.168.0.47:49343 to 69.63.180.23:80; first packet (SYN)
Mon Oct 5 19:30:05 2009; TCP; eth0; 64 bytes; from 192.168.1.7:49343 to 69.63.180.23:80; first packet (SYN)
Mon Oct 5 19:30:05 2009; TCP; eth0; 46 bytes; from 69.63.176.170:80 to 192.168.1.7:49342; first packet
Mon Oct 5 19:30:05 2009; TCP; eth1; 40 bytes; from 69.63.176.170:80 to 192.168.0.47:49342; first packet
Mon Oct 5 19:30:05 2009; TCP; eth0; 64 bytes; from 69.63.180.23:80 to 192.168.1.7:49343; first packet (SYN)
Mon Oct 5 19:30:05 2009; TCP; eth1; 64 bytes; from 69.63.180.23:80 to 192.168.0.47:49343; first packet (SYN)
Mon Oct 5 19:30:06 2009; UDP; eth0; 1500 bytes; from 169.254.1.185:21302 to 255.255.255.255:21302
Mon Oct 5 19:30:06 2009; UDP; eth0; 416 bytes; from 169.254.1.185 to 255.255.255.255; fragment
Mon Oct 5 19:30:06 2009; UDP; eth0; 46 bytes; from 169.254.1.141:5056 to 169.254.1.255:5000
Mon Oct 5 19:30:06 2009; TCP; eth1; 64 bytes; from 192.168.0.47:49344 to 69.63.176.170:80; first packet (SYN)
Mon Oct 5 19:30:06 2009; TCP; eth0; 64 bytes; from 192.168.1.7:49344 to 69.63.176.170:80; first packet (SYN)
Mon Oct 5 19:30:06 2009; UDP; eth0; 46 bytes; from 169.254.1.88:5056 to 169.254.1.255:5000
Mon Oct 5 19:30:06 2009; TCP; eth0; 46 bytes; from 69.63.176.170:80 to 192.168.1.7:49344; first packet (SYN)
Mon Oct 5 19:30:06 2009; TCP; eth1; 44 bytes; from 69.63.176.170:80 to 192.168.0.47:49344; first packet (SYN)
Mon Oct 5 19:30:09 2009; TCP; eth1; 52 bytes; from 192.168.0.47:49343 to 69.63.180.23:80; FIN sent; 6 packets, 1604 bytes, avg flow rate 0.25 kbytes/s
Mon Oct 5 19:30:09 2009; TCP; eth0; 52 bytes; from 192.168.1.7:49343 to 69.63.180.23:80; FIN sent; 6 packets, 1604 bytes, avg flow rate 0.25 kbytes/s
Mon Oct 5 19:30:09 2009; UDP; eth0; 46 bytes; from 169.254.1.185:51413 to 169.254.1.255:5000
Mon Oct 5 19:30:09 2009; TCP; eth0; 52 bytes; from 69.63.180.23:80 to 192.168.1.7:49343; FIN acknowleged
Mon Oct 5 19:30:09 2009; TCP; eth1; 52 bytes; from 69.63.180.23:80 to 192.168.0.47:49343; FIN acknowleged
Mon Oct 5 19:30:09 2009; TCP; eth0; 52 bytes; from 69.63.180.23:80 to 192.168.1.7:49343; FIN sent; 5 packets, 1025 bytes, avg flow rate 0.25 kbytes/s
Mon Oct 5 19:30:09 2009; TCP; eth1; 52 bytes; from 69.63.180.23:80 to 192.168.0.47:49343; FIN sent; 5 packets, 1025 bytes, avg flow rate 0.25 kbytes/s
Mon Oct 5 19:30:09 2009; TCP; eth1; 52 bytes; from 192.168.0.47:49343 to 69.63.180.23:80; FIN acknowleged
Mon Oct 5 19:30:09 2009; TCP; eth0; 52 bytes; from 192.168.1.7:49343 to 69.63.180.23:80; FIN acknowleged
Mon Oct 5 19:30:10 2009; TCP; eth1; 46 bytes; from 192.168.0.47:49344 to 69.63.176.170:80; FIN sent; 4 packets, 513 bytes, avg flow rate 0.00 kbytes/s
Mon Oct 5 19:30:10 2009; TCP; eth0; 40 bytes; from 192.168.1.7:49344 to 69.63.176.170:80; FIN sent; 4 packets, 501 bytes, avg flow rate 0.00 kbytes/s
Mon Oct 5 19:30:10 2009; TCP; eth0; 46 bytes; from 69.63.176.170:80 to 192.168.1.7:49344; FIN acknowleged
Mon Oct 5 19:30:10 2009; TCP; eth1; 40 bytes; from 69.63.176.170:80 to 192.168.0.47:49344; FIN acknowleged
Mon Oct 5 19:30:15 2009; UDP; eth0; 46 bytes; from 169.254.1.253:46779 to 169.254.1.255:5000
Mon Oct 5 19:30:15 2009; UDP; eth0; 56 bytes; from 169.254.1.185:7500 to 169.254.1.255:7500
Mon Oct 5 19:30:16 2009; ******** IP traffic monitor stopped ********
|
|
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Tue Oct 06, 2009 12:50 am Post subject: |
|
|
Keeping a hacked box online is being accessory to a crime. You can investigate it by booting from some good CD but you have to take it offline immediately. In any case, in *NIX world there is no such thing as "fixing a hacked computer", only fresh clean install will do. |
|
Back to top |
|
|
mattwood2000 Tux's lil' helper
Joined: 13 Apr 2005 Posts: 146
|
Posted: Tue Oct 06, 2009 1:15 am Post subject: |
|
|
Hi Jaglover...thats why I've already taken it off line...I wanted to see if it was a fluke or not. Now its offline....and yes there will be a fresh install happening along with a complete change of passwords, etc. My question, though is does the log file indicate a hacked box at all? What traffic should I look out for. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Tue Oct 06, 2009 12:49 pm Post subject: |
|
|
Well, there is literally nothing you can trust in this computer. For instance, ps command will not show pirate processes and so on. This is why you need to investigate it (or just the HDD) using some clean OS. Common places to look at are root command history and other log files. Basically, imagine you are a hacker and you just broke into a remote computer. You got root shell, what's your next task? Download your toolkit, naturally. So look for any traces of downloading, unpacking and executing such a toolkit. However, a highly qualified blackhat may leave no traces at all.
rkhunter may find something.
Checking files against a remote AIDE database will definitely tell the truth. Assuming you created one in the first place.
Another thing, how comes your firewall did not block opening those ports? Did this cracker hack your firewall too? Or you didn't have one? From description of your setup I take this FiOS box is not a router, it's just passing the public IP address to your Gentoo router. This means your Gentoo box is directly exposed to the internet. You cannot run a Linux computer without a well configured firewall when exposed directly to the internet. I'd consider using hardened Gentoo as well. |
|
Back to top |
|
|
Anarcho Advocate
Joined: 06 Jun 2004 Posts: 2970 Location: Germany
|
Posted: Tue Oct 06, 2009 1:11 pm Post subject: |
|
|
Jaglover wrote: | You cannot run a Linux computer without a well configured firewall when exposed directly to the internet. |
At least for this sentence I must disagree. A firewall is not needed if only services are running that are supposed to listen on the WAN interface and if other services are correctly configured.
You don't need to configure a firewall to disallow connections on ports where no program is listen to. Every other port must be opened in the firewall so there is no benefit.
Even worse, a firewall (or in most cases a packet filter) may be vulnerable itself.
My root servers have no firewall running as each and every service they run has to be reached world-wide through the internet. No other service is running.
What is really strange is the filtered ports with some open ones. The difference between a closed port and a filtered port is that for the closed port the kernel answers with the appropiate ICMP message which doesn't get send when the port is filtered.
Was there netfilter enabled in the kernel and where iptables even installed? _________________ ...it's only Rock'n'Roll, but I like it! |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Tue Oct 06, 2009 1:17 pm Post subject: |
|
|
Quote: | At least for this sentence I must disagree. A firewall is not needed if only services are running that are supposed to listen on the WAN interface and if other services are correctly configured. |
Not every service can be configured to listen only on LAN interface. |
|
Back to top |
|
|
Anarcho Advocate
Joined: 06 Jun 2004 Posts: 2970 Location: Germany
|
Posted: Tue Oct 06, 2009 1:22 pm Post subject: |
|
|
Jaglover wrote: | Quote: | At least for this sentence I must disagree. A firewall is not needed if only services are running that are supposed to listen on the WAN interface and if other services are correctly configured. |
Not every service can be configured to listen only on LAN interface. |
That's why I wrote the second sentence you quoted. I just wanted to mention that this "Firewall is SOOOO important and ALWAYS necessary" is simply not true, which you always here from some "experts". There are good reasons for installing one and good reasons for don't installing one. It always depends on the situation e.g. for most root servers there are no such application that should not listen to the WAN interface. _________________ ...it's only Rock'n'Roll, but I like it! |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Tue Oct 06, 2009 1:25 pm Post subject: |
|
|
Agreed, if you have the luxury having different boxes. For a home network where one box has do do everything firewall is a good idea. |
|
Back to top |
|
|
Anarcho Advocate
Joined: 06 Jun 2004 Posts: 2970 Location: Germany
|
Posted: Tue Oct 06, 2009 1:27 pm Post subject: |
|
|
Jaglover wrote: | Agreed, if you have the luxury having different boxes. For a home network where one box has do do everything firewall is a good idea. |
That's true and is exactly as my setup is at home. _________________ ...it's only Rock'n'Roll, but I like it! |
|
Back to top |
|
|
|