Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
07-14-2013, 04:47 PM
|
#1
|
Member
Registered: Nov 2012
Posts: 55
Rep: 
|
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 04:50 PM.
|
|
|
07-14-2013, 05:21 PM
|
#2
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep: 
|
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).
|
|
|
07-14-2013, 05:33 PM
|
#3
|
Member
Registered: Nov 2012
Posts: 55
Original Poster
Rep: 
|
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.
|
|
|
07-14-2013, 05:51 PM
|
#4
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep: 
|
Quote:
Originally Posted by Azrael84
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
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
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.
|
|
|
07-14-2013, 06:20 PM
|
#5
|
Member
Registered: Nov 2012
Posts: 55
Original Poster
Rep: 
|
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.
|
|
|
07-14-2013, 06:30 PM
|
#6
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep: 
|
Quote:
Originally Posted by Azrael84
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
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.
|
|
|
07-14-2013, 06:47 PM
|
#7
|
Member
Registered: Nov 2012
Posts: 55
Original Poster
Rep: 
|
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
|
|
|
07-16-2013, 05:24 AM
|
#8
|
Member
Registered: Nov 2012
Posts: 55
Original Poster
Rep: 
|
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??
|
|
|
07-16-2013, 05:29 AM
|
#9
|
Member
Registered: Nov 2012
Posts: 55
Original Poster
Rep: 
|
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
|
|
|
07-16-2013, 07:55 AM
|
#10
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep: 
|
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.
|
|
|
07-16-2013, 11:57 AM
|
#11
|
Member
Registered: Nov 2012
Posts: 55
Original Poster
Rep: 
|
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.
|
|
|
07-16-2013, 12:07 PM
|
#12
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep: 
|
Quote:
Originally Posted by Azrael84
|
It looks like the example uses the "owner" match, which was removed a long time ago as it was, and I quote, "unfixable broken".
|
|
|
07-16-2013, 01:38 PM
|
#13
|
Member
Registered: Nov 2012
Posts: 55
Original Poster
Rep: 
|
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...
|
|
|
All times are GMT -5. The time now is 06:40 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|