LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 07-14-2013, 03:47 PM   #1
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Rep: Reputation: Disabled
suspicious incoming packets on high ports


Hi,

In my iptables logs I have noticed:

Code:
netfilter:in dropped: IN=eth1 OUT= MAC=c5:17:fe:65:51:f8:00:26:44:59:a7:10:08:00 SRC=81.242.212.176 DST=192.168.1.79 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=16380 PROTO=TCP SPT=49480 DPT=44222 WINDOW=0 RES=0x00 ACK RST URGP=0
The source IP matches BE-SKYNET-ADSL1 in Belgium whatever that is, and the src and dst ports don't seem to match any known ones I can find. My computer is also behind a NAT router, which does not forward on those ports, and the fact that the packet is "ACK RST" makes me wonder if it is a "RELATED/ESTABLISHED" packet that just arrived too late for conntrack, but if this is the case, related to what? (I could understand if the SPT was 80 and it was something to do with a website I had visited but that isn't the case).

Last edited by Azrael84; 07-14-2013 at 03:50 PM.
 
Old 07-14-2013, 04:21 PM   #2
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,953

Rep: Reputation: Disabled
Could be the remote computer is responding to a spoofed packet. Perhaps someone is performing some sort of port scan; ACK and RST is what you'd expect to see as a response to a SYN packet sent to a closed, non-firewalled port. Are you seeing many of these packets?

The IP address belongs to a range of addresses dynamically assigned to residential DSL customers in Belgium (Belgacom).
 
Old 07-14-2013, 04:33 PM   #3
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Code:
Could be the remote computer is responding to a spoofed packet. 
Perhaps someone is performing some sort of port scan; ACK and RST is what you'd expect to see as a response to a SYN packet sent to a closed, non-firewalled port
I think I might be misunderstanding you. Are you suggested this person at 81.242.212.176 is portscanning me or they themselves are being portscanned/packet spoofed, and somehow I'm ending up with a packet?

Or are you even suggesting that I am part of a botnet and it is my own computer doing the portscanning on 81.242.212.176 and it is their ACK/RST response I am getting back?

Code:
Are you seeing many of these packets?
Seems to be a few a day. Not vast numbers, but enough to make me curious.

Code:
The IP address belongs to a range of addresses dynamically assigned to residential DSL customers in Belgium (Belgacom).
I see, thanks.
 
Old 07-14-2013, 04:51 PM   #4
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,953

Rep: Reputation: Disabled
Quote:
Originally Posted by Azrael84 View Post
I think I might be misunderstanding you. Are you suggested this person at 81.242.212.176 is portscanning me or they themselves are being portscanned/packet spoofed, and somehow I'm ending up with a packet?
Yes, it's a common technique to hide one's own port scanning packets amongst a bunch of spoofed packets. That way, the target has no way of identifying the real attacker. Your IP address may be just one of many addresses the attacker is trying to hide behind.

Quote:
Originally Posted by Azrael84 View Post
Or are you even suggesting that I am part of a botnet and it is my own computer doing the portscanning on 81.242.212.176 and it is their ACK/RST response I am getting back?
Unlikely, as netfilter wouldn't be dropping valid responses to packets sent by your system.

Quote:
Originally Posted by Azrael84 View Post
Seems to be a few a day. Not vast numbers, but enough to make me curious.
If these packets are indeed responses to SYN packets with spoofed source addresses, it would make sense that you'd only see a few of them now and again, and from different sources.
 
Old 07-14-2013, 05:20 PM   #5
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Code:
Yes, it's a common technique to hide one's own port scanning packets amongst a bunch of spoofed packets. That way, the target has no way of identifying the real attacker. Your IP address may be just one of many addresses the attacker is trying to hide behind.
I see, so 81.242.212.176 could be the victem, and some third-party hacker is sending him spoofed packets with my IP in their header, and then 81.242.212.176's firewall is rejecting them sending back an ACK RST response that finds its way back to me?

Code:
 >>Originally Posted by Azrael84 View Post
>>Or are you even suggesting that I am part of a botnet and it is my own computer doing the >>portscanning on 81.242.212.176 and it is their ACK/RST response I am getting back?

Unlikely, as netfilter wouldn't be dropping valid responses to packets sent by your system.
Could it be that it's not dropping most of them, but these few I see in the logs are just a few timed out ones? Maybe I should start logging outgoing high port activity just to check what is being sent out..

Final more prosaic theory: could Skype have anything to do with this? perhaps utilising these high ports to connect me through a relay or some such, and again the reason why netfilter is dropping (despite my initiation) could be put down to conntrack timeout?

I'm not really sure how to find out which of the above is true.
 
Old 07-14-2013, 05:30 PM   #6
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,953

Rep: Reputation: Disabled
Quote:
Originally Posted by Azrael84 View Post
I see, so 81.242.212.176 could be the victem, and some third-party hacker is sending him spoofed packets with my IP in their header, and then 81.242.212.176's firewall is rejecting them sending back an ACK RST response that finds its way back to me?
Precisely, or rather the TCP/IP stack on the victim's system is sending these responses. A firewall would most likely just drop the incoming packets.

Quote:
Originally Posted by Azrael84 View Post
Could it be that it's not dropping most of them, but these few I see in the logs are just a few timed out ones? Maybe I should start logging outgoing high port activity just to check what is being sent out..
It is possible, and I wouldn't rule out Skype as a factor either. Skype does some hideously complex application-layer routing to get past firewalls and packet filters, and could very well be trying to connect to a Skype process running on some Belgian computer, only to find that the user just closed the application or turned off the computer.

If you start logging outgoing SYN packets to high ports, you may be able to get to the bottom of this. Or at the very least be able to rule out you own system as the source of any port scanning activities.
 
Old 07-14-2013, 05:47 PM   #7
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
thanks again, I'll do that and see how things look over the next few days with a rule like:

Code:
iptables -A OUTPUT -p  tcp --dport 1024:65535 --syn -j LOGNACCEPT
 
Old 07-16-2013, 04:24 AM   #8
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Further to our discussion a few days ago, I set up outbound high port logging, and nothing much for days but today I see:

Code:
netfilter:Hout accepted: IN= OUT=eth1 SRC=192.168.1.79 DST=91.40.135.179 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=32749 DF PROTO=TCP SPT=42889 DPT=28854 WINDOW=14600 RES=0x00 SYN URGP=0
I can verify that Skype was definitely not running at this time (nor was a torrent client). Spotify was, but I think it only uses port 4070 (and broadcasts on LAN with port 57621).

This looks like a SYN packet from my computer to a residential customer in Germany? Am I infected??
 
Old 07-16-2013, 04:29 AM   #9
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
There is also

Code:
netfilter:Hout accepted: IN= OUT=eth1 SRC=192.168.1.79 DST=87.105.190.187 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4673 DF PROTO=TCP SPT=39176 DPT=34761 WINDOW=14600 RES=0x00 SYN URGP=0
and

Code:
netfilter:Hout accepted: IN= OUT=eth1 SRC=192.168.1.79 DST=143.21.20.178 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=55538 DF PROTO=TCP SPT=57072 DPT=47624 WINDOW=14600 RES=0x00 SYN URGP=0
 
Old 07-16-2013, 06:55 AM   #10
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,953

Rep: Reputation: Disabled
I'd expect to see more outbound traffic from a compromised system, but I do think it's strange that your system should be initiating TCP connections with IP addresses belonging to seemingly random DSL customers.

It's unfortunate that there's no way to log the name of the ID of the process generating these packets. I guess you could set up a job continuously monitoring the logs for messages related to these SYN packets, and have it dump the output of netstat -tap to a file whenever a message appears in the log.
 
Old 07-16-2013, 10:57 AM   #11
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Quote:
It's unfortunate that there's no way to log the name of the ID of the process generating these packets
How about this idea: http://jsosic.wordpress.com/tag/iptables/, see post "Finding UID that is generating traffic". Would that meet my purposes?

Quote:
it dump the output of netstat -tap to a file whenever a message appears in the log.
OK. Maybe I could run wireshark for a day or two and filter on the high ports too.

Perhaps I am being paranoid and it will turn out to be nothing, but either way I would like to understand what I am seeing here.
 
Old 07-16-2013, 11:07 AM   #12
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,953

Rep: Reputation: Disabled
Quote:
Originally Posted by Azrael84 View Post
How about this idea: http://jsosic.wordpress.com/tag/iptables/, see post "Finding UID that is generating traffic". Would that meet my purposes?
It looks like the example uses the "owner" match, which was removed a long time ago as it was, and I quote, "unfixable broken".
 
Old 07-16-2013, 12:38 PM   #13
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
I am now beginning to believe these packets are caused by Spotify. I did not realise it worked partially peer2peer (See http://www.dummies.com/how-to/conten...ify-works.html). I thought it only used port 4070 (as in the past I have blocked all ports but this and it has still worked), but I believe it also uses p2p to suppliment the download.

I can certainly identify some outgoing SYN packets to seeimngly random residential computers on high ports, with sockets being used by Spotify. It's hard to say for certain if Spotify P2P is responsible for everything, it's a pity I can't filter all Spotify packets from the logs...
 
Old 07-16-2013, 12:51 PM   #14
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
I guess it works with only outbound 4070 allowed by the techniques explained here: http://www.csc.kth.se/~gkreitz/spoti...tify-p2p10.pdf .........a bit like UDP hole punching but for TCP.
 
  


Reply

Tags
iptables


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Incoming Packets Francy Linux - Networking 1 05-02-2011 04:00 PM
Mark all incoming packets on connection andrewhiggs Linux - Networking 26 04-16-2010 12:10 PM
Should I be paranoid about having suspicious ports on Nmap...that are closed? mohtech Linux - Security 1 01-30-2008 07:39 AM
check incoming or outgoing packets ilnli Programming 1 07-24-2007 03:08 PM
logging incoming packets ip address b123coder Linux - Networking 1 11-18-2004 02:17 PM


All times are GMT -5. The time now is 10:18 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration