How can I shake off this guy ?

[Doug S]

This appears to be the problem in reverse: if my machine is contacting the ubuntu update server via http, shouldn't the source port be 80 and the destination port a high number?

No. Your computer uses the high port number and earlier has opened a TCP session with port 80 of the destination. This is, perhaps, a similar problem to your earlier problem, but this time it is your end that is trying to finish a TCP session close, and not the other end. Your end keeps trying because the packets are being dropped instead of rejected, so your end does not know that the TCP connection has actually been terminated (I think). After a few re-tries it just gives up.

I do not have enough information to comment on the other parts of your post.

[hasinasi]

Interesting. Thank you!

Learning more about this, I am realizing that I am a little bit over my head in terms of how much I understand about TCP packets.

I am bit surprised these packets end up being dropped, since I am using the following rule to allow http traffic, where "oAll" is my "catch-all" chain for outgoing traffic:

iptables -A oALL -p tcp  --dport 80  -m state --state NEW -j ACCEPT

I am using this in conjunction with another rule before that to allow all "related" traffic:

iptables  -A OUTPUT  -m state  --state ESTABLISHED,RELATED  -j ACCEPT

As expected, usual http browsing (and updating the computer via apt-get) is not a problem. So I am a bit puzzled why the above-mentioned events end up in the logs.
Could these be invalid packets? I am not explicitly addressing packets of state "INVALID" (only NEW, ESTABLISHED, and RELATED), so they would be dropped and logged.
I will modify my iptables such that invalid packets can be identified from the logs.

[Doug S]

The packets are not "NEW" nor are they "ESTABLISHED,RELATED", is why they get end up in the DROP rule.
What happens is (I think) the TCP session has been closed and the connection tracking table has forgotten about it, but the client application doesn't realize it. This happens a lot with the half-duplex close method and with various NAT type routers in the middle.

Going back a few posts, here is better example of a case where the other side is trying to reset a connection that my side has already thought of as closed (but not forgotten, in this example). First the logs entries:

May 18 15:26:42 doug-64 kernel: [974914.165959] BAD80:IN=eth1 OUT= MAC=XX SRC=205.210.186.235 DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP SPT=80 DPT=54972 WINDOW=0 RES=0x00 RST URGP=0
May 18 15:26:42 doug-64 kernel: [974914.168128] BAD80:IN=eth1 OUT= MAC=XX SRC=205.210.186.235 DST=XXX.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP SPT=80 DPT=54972 WINDOW=0 RES=0x00 RST URGP=0

And then the entire TCP session

2013-05-18 15:26:41.741035 IP XXX.XXX.XXX.XXX.54972 > 205.210.186.235.80: Flags [S], seq 4147817431, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 571005325 ecr 0,sackOK,eol], length 0
2013-05-18 15:26:41.793904 IP 205.210.186.235.80 > XXX.XXX.XXX.XXX.54972: Flags [S.], seq 14144562, ack 4147817432, win 8000, options [mss 1460], length 0
2013-05-18 15:26:41.795412 IP XXX.XXX.XXX.XXX.54972 > 205.210.186.235.80: Flags [.], ack 1, win 65535, length 0
2013-05-18 15:26:41.797641 IP XXX.XXX.XXX.XXX.54972 > 205.210.186.235.80: Flags [P.], seq 1:1137, ack 1, win 65535, length 1136
2013-05-18 15:26:41.867327 IP 205.210.186.235.80 > XXX.XXX.XXX.XXX.54972: Flags [.], ack 1137, win 16338, length 0
2013-05-18 15:26:42.675978 IP 205.210.186.235.80 > XXX.XXX.XXX.XXX.54972: Flags [P.], seq 1:151, ack 1137, win 16338, length 150
2013-05-18 15:26:42.676185 IP 205.210.186.235.80 > XXX.XXX.XXX.XXX.54972: Flags [F.], seq 151, ack 1137, win 16338, length 0
2013-05-18 15:26:42.676437 IP 205.210.186.235.80 > XXX.XXX.XXX.XXX.54972: Flags [R.], seq 152, ack 1137, win 16338, length 0
2013-05-18 15:26:42.677949 IP XXX.XXX.XXX.XXX.54972 > 205.210.186.235.80: Flags [.], ack 151, win 65535, length 0
2013-05-18 15:26:42.678376 IP XXX.XXX.XXX.XXX.54972 > 205.210.186.235.80: Flags [F.], seq 1137, ack 151, win 65535, length 0
2013-05-18 15:26:42.678402 IP XXX.XXX.XXX.XXX.54972 > 205.210.186.235.80: Flags [F.], seq 1137, ack 152, win 65535, length 0
2013-05-18 15:26:42.812191 IP 205.210.186.235.80 > XXX.XXX.XXX.XXX.54972: Flags [R], seq 14144713, win 0, length 0
2013-05-18 15:26:42.812262 IP XXX.XXX.XXX.XXX > 205.210.186.235: ICMP XXX.XXX.XXX.XXX tcp port 54972 unreachable, length 48
2013-05-18 15:26:42.814383 IP 205.210.186.235.80 > XXX.XXX.XXX.XXX.54972: Flags [R], seq 14144713, win 0, length 0
2013-05-18 15:26:42.814414 IP XXX.XXX.XXX.XXX > 205.210.186.235: ICMP XXX.XXX.XXX.XXX tcp port 54972 unreachable, length 48

My side did acknowledge the FIN request and the RST request, but the other side still tries to RST the connection, hence the logs entries. Here is the related section of my iptables:

# At this point traffic to ports 80 or 443 is likely due to the half-duplex TCP close sequence. Be polite and REJECT instead of DROP.

$IPTABLES -A INPUT -i $EXTIF -p tcp -m multiport --sport 80,443 -j LOG --log-prefix "BAD80:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -p tcp -m multiport --sport 80,443 -j REJECT

# Catch all rule, all other incoming is denied.
# (Leave the log-n-drop jump here so that in future I can remember how to do it.)
#
$IPTABLES -A INPUT -s $UNIVERSE -d $UNIVERSE -j log-n-drop

[jeremywc]

This appears to be the problem in reverse: if my machine is contacting the ubuntu update server via http, shouldn't the source port be 80 and the destination port a high number? The same machine has been running at least for a month without creating such events in the firewall logs. Automatic updating always worked well.

No, you've got a reverse understanding of how TCP/IP works. Their server has to listen on a static port and the default for HTTP is 80. If they were listening on something other than the default port, you'd have to manually specify it in your URL string (i.e. http://www.example.com:8080). Your computer will randomly choose a port (usually something 50k+) that it will initiate it's connection FROM. Any packets coming back to you from the server will go to that random port.

EDIT: Doug beat me to it. Helps if I go to the end of the thread before replying. :-/

[scruffyeagle]

Hi! Much of this is over my head, but I did read all the posts... Anyway, I had a thought about this:

"medibuntu" sounds like it's some kind of medical program. However, checking in Synaptic, it didn't show up for this Xubuntu v12.04 OS. (3rd-party source?) What I was thinking, is that if this is a program you have installed on your machine, a remote server might be trying to provide data updates without realizing you don't have the program in operation at the moment; i.e., if the program had been running at that moment, then it would have gathered the data in an authorized manner, and no firewall probe event would have been reported.

Just a thought...

[cariboo]

Hi! Much of this is over my head, but I did read all the posts... Anyway, I had a thought about this:

"medibuntu" sounds like it's some kind of medical program. However, checking in Synaptic, it didn't show up for this Xubuntu v12.04 OS. (3rd-party source?) What I was thinking, is that if this is a program you have installed on your machine, a remote server might be trying to provide data updates without realizing you don't have the program in operation at the moment; i.e., if the program had been running at that moment, then it would have gathered the data in an authorized manner, and no firewall probe event would have been reported.

Just a thought...

Medibuntu is an unofficial repository for media codecs that aren't included in the main Ubuntu repositories, it's been around for almost as long as Ubuntu itself. It looks like the bad guy may be spoofing the Medibuntu ip address.

[scruffyeagle]

Got it. Naughty, naughty. Somebody ought to spank his modem.

[hasinasi]

@cariboo907:
I don't think it's IP spoofing, as I only get errors in my log as long as medibuntu is enabled as a repository. The occurrence of the problem in my logs also coincides with running "apt-get update". Therefore it (reproducibly) only happens when my machine establishes contact with the repos and not due to an action from an outside person.

[scruffyeagle]

Is it possible for a hacker to monitor the medibuntu activity, and spoof to try to take over or exploit the connection for their own purposes?

[CharlesA]

I guess they could be monitoring the repo, but that is why the packages are signed with GPG keys...