Suspicious activity


(Lorne Gaetz) #21

Apart from a framework (?) version, there are no answers to my questions. Just more questions. Now the system is natted, whereas in post 1 it wasn’t.

Going to recommend you hire someone to review and explain what’s going on here. Sangoma support is one option.


(United States) #22

Been unavailable. Still seeing occasional odd activity.

https://pastebin.freepbx.org/view/05d22889

I have a burst of of calls like this. Firewall is on, Responsive is enabled for pjsip only. System is a vm with NAT.


#23

Exactly which bit of that log do you find ‘odd’ ? (don’t assume everyone else will filter out your ‘un-odd’ bits :slight_smile: )


(Tom Ray) #24

If they have auth creds then Responsive will allow them because they auth’d successfully. This shows that 205 made a call to the 605 area code (high cost) and it was a good call. They authed, they matching outbound routes and calls went out like it should.

You need to look at actual SIP traffic to see where these are coming from.


(United States) #25

There are about 30 calls out to 1605562045x then incrementing to the next number. The call seems to come from extension 205 and happens afterhours when that extension is behind locked doors. The system is NAT and has Firewall and Responsive configrured. I cannot see how these calls are being made.


#26

Then investigate what exactly extension 205 was when it made the call, likely it got ‘owned’ and but

grep 205 /var/log/asterisk/full/

might reveal a little (actually a lot :wink: you are looking for ‘registrations’ ).


(Tom Ray) #27

sngrep is your friend. You need to run something like sngrep to watch the actual SIP traffic so you can see where they are coming in from.

As I said, with the Responsive Firewall it allows ANY IP to access the system over the SIP ports you want. IF they AUTH then the firewall considers them ALLOWED.

The fact these calls are being authenticated means they have the creds for 205 and are using them. If you say you’ve changed them already, that doesn’t mean they still don’t have a way into your system to get these details.


(United States) #28

https://pastebin.freepbx.org/view/79558ae3

This is grep 205 with only the records with an after hours time stamp.


#29

Log shows successful registration from 208.81.157.22 (Air Pipe?)
See
https://whois.domaintools.com/208.81.157.22


(Tom Ray) #30

Wow 30K lines of crap for 5 related lines because of a horrible shotgun approach. I guess you “lucked out” here because this shows some REGISTERs but calls don’t require REGISTERs so this still doesn’t show where calls could be coming from.

Again, sngrep is your friend you should be using that to watch/log the traffic so you can see 100% where these calls are actually sourcing from. Using the full log is a waste of time for that.

/var/log/asterisk/full-20200603:[2020-06-02 17:51:56] VERBOSE[6324] res_pjsip_registrar.c: Added contact 'sip:205@192.168.1.247:5060' to AOR '205' with expiration of 3600 seconds
/var/log/asterisk/full-20200603:[2020-06-02 18:15:46] VERBOSE[6324] res_pjsip_registrar.c: Added contact 'sip:205@208.81.157.22:8955' to AOR '205' with expiration of 3600 seconds
/var/log/asterisk/full-20200603:[2020-06-02 18:41:55] VERBOSE[12613] res_pjsip_registrar.c: Added contact 'sip:205@192.168.1.247:5060' to AOR '205' with expiration of 3600 seconds
/var/log/asterisk/full-20200603:[2020-06-02 18:44:33] VERBOSE[12613] res_pjsip_registrar.c: Added contact 'sip:205@208.81.157.22:8956' to AOR '205' with expiration of 3600 seconds
/var/log/asterisk/full-20200603:[2020-06-02 19:31:53] VERBOSE[15840] res_pjsip_registrar.c: Added contact 'sip:205@192.168.1.247:5060' to AOR '205' with expiration of 3600 seconds

(United States) #31

Ok, sngrep is awesome. I have no idea what I am looking at, will have to readup. What indicated in SIP traffic here that says a call is/was successfully made?


(United States) #32

Interesting. So either Air Pipe / Wow-tel has a client doing this or is this wow-tel itself.


(Tom Ray) #33

It would be a client. So this thread was started a week ago and it was determined that you had the same SIP password for all your extensions, they were short passwords, you were using TFTP for provisioning and you were compromised. You stated you were going to be changing passwords and it was suggested you move to HTTPS for provisioning.

Now roughly 24 hours ago you stated the same thing when you opened this thread. More calls being made that shouldn’t be. So now the questions are:

  • Did you move from TFTP to HTTPS for your provisioning?
  • Did you change all the passwords?
  • Did you make them longer and more complex?
  • What steps have you actually taken to secure this box?

Because if you taken a bunch of steps and this still happened a week later, then they are in your box another way and you really need to find it. Otherwise, if you’ve done nothing we’ve spent the last 24 hours troubleshooting an issue that was left unresolved from earlier in the week.


(United States) #34

This thread started with an incident, I was unavailble for days, then taken up again with a new incident with the same parameters.

  • Did you move from TFTP to HTTPS for your provisioning?
    To be done

  • Did you change all the passwords ?
    Yes, all passwords, user and device

  • Did you make them longer and more complex?
    Yes, 25 char random generated unique to each device

  • What steps have you actually taken to secure this box?
    Firewall is enabled, Responsive is enabled on pjsip, ip authorization locked at provider. I also notified the abuse contact for the offending ip address, wow-tel.com

To do: change port 5060/5061 to something else and change to HTTP provisioning.

With these changes we have had no incursions since.


(Tom Ray) #35

That would mean if they got the details from spoofing MACs or hammering TFTP services, then they have the details and just need to spoof the MACs again and pull the configs. Thus giving them the passwords that you changed.

This is leaving the door open.


(United States) #36

Did it this morning. Thanks, I agree with your assessment.


(United States) #37

All items discussed have been addressed and, of course, something else is broken. Outbound alls get all circuits busy.

We changed the SIP port, it is port number NNNNN in the allowed ranger, I checked.
Now we get all circuits busy. The calls are not getting to the SIP provider at all.

Changed the SIP port with the provider, changed it in:
CONNECTIVITY-TRUNKS - SIP SERVER PORT and
SETTINGS - ASTERISK SIP SETTINGS - CHAN PJSIP SETTINGS - UDP - PORT TO LISTEN ON.

How can I upload a pcap file?

//pastebin.freepbx.org/view/68f3e6a9


(United States) #38

All items discussed have been addressed and, of course, something else is broken. Outbound alls get all circuits busy.

We changed the SIP port, it is port number NNNNN in the allowed ranger, I checked.
Now we get all circuits busy. The calls are not getting to the SIP provider at all.

Changed the SIP port with the provider, changed it in:
CONNECTIVITY-TRUNKS - SIP SERVER PORT and
SETTINGS - ASTERISK SIP SETTINGS - CHAN PJSIP SETTINGS - UDP - PORT TO LISTEN ON.

How can I upload a pcap file?

//pastebin.freepbx.org/view/68f3e6a9 ](//pastebin.freepbx.org/view/68f3e6a9)


#39

While it says Port in both of those places they are entirely different things. The first is the port that your Trunk provider is listening on at their end. Its something they tell you to use.

The second is the port that your server is listening on and asterisk tells other servers you are using it so they can communicate send traffic back to it. If you wanted to change the port your server was listening on to something other than 5060 you only needed to change this one.

There’s nothing in that log fragment to say what is happening with your trunks. I’d suggest you change one at time and see if things start working again.


(United States) #40

I came to that conclusion and changed the trunk port back to 5060 and updated at flowroute and restarted Asterisk, no luck.

I currently do not have access to wireshark and I am not seeing the issue looking at log created by “pjsip set logging” or with sngrep. Not up on using sngrep or reading logs, as you can see. Suggestion for getting the right log to look at?