Connection to china?

[humantoad]

Hi, 

Please disregard this if it's expected behaviour. I've been using the wifi pineapple on and off, for a while now, but today logged in over SSH for the first time when I started wondering why the CPU utilisation spiked. 

Running netstat -ant showed two established SSH connections to IP:s that are in china. 

Being a paranoid person, I freaked and restored factory settings, went through the setup process and logged in over SSH again only to find the same IP:s as established sessions on SSH. 

Now, I haven't gone through the firmware restore, since I figured I'd ask the forums if this is expected behavior and if it isn't how can I go about finding out how the connections orginate and what they are doing on the box.

Any and all help would be greatly apreciated. 

[Just_a_User]

I'd recommend using iftop as its nice to see connection activity live. Also are you leaving the tetra on and connected to the internet for long periods of  time? What have you installed onto it and from what sources?

I would check iftop then do a firmware recovery and check again with iftop to check the connections are gone.

I dont have much more than local connections on mine, apart from google dns and some small occasional exceptions. Be aware if your allowing client connections they can try brute forcing your ssh unless you turn user/pass off and go to certificates using the papers module or so.

 

To install iftop: -

opkg update
opkg install iftop

Iftop usage: -

root@TETRA:~# iftop -h
iftop: display bandwidth usage on an interface by host

Synopsis: iftop -h | [-npblNBP] [-i interface] [-f filter code]
                               [-F net/mask] [-G net6/mask6]

   -h                  display this message
   -n                  don't do hostname lookups
   -N                  don't convert port numbers to services
   -p                  run in promiscuous mode (show traffic between other
                       hosts on the same network segment)
   -b                  don't display a bar graph of traffic
   -B                  Display bandwidth in bytes
   -i interface        listen on named interface
   -f filter code      use filter code to select packets to count
                       (default: none, but only IP packets are counted)
   -F net/mask         show traffic flows in/out of IPv4 network
   -G net6/mask6       show traffic flows in/out of IPv6 network
   -l                  display and count link-local IPv6 traffic (default: off)
   -P                  show ports as well as hosts
   -m limit            sets the upper limit for the bandwidth scale
   -c config file      specifies an alternative configuration file

iftop, version 1.0pre2
copyright (c) 2002 Paul Warren <pdw@ex-parrot.com> and contributors

Hope this helps.

Edited March 23, 2017 by Just_a_User

[3mrgnc3]

I don't know about the pineapple, as I don't leave any of mine connected to the internet for a long period of time.

However, on the VPS I run my blog from I was seeing many connections 'ESTABLISHED' to port 22 in netstat output. After also looking at my auth.log files too I saw Chinese IP addresses attempting to brute force my ssh password (unlucky for them I disable passwords and only use rsa keys).

Sadly, this is common behaviour now in this age of cyberwarfare.

I changed my ssh port to a non-standard one and now I have no problems.

Just so everyone is clear, a netstat connection 'ESTABLISHED' doesn't mean an ssh session has been 'AUTHENTICATED'.

Check using the commands:

'w', 'last', & 'lastlog'

Then you will see precisely who is/has connected to your server and when.

 

[humantoad]

Thanks,
It's probabbly someone trying to bruteforce it then. Good thing I have a strong password. 

None of the suggested commands are installed, or in the included repository. Are there any alternatives? 

Also, can't seem to find access logs?  

Not familiar with the installed distro at all. 

[Just_a_User]

Yeah we dont have w or who on Pineapple AFAIK. On the pineapple we use openSSH and it seems to log to syslogd. There isnt a traditional /var/log/auth.log.

You can view ssh server logins by using

logread | grep sshd

or dump it to a file with

logread | grep sshd > /var/log/auth.log

As an example. hope this helps.

Edited March 27, 2017 by Just_a_User

[3mrgnc3]

3 minutes ago, Just_a_User said:

Yeah we dont have w or who on Pineapple AFAIK. On the pineapple we use openSSH and it seems to log to syslogd. There isnt a traditional /var/log/auth.log.

You can view ssh server logins by using

logread | grep sshd

or dump it to a file with

logread | grep sshd > /var/log/auth.log

As an example. hope this helps.

lol, Oh Yeah , Forgot about that when thinking about what I saw on my VPS, cheers for posting and letting people know I was mistaken  in suggesting those particular commands.

[humantoad]

Someone is trying to bruteforce the ssh password for sure. 

Tue Mar 28 09:14:11 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:12 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:13 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:14 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:15 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:16 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2

Is there something like fail2ban for the pineapple distro? 

 

[Just_a_User]

I looked at fail2ban a while ago and I think it uses /var/log/auth.log to monitor failed ssh login attempts. I’m sure there must be a way to change how/where it looks for logs. It also runs on python and can be heavy on resources.

I instead had a look around and found something which seems a more light weight solution. But I haven't tested it so cant confirm if it can run on the pineapple yet. There are quite some differences between the pineapple and standard OpenWRT build.

if you (or anyone else) has time it might benefit us all to have some protection both from WAN but also maybe br-lan clients.

https://github.com/robzr/bearDropper

https://forum.openwrt.org/viewtopic.php?id=62084

Of course the best solution would be to not leave your pineapple exposed to the internet without a firewall, use alternative ssh port, disable user/pass login and use certs.

Edited March 28, 2017 by Just_a_User

[3mrgnc3]

2 hours ago, humantoad said:

Someone is trying to bruteforce the ssh password for sure. 

Tue Mar 28 09:14:11 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:12 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:13 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:14 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:15 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2
Tue Mar 28 09:14:16 2017 auth.info sshd[4468]: Failed password for root from 183.214.141.104 port 14350 ssh2

Is there something like fail2ban for the pineapple distro? 

 

There is a project I found on github that is a fail2ban style solution for opewrt that would probably work on the pineapple https://github.com/robzr/bearDropper

Edit: lol just saw this was the same as suggested above too :D

However, the issue with fail2ban's blacklisting style solution to the problem is that it ends up appending hundreds and hundreds of IP addresses to an iptables rule list. Then this has to be loaded/parsed/compared whenever connection attempts are made. This could give a significant performance hit to you little old pineapple.

The simplest and least CPU intensive solution to the problem is to switch ssh to a high port (eg. 61222) AND use RSA key authentication, STRICTLY disallowing password auth in your config. Then (as just_a_user alluded to) WHITELIST you own IP addresses using iptables.

The ssh BOT/BOTS that are trying to brute you tend only to focus on port 22, and if they are smart enough to detect password auth is dsabled will give up quickly.

But in 99.9% of cases I would put money on the problem going away if your using a non standard high port number for ssh.

Hope this helps.

Edited March 28, 2017 by 3mrgnc3
link updated

[barry99705]

Heh, my OSX servers used to get this crap back in 03 or 04.  I just block all of China now.  Much easier.

[Sebkinne]

Hi everyone,

No hak5 products are making connections to china or anywhere else (unless explicitly stated beforehand, such as updates, bulletins, etc). If you see SSH connections, and the device is accessible from the internet, then you are most likely just a victim of brute-force attempts. As others have said, just drop those IP ranges.

I have hidden the off-topic posts in this thread, and I expect the conversation will stay on topic from now on.

[Forkish]

This thread takes me down a peg or two.  I still have a lot of learn especially in the CLI and ssh department.. and iptables.