Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 40

Thread: How can I shake off this guy ?

  1. #21
    Join Date
    Mar 2007
    Location
    Virginia
    Beans
    50
    Distro
    Kubuntu 12.04 Precise Pangolin

    Under "attack" by the same IP?

    I also recently found some events in my iptables logs coming from the very same IP address. The command "host" still says the corresponding IP address is "faraway.pocentek.net".
    However, doing some googling, I found out that this IP also corresponds to "medibuntu.org", and a
    Code:
    host medibuntu.org
    command confirmed this. I do have the medibuntu repos enabled, so I am thinking it's related to that.

    What I am puzzled about is which ports are actually being used. I am not an expert, but I am under the impression that "apt-get" only uses http. Therefore, port 80 should be open for outgoing traffic, which it is. I can update this machine (ubuntu repos), and I can browse the web. My log, however, shows input from this server 88.191.127.22 on port 80, whereas many different ports are listed for my machine (high port numbers).

    So how does this work? Obviously, the first IP request from my machine goes to the remote server (output), but then, the data has to flow from the server to my machine, which would be considered an input? Is this possibly related to the timing? Maybe, the server is responding too late, and then it is no longer considered a response but suddenly looks like an attack?

  2. #22
    Join Date
    Oct 2009
    Beans
    Hidden!
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: How can I shake off this guy ?

    A a general rule of thumb, the destination port will be one of the known ports (80, 443, 22, 25, etc), and the source ports will be some random high numbered port. Without an example, it is hard to picture what you are talking about.
    Come to #ubuntuforums! We have cookies! | Basic Ubuntu Security Guide

    Tomorrow's an illusion and yesterday's a dream, today is a solution...

  3. #23
    Join Date
    Mar 2007
    Location
    Virginia
    Beans
    50
    Distro
    Kubuntu 12.04 Precise Pangolin

    Re: How can I shake off this guy ?

    @CharlesA:

    Thanks very much for your reply.
    What you tell me is kind of what I expected. However, going through my browser logs, I often find entries where it is the other way round: the source being one of the known ports (often http or https) and the destination (incoming) being a high number. That's why I could not make sense of it. I see this stuff on several of my machines; much more frequently on machines that have web browsers running (not a real proof at this point).

    Let me give you an example of my logs. The address 192.168.0.159 is the local address of my machine (behind a wireless router, which already block most of the mean stuff). The address 88.191.127.22 belongs to the machine that has previously been discussed in this thread. It appears to belong to "faraway.pocentek.net", but "medibuntu.org" also resolves to the same address, and therefore, it might be relevant to lots of ubuntu users. (I replaced the real MAC addresses with *** in the following code.)

    Code:
    May 19 05:02:11 haseee kernel: [76574.957701] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36759 SEQ=3895961960 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 05:02:12 haseee kernel: [76576.200122] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36766 SEQ=1289942439 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 05:02:12 haseee kernel: [76576.406922] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36767 SEQ=4155235900 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 05:02:12 haseee kernel: [76576.823143] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36769 SEQ=1498010674 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 05:02:13 haseee kernel: [76577.861990] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36774 SEQ=4167418617 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 05:02:14 haseee kernel: [76578.068836] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36775 SEQ=1631493983 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 07:51:39 haseee kernel: [86743.661530] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36848 SEQ=2177653835 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 07:51:39 haseee kernel: [86743.866111] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36849 SEQ=1542108056 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 07:51:41 haseee kernel: [86745.096420] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36855 SEQ=273139663 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 07:51:41 haseee kernel: [86745.312698] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36856 SEQ=3594443889 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 07:51:41 haseee kernel: [86745.723826] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36858 SEQ=3583800294 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 07:51:42 haseee kernel: [86746.347302] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36861 SEQ=299316482 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 09:21:02 haseee kernel: [92106.584708] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36914 SEQ=3939528884 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 09:21:03 haseee kernel: [92106.994400] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36916 SEQ=3172116063 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 09:21:03 haseee kernel: [92107.202958] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36917 SEQ=810468995 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 09:21:04 haseee kernel: [92108.024106] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36921 SEQ=1678517465 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 09:21:04 haseee kernel: [92108.232606] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36922 SEQ=1978130127 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 09:21:04 haseee kernel: [92108.445364] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36923 SEQ=4271162775 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 09:21:04 haseee kernel: [92108.648243] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36924 SEQ=2078825870 ACK=0 WINDOW=0 RES=0x00 RST URGP=0 
    May 19 09:21:05 haseee kernel: [92109.262073] DROPPED IN=eth0 OUT= MAC=*** SRC=88.191.127.22 DST=192.168.0.159 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=0 DF PROTO=TCP SPT=80 DPT=36927 SEQ=186303009 ACK=0 WINDOW=0 RES=0x00 RST URGP=0
    Do you need any more info?

    Thanks a bunch.
    --hasi

  4. #24
    Join Date
    Oct 2009
    Beans
    Hidden!
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: How can I shake off this guy ?

    That looks odd.. you don't usually see traffic from the source port of 80 (http) because a normal web server wouldn't be trying to connect to you in reverse.

    This is what an attack should look like:

    Code:
    May 15 23:13:21 serenity kernel: [10100.497336] SSH Attack: IN=venet0 OUT= MAC= SRC=173.45.97.98 DST=xxx.xxx.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=20821 DF PROTO=TCP SPT=54244 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
    Come to #ubuntuforums! We have cookies! | Basic Ubuntu Security Guide

    Tomorrow's an illusion and yesterday's a dream, today is a solution...

  5. #25
    Join Date
    Nov 2008
    Location
    S.H.I.E.L.D. 6-1-6
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: How can I shake off this guy ?

    Have you set iptables to MIRROR by any chance.
    It looks exactly what it should look like if MIRROR was enabled
    Don't waste your energy trying to change opinions ... Do your thing, and don't care if they like it.

  6. #26
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    2,393
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: How can I shake off this guy ?

    The log entries look O.K. to me, and just indicate that 88.191.127.22 is resetting the TCP session. The session might well have been started by the OP's computer. Linux uses a "half_duplex" close sequence, and it is very easy for one side to think the session has been closed while the other side doesn't, and thus a reset packet can be thought to be a whole new session packet, without a SYN. Here is an example from my logs, but notice that I use a different discriptor for each entry type to help me know where in the iptables the log entry came from:
    Code:
    May 12 16:42:19 doug-64 kernel: [461050.935032] NEW TCP no SYN:IN=eth1 OUT= MAC=XX SRC=72.52.5.67 DST=XXX.XXX.XXX.XXX LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=44377 PROTO=TCP SPT=80 DPT=7315 WINDOW=1400 RES=0x00 ACK URGP=0
    May 12 16:42:19 doug-64 kernel: [461051.349415] NEW TCP no SYN:IN=eth1 OUT= MAC=XX SRC=72.52.5.67 DST=XXX.XXX.XXX.XXX LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=44377 PROTO=TCP SPT=80 DPT=7315 WINDOW=1400 RES=0x00 ACK URGP=0
    If you want to know for certain, use tcpdump (or wireshark, if you prefer) and catch and entire TCP session or more.
    Code:
    sudo tcpdump -n -nn -tttt -i eth0 host 88.191.127.22
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  7. #27
    Join Date
    Mar 2007
    Location
    Virginia
    Beans
    50
    Distro
    Kubuntu 12.04 Precise Pangolin

    Re: How can I shake off this guy ?

    @ sandyd:
    I don't have any MIRROR commands in my iptables.

  8. #28
    Join Date
    Mar 2007
    Location
    Virginia
    Beans
    50
    Distro
    Kubuntu 12.04 Precise Pangolin

    Re: How can I shake off this guy ?

    @ Doug S:

    Thank you so much for your thoughtful reply. It sounds quite plausible. It's good to know that there is a way to make sense of it.
    Interesting what you mention about the descriptors. Are those the sections in your log saying "NEW TCP no SYN:"?
    How do you have to change iptables scripts to implement getting these descriptors in the logs? (I did a quick google search on "iptables descriptor", but nothing useful came up.)

    Yes, I figured I have to dig deeper in order to figure out the problem in more detail (and understand more about TCP/IP, in general). I have never done any packet sniffing; and at this moment, I don't have the spare time to teach myself how to do it. Nevertheless, thanks for the hints (tcpdump), so that I can come back to it later

    Best wishes,
    hasi

  9. #29
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    2,393
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: How can I shake off this guy ?

    Here are the corresponding lines of my iptables rules script:
    Code:
    # V1.02: Many packets here are due to forgotten connections. Try REJECT instead of DROP.
    $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "NEW TCP no SYN:" --log-level info
    #$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
    $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j REJECT
    It turns out, that my example and my explaination above was not so great. I went back and extracted the actual packets and it turns out there was never a TCP session that got forgotten. Here is the tcpdump capture that led to the syslog entries of my earlier post:
    Code:
    2013-05-12 16:42:19.581253 IP 72.52.5.67.80 > XXX.XXX.XXX.XXX.7315: Flags [.], ack 2636464277, win 1400, options [mss 512], length 0
    2013-05-12 16:42:19.581350 IP XXX.XXX.XXX.XXX > 72.52.5.67: ICMP XXX.XXX.XXX.XXX tcp port 7315 unreachable, length 52
    2013-05-12 16:42:19.995653 IP 72.52.5.67.80 > XXX.XXX.XXX.XXX.7315: Flags [.], ack 983077, win 1400, options [mss 512], length 0
    2013-05-12 16:42:19.995709 IP XXX.XXX.XXX.XXX > 72.52.5.67: ICMP XXX.XXX.XXX.XXX tcp port 7315 unreachable, length 52
    So, in this case it was just some IP address, port 80 either trying stuff, or replying to an original packet to it with a forged return address (my address). Actually the RST isn't set, so I was mis-stating my example anyhow.
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  10. #30
    Join Date
    Mar 2007
    Location
    Virginia
    Beans
    50
    Distro
    Kubuntu 12.04 Precise Pangolin

    Re: How can I shake off this guy ?

    @Doug S:

    Thanks so much!
    I like the "--log-prefix" and "--log-level" additions. Makes logs much easier to analyze... I will implement these things on the next overhaul of my scripts.

    I just ran a "sudo apt-get update", which gave me three more iptables log events of the same kind. The update servers responded without out any noticeable delay, as I was watching the process in the terminal with several repositories responding per second. Why did this start now? I don't remember changing any settings, and in the past month the firewall logs were really quite. Suddenly I get these events, simply when the daily updates are run. The machine in question is running kubuntu 12.04.

    I also found another interesting thing in the logs:
    Code:
    May 20 05:05:50 haseee kernel: [163194.895311] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36017 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK FIN URGP=0 OPT (0101080A026D650B82ED4B41)                                                                                                                                                                                                                       
    May 20 05:05:51 haseee kernel: [163195.120194] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36018 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026D654482ED4B41)                                                                                                                                                                                                                   
    May 20 05:05:51 haseee kernel: [163195.576271] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36019 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026D65B682ED4B41)                                                                                                                                                                                                                   
    May 20 05:05:52 haseee kernel: [163196.488261] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36020 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026D669A82ED4B41)                                                                                                                                                                                                                   
    May 20 05:05:54 haseee kernel: [163198.316260] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36021 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026D686382ED4B41)                                                                                                                                                                                                                   
    May 20 05:05:57 haseee kernel: [163201.968251] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36022 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026D6BF482ED4B41) 
    May 20 05:06:05 haseee kernel: [163209.280283] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36023 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026D731882ED4B41) 
    May 20 05:06:19 haseee kernel: [163223.904266] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36024 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026D816082ED4B41) 
    May 20 05:06:49 haseee kernel: [163253.152267] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36025 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026D9DF082ED4B41) 
    May 20 05:07:47 haseee kernel: [163311.584275] DROPPED IN= OUT=eth0 SRC=192.168.0.159 DST=91.189.91.14 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=36026 DF PROTO=TCP SPT=46243 DPT=80 SEQ=3658097242 ACK=3241237092 WINDOW=4538 RES=0x00 ACK PSH FIN URGP=0 OPT (0101080A026DD70082ED4B41)
    This is interesting, especially since 91.189.91.14 resolves to "orobas.canonical.com", so this must have been an automatic connection to an update server or so (if you go to orobas.canonical.com via browser, it looks like a repo).
    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.

Page 3 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •