# Am I being attacked? [SOLVED]

## iandoug

Hi

Last few days have been noticing unusual traffic on my home LAN. I have three NAS boxes, and there is persistant traffic up/down to one or more of them at a time. Around 50-60 KB/s each direction.

I know this because I can see via the KDE net traffic applet, and EtherApe shows the connection as a solid line, MICROSOFT-DS. I shut down GUI programs which might want to access those drives.

I don't think I've noticed this in the past.

So given the plagues of encryption malware running around (including attacking Linux), I'm trying to decide:

1. is this just Baloo/Recoll indexing things? But why similar up/down traffic then?

2. is this some malware quietly encrypting my drives?

3. Something else?

The various drives are mounted from here at boot time.

A search for .enc files showed a lot of font-related files, so I don't think whatever it is is creating such files.

Random files checked on the NAS boxes appear to be okay. But there are thousands....

I Googled trying to find out how to see exactly which process is causing the traffic, general solution seems to be to use nethogs. However the stable version is buggy and the unstable one even buggier. So not particularly wiser.

Netstats shows for example:

```

tcp        0      1 trooper.zti.co.za:33914 nas2:microsoft-ds       SYN_SENT   

tcp        0     42 trooper.zti.co.za:43280 nas1:microsoft-ds       ESTABLISHED

tcp        0      0 trooper.zti.co.za:54338 nas3:microsoft-ds       ESTABLISHED

```

Any ideas how to find out exactly what is generating the traffic?

Thanks, Ian

----------

## krinn

It depends, if you are tooper.zti.co.za... it's ok

else it's just someone using microsoft share on your nas (that's not cool)

You should disable samba on the nas, or at least, not having the nas expose.

----------

## eccerr0r

If you're connected to the internet, expect to be attacked.

There's a difference between attacked and successfully attacked, but since you don't know the remote host, it's at least the first and since there's a lot of traffic, the second is possible.

microsoft-ds in a Linux world likely means samba.  So yes that host is connecting to your samba server.

Are these NAS boxes for LAN use or were you expecting worldwide use for them, can you firewall them off?

----------

## iandoug

Thanks for speedy responses.

Yes I am trooper.zti.co.za ('cos it's a Coolermaster Trooper case....  :Smile:  )

Boxes are for LAN use only, running FreeNAS (FreeBSD-based). Accessed via SMB.

Internet -> ADSL router -> IPFire firewall -> LAN -> trooper.

I would relax better if I could figure out what is generating the traffic... 

FIrewall was configured to allow port 80 traffic to another server at one point but don't think it's doing that any more.

Is there a tool I can use to show me what's driving the SMB process causing the traffic?

Thanks, Ian

----------

## cboldt

Amen to "If you're connected to the internet, expect to be attacked."

I have a handful of open ports, and the amount of traffic hitting them from the outside is mind boggling.

----------

## Skinjob2707

 *Quote:*   

> Is there a tool I can use to show me what's driving the SMB process causing the traffic? 

  .

You could give Wireshark a try:

https://wiki.gentoo.org/wiki/Wireshark

It will allow you to see the network traffic and protocol information.  The protocol dissectors should enable you take a deep dive through the SMB sections of the packet.  One thing to be careful of is if you are plugging your network into switches instead of hubs.  If it is the former, you will need to configure the system running Wireshark's network port on the switch to send all traffic and not just traffic for devices on that Ethernet segment.

----------

## Hu

Although Wireshark has the ability to capture from the command line, you might find it more convenient (particularly on a GUI-free system) to install only tcpdump on the machine that will capture traffic, dump the traffic to a file, then scp the file to a machine with a GUI where you can use Wireshark to review the captured data.

----------

## NeddySeagoon

iandoug,

The IPv4 address space is full.  If you are connected via IPv4, whatever holds your public IP is being scanned and probed continuously.  

IPv6 is not so bad as the address space is mind bogglingly huge, so its mostly empty.

Its not directed scanned and probing, its nasty people trying to build a bigger botnet. Any random host will do.

Some of it isn't vey well managed either.  I've had scanners hitting my POP3 so hard, I can't use it, so I dropped their entire netblock.

To see if its internal or external traffic, unplug your internet connection.  If your 60k/sec traffic stops, you might have a problem.

If it continues, its less of a risk.

----------

## eccerr0r

What was a bit confusing is that tooper.zti.co.za had a FQDN and "nas1" is typical of a LAN NFQDN ... but if both are on your LAN then it's just computer to computer traffic on your own net which is a bit less concerning unless tooper.zti.co.za got hijacked and is the reason for the traffic.  Whether to assume that to not be the case I don't know...

----------

## iandoug

Hi 

Thanks guys.

I did install wireshark, bit clueless using it but think I managed to capture the traffic twice and it LOOKS to me like a continuous stream of 

Hello

      Yes?

Hello

      Yes?

      Hello

Yes?

Sample below. Yes all traffic is on LAN, this box has a FQDN because at some point something moaned about it not being one.

I have indeed switched off the router and traffic continues. Only thing that stops it is SSH to NAS boxes and shut them down... 

The traffic is not PERMANENTLY CONTINUOUS... seems to occur in bursts, but for quite a long while. Then I happen to notice that there is none running, like now. So I really don't know it it is something indexing the files or not ... I see KDE Desktop now has additional search settings which refuse to stick (this is over and above their Akonadi/Baloo File Indexing thing.). Possibly Recoll is also poking around on the drives, but wireshark packet size does not seem to be media, and anyway, why read then send it back?

The other "part of the problem" that was bugging me was that these drives are backed up to tape nightly. At some point, I started getting "host is down" messages from Bacula. But the next directory on the same drive backs up just fine. So being a Doomer I assume that something is slowly encrypting the drives, one folder at a time, leading to these errors. But if I run the back up job manually then it works just fine. And accessing the drives manually is fine. Although this happened once:

```

~ $ ls /home/ian/nas1stuff/

ls: cannot access '/home/ian/nas1stuff/': Host is down

~ $ cd 

~ $ cd /home/ian/nas1stuff/

~/nas1stuff $ ls /home/ian/nas1stuff/

(works)

```

So possibly something is mysteriously broken in my SMB setting... I wonder if setting

nt pipe support = no

in smb.conf, as advised on  http://www.linux-magazine.com/Online/News/Samba-Security-Hole-Patched-but-Risk-is-Bigger to prevent the latest nasties from causing havoc, is causing these issues.

Else I thought it may be some sort of "keep alive" function that I may or may not have set on somewhere (but have no idea where).

Anyway, extracts from wireshark captures:

http://imgur.com/N68vO7Q

thanks, Ian

----------

## krinn

that's just the nas asking whois (like ethernet protocol do, but the smb version), and echo

smb doesn't discover hosts, hosts send they are up thru the network (they broadcast blindly they are up) and other smb hosts discover they exists, that's why you sometimes wait before seeing an host appears while the new host didn't yet yell it exists

the echo is the "down" version, you echo an host you know to be active, and if it doesn't answer, it is down.

you have just discover smb is really a shitty protocol

now, put some upnp device in your network and enjoy the 2nd shittiest protocol in network  :Smile: 

----------

## iandoug

 *krinn wrote:*   

> that's just the nas asking whois (like ethernet protocol do, but the smb version), and echo
> 
> smb doesn't discover hosts, hosts send they are up thru the network (they broadcast blindly they are up) and other smb hosts discover they exists, that's why you sometimes wait before seeing an host appears while the new host didn't yet yell it exists
> 
> the echo is the "down" version, you echo an host you know to be active, and if it doesn't answer, it is down.
> ...

 

I can accept some initial "hello everyone, here I am" traffic when a host starts up, but why would it need to contact other hosts continuously?

Also this traffic is between this box and my three NAS boxes. There is no similar traffic between this host and other computers/devices on the LAN Including another Linux box running Mint, and another running Gentoo.

I think the difference is that I have folders on the NAS boxes mounted as shares on boot (so that Bacula can work without having to worry about running bacula-file-directors on each host, because they are running FreeNAS/FreeBSD and keeping versions of Bacula synchronised is an issue... it is anyway the recommended solution and worked fine in the past, without issues.)

If this is SMB traffic, then should "/etc/init.d/samba stop" make everyone shut up?

I tried that as root after logging out of KDE and nettop still showed traffic ...

So although this traffic looks like SMB housekeeping, I'm still not convinced... especially as to why so much is necessary, and if it is necessary, why is it not permanently running, instead of only some/most of the time...

thanks, Ian

----------

## toralf

FWIW I like the tool iftop - gives a helpful online stats about tcp connections.

----------

## iandoug

 *toralf wrote:*   

> FWIW I like the tool iftop - gives a helpful online stats about tcp connections.

 

Thanks, I installed it but it tells me what I already know ... there's a lot of traffic between this box and the NAS boxes.

So I installed ntop ... which allows me to drill down via the web interface.

Curiously it tells me that the traffic is FTP ... which makes no sense.

If anyone could shed some light on this I'd be grateful .... other net analyzers just point to MS-DIRECTOR, but ntop says the Layer 7 is on FTP ....

Also a lot of rejected packets, probably because NAS boxes are not running FTP servers....

I can't think of any process that I would run that tries to autoconnect via FTP to my NAS boxes....

----------

## iandoug

I SSHd to NAS2 and ran netstat, which produced a very fast scrolling list like this extract:

```

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52990 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52988 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52984 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52982 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52978 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52976 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52972 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52970 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52966 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52964 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52960 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52958 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52954 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52952 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52948 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52946 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52942 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52940 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52936 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52934 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52930 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52928 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52924 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52922 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52918 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52916 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52912 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52910 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52906 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52904 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52900 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52898 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52894 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52892 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52888 TIME_WAIT

tcp4       0      0 192.168.1.52.microsoft trooper.zti.co.z.52886 TIME_WAIT

```

trooper.zti.co.za is this box.

192.168.1.52 is NAS2.

What does this mean?

Same story on NAS1

NAS3 just prints a page of data and stops.

----------

## krinn

Instead of trying to guess who is who and who do what, can't you just shut down samba on all hosts and see if your network gets quiet?

Have a good reading: https://www.samba.org/samba/docs/using_samba/ch07.html

----------

## iandoug

So after enduring this annoying odd network traffic for a few months, I am happy to report that it has now stopped and things are back to normal.

I think the fix was upgrading to kernel 4.12.5-gentoo ... (from 4.9.16)

At the same time the other related problem (Bacula complaining that mounted drives are down, on the first attempt to access it), has also gone away.

Find it a bit odd that a kernel upgrade (as opposed to something Samba-related) would fix this, but am not complaining.

Thanks to all those who offered advice  :Smile: 

Cheers, Ian

----------

