# Have I been hacked??!!

## mattwood2000

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:

```

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:

```

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?

----------

## cazort

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.

----------

## mattwood2000

Hi cazort, I also found these strange addresses in my /var/log/messages log right after my reboot

```

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.

----------

## user124

 *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?

----------

## mattwood2000

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.

----------

## mattwood2000

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.

```

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 ********

```

----------

## Jaglover

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.

----------

## mattwood2000

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.

----------

## Jaglover

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.

----------

## Anarcho

 *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?

----------

## Jaglover

 *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.

----------

## Anarcho

 *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.

----------

## Jaglover

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.   :Cool: 

----------

## Anarcho

 *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.

----------

