Page 1 of 2 12 LastLast
Results 1 to 10 of 11
  1. #1
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,079

    Default buffer size limitation

    I've been tearing my hair out trying to figure out why Snort Drop rules based on packet content always fail (or perhaps more correctly, trying to figure out how to make them work). I think I finally figured it out: there's a buffer size limitation, and once the session gets bigger than the buffer, the packets flow through unmolested.

    The scenario is an SMTP AUTH attack by a botnet that always uses the string "EHLO ylmf-pc" to begin the SMTP conversation. So I wrote a rule to trigger on that string, and I also found basically the same rule here: https://forum.netgate.com/post/660007

    Code:
    drop tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP EHLO from ylmf-pc attempt"; threshold: type limit, track by_src, count 1, seconds 60; content:"ylmf-pc"; nocase; classtype:suspicious-login; sid:9000032; rev:2;)
    This rule is pretty basic, and has the logging limits typical of all stock Snort rules.. If it actually worked, I would tune it with limits so it only looks at packets with the right length, so that it's not wasting time looking at all SMTP packets.

    So with this rule in place, the "Blocked" events start counting up in Reports: IPS claims to be blocking these packets by the hundreds. However, the mail server log is still flooded with "ylmf-pc" sessions. A packet capture from Untangle reveals the failure:
    Code:
    16:14:15.439124 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [S], seq 3195578561, win 8192, options [mss 1440,nop,wscale 2,nop,nop,sackOK], length 0
    16:14:15.448667 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [S.], seq 4152073913, ack 3195578562, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    16:14:15.645958 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [.], ack 1, win 16560, length 0
    16:14:16.000653 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [P.], seq 1:132, ack 1, win 229, length 131: SMTP: 220 mail.mrmold.com GroupWise Internet Agent 18.0.2  Copyright (C) 1993-2018 Micro Focus Software Inc. All Rights Reserved. Ready
    16:14:16.197950 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 132, win 16527, length 14: SMTP: EHLO ylmf-pc
    16:14:16.497820 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [P.], seq 1:132, ack 1, win 229, length 131: SMTP: 220 mail.mrmold.com GroupWise Internet Agent 18.0.2  Copyright (C) 1993-2018 Micro Focus Software Inc. All Rights Reserved. Ready
    16:14:16.694461 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [.], ack 132, win 16527, options [nop,nop,sack 1 {1:132}], length 0
    16:14:16.886432 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 132, win 16527, length 14: SMTP: EHLO ylmf-pc
    16:14:17.093834 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [P.], seq 1:132, ack 1, win 229, length 131: SMTP: 220 mail.mrmold.com GroupWise Internet Agent 18.0.2  Copyright (C) 1993-2018 Micro Focus Software Inc. All Rights Reserved. Ready
    16:14:17.294467 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [.], ack 132, win 16527, options [nop,nop,sack 1 {1:132}], length 0
    16:14:18.169060 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 132, win 16527, length 14: SMTP: EHLO ylmf-pc
    16:14:18.283838 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [P.], seq 1:132, ack 1, win 229, length 131: SMTP: 220 mail.mrmold.com GroupWise Internet Agent 18.0.2  Copyright (C) 1993-2018 Micro Focus Software Inc. All Rights Reserved. Ready
    16:14:18.481020 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [.], ack 132, win 16527, options [nop,nop,sack 1 {1:132}], length 0
    16:14:20.684404 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 132, win 16527, length 14: SMTP: EHLO ylmf-pc
    16:14:20.684555 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [.], ack 15, win 229, length 0
    16:14:20.687138 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [P.], seq 132:202, ack 15, win 229, length 70: SMTP: 551 Verification of sending machine failed: no mail will be accepted
    16:14:20.687417 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [F.], seq 202, ack 15, win 229, length 0
    16:14:20.888438 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [.], ack 203, win 16509, length 0
    16:14:20.941058 IP 113.123.0.228.62875 > 216.237.4.245.25: Flags [F.], seq 15, ack 203, win 16509, length 0
    16:14:20.941178 IP 216.237.4.245.25 > 113.123.0.228.62875: Flags [.], ack 16, win 229, length 0
    You can see the "EHLO ylmf-pc" packet is dropped the first 3 times, and then goes through and the conversation completes. (90% of the IP's in this botnet have no PTR record, so the DNS verification fails))

    After looking at dozens of captures and finding it was ALWAYS 3 times, I got to thinking "Why 3 times? why not only 1, or 10, or 100?"

    I thought it might be some sort of buffer limit or overflow, so I figured if I turn off my verbose SMTP banner that will make the conversation smaller; if it's a buffer size limit, more attempts will fit before the buffer overflows. Witness:
    Code:
    16:04:30.204155 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [S], seq 1495882875, win 8192, options [mss 1440,nop,wscale 2,nop,nop,sackOK], length 0
    16:04:30.216073 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [S.], seq 3257190718, ack 1495882876, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    16:04:30.424584 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [.], ack 1, win 16560, length 0
    16:04:30.426527 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [P.], seq 1:28, ack 1, win 229, length 27: SMTP: 220 mail.mrmold.com Ready
    16:04:30.633116 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 28, win 16553, length 14: SMTP: EHLO ylmf-pc
    16:04:30.939790 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [P.], seq 1:28, ack 1, win 229, length 27: SMTP: 220 mail.mrmold.com Ready
    16:04:31.164524 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [.], ack 28, win 16553, options [nop,nop,sack 1 {1:28}], length 0
    16:04:31.387487 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 28, win 16553, length 14: SMTP: EHLO ylmf-pc
    16:04:31.567832 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [P.], seq 1:28, ack 1, win 229, length 27: SMTP: 220 mail.mrmold.com Ready
    16:04:31.803129 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [.], ack 28, win 16553, options [nop,nop,sack 1 {1:28}], length 0
    16:04:32.823829 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [P.], seq 1:28, ack 1, win 229, length 27: SMTP: 220 mail.mrmold.com Ready
    16:04:32.881446 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 28, win 16553, length 14: SMTP: EHLO ylmf-pc
    16:04:33.031453 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [.], ack 28, win 16553, options [nop,nop,sack 1 {1:28}], length 0
    16:04:35.335819 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [P.], seq 1:28, ack 1, win 229, length 27: SMTP: 220 mail.mrmold.com Ready
    16:04:35.565087 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [.], ack 28, win 16553, options [nop,nop,sack 1 {1:28}], length 0
    16:04:35.848568 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 28, win 16553, length 14: SMTP: EHLO ylmf-pc
    16:04:40.367821 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [P.], seq 1:28, ack 1, win 229, length 27: SMTP: 220 mail.mrmold.com Ready
    16:04:40.577930 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [.], ack 28, win 16553, options [nop,nop,sack 1 {1:28}], length 0
    16:04:41.152524 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [F.], seq 15, ack 28, win 16553, length 0
    16:04:41.152710 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [.], ack 1, win 229, options [nop,nop,sack 1 {15:16}], length 0
    16:04:41.658309 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [FP.], seq 1:15, ack 28, win 16553, length 14: SMTP: EHLO ylmf-pc
    16:04:41.661622 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [P.], seq 28:98, ack 16, win 229, length 70: SMTP: 551 Verification of sending machine failed: no mail will be accepted
    16:04:41.661958 IP 216.237.4.245.25 > 125.72.232.187.64112: Flags [F.], seq 98, ack 16, win 229, length 0
    16:04:41.886109 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [R.], seq 16, ack 98, win 0, length 0
    16:04:41.889392 IP 125.72.232.187.64112 > 216.237.4.245.25: Flags [R], seq 1495882891, win 0, length 0
    so, yes, now with the smaller SMTP banner, Snort drops 5 packets before giving up. 5 packets every single time. (in both instances I can only post one SMTP conversation due to forum post length limits)

    So, Untangle's Snort implementation has a buffer problem (or something along those lines), which makes rules that use the content of the packets completely ineffective for Drop rules. I worry that if the same architecture is used for the upcoming Suricata implementation in 14.1, then the same problem will carry over.
    Sam Graf and donhwyo like this.

  2. #2
    Master Untangler
    Join Date
    Feb 2016
    Location
    Michigan
    Posts
    607

    Default

    Thank you for all your efforts on this matter.
    Kkorkky and donhwyo like this.

  3. #3
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,079

    Default

    Quote Originally Posted by Sam Graf View Post
    Thank you for all your efforts on this matter.
    my efforts appear to be in vain however

  4. #4
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,079

    Default

    A small consolation so far is that putting in the block rule, even though it doesn't actually block anything, does slow down the attack a bit so that I'm getting fewer total ylmf-pc hits. You can see in the packet captures above that the TCP retries consume 5-7 seconds, so the whole SMTP conversation goes from a second or two with no interference to as much as 11 seconds. That ties up more SMTP receive threads on my server, but doesn't seem to be causing any problem and hopefully exacts some small penalty on the botnet - the more time it spends on each failed attempt, the fewer total attacks it can execute.

    stats from recent days:

    sept 10 - 92,121 ylmf-pc hits (no blocking, and this total has been typical)
    sept 11 - 68,036 ylmf-pc hits ("blocking" for part of the day)
    sept 12 - 43,336 ylmf-pc hits ("blocking" all day)
    sept 13 - 45,112 ylmf-pc hits ("blocking" all day)
    9 hours of today - 15,189 ylmf-pc hits (on pace to match the last 2 days)
    Last edited by johnsonx42; 09-14-2018 at 11:03 AM.

  5. #5
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,079

    Default

    argh, spoke to soon... after posting that, I asked myself "how do I know tying up extra SMTP receive threads isn't causing me a problem?"

    turns out, it is causing a problem. I ran a 2-minute packet capture and caught 12 of these:
    Code:
    09:04:44.758791 IP 125.106.129.107.60517 > 216.237.4.245.25: Flags [S], seq 3928291042, win 8192, options [mss 1440,nop,wscale 2,nop,nop,sackOK], length 0
    09:04:44.768479 IP 216.237.4.245.25 > 125.106.129.107.60517: Flags [S.], seq 3552772546, ack 3928291043, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    09:04:44.953912 IP 125.106.129.107.60517 > 216.237.4.245.25: Flags [.], ack 1, win 16560, length 0
    09:04:44.956499 IP 216.237.4.245.25 > 125.106.129.107.60517: Flags [P.], seq 1:58, ack 1, win 229, length 57: SMTP: 421 Service not available, closing transmission channel
    09:04:44.956877 IP 216.237.4.245.25 > 125.106.129.107.60517: Flags [.], seq 58:2938, ack 1, win 229, length 2880: SMTP: 21 Service not available, closing transmission channel
    09:04:44.957443 IP 216.237.4.245.25 > 125.106.129.107.60517: Flags [.], seq 2938:5818, ack 1, win 229, length 2880: SMTP
    09:04:44.958643 IP 216.237.4.245.25 > 125.106.129.107.60517: Flags [FP.], seq 5818:8249, ack 1, win 229, length 2431: SMTP
    09:04:45.145871 IP 125.106.129.107.60517 > 216.237.4.245.25: Flags [.], ack 1498, win 16560, length 0
    09:04:45.145971 IP 125.106.129.107.60517 > 216.237.4.245.25: Flags [.], ack 4378, win 16560, length 0
    09:04:45.146007 IP 125.106.129.107.60517 > 216.237.4.245.25: Flags [.], ack 7258, win 16560, length 0
    09:04:45.146039 IP 125.106.129.107.60517 > 216.237.4.245.25: Flags [.], ack 8250, win 16312, length 0
    09:04:45.150255 IP 125.106.129.107.60517 > 216.237.4.245.25: Flags [R.], seq 1, ack 8250, win 0, length 0
    So the attack total is likely lessened only because I'm now running out of SMTP receive threads all the time. I'm not noticing legit email being delayed, but I'm sure it's happening; the mail server itself doesn't log these unless I turn on full diagnostic logging, and I've only been on Verbose so I can't tell how much this has happened the last few days (~8000 times per day wouldn't be a bad guess though, if I caught 12 in two minutes).

    Yes, of course I can just add more SMTP receive threads, as they're just idle most of the time it won't hurt the server, but that won't really help anything. If the blocking actually worked, yes, I'd have a pile of idle SMTP threads waiting to time out, but then increasing the thread total would actually help. At this point I may as well just delete the "EHLO ylmf-pc" drop rule, it ultimately is doing nothing.

    Too bad I don't have a firewall sitting between my mail server and the internet that could do something about this.
    Last edited by johnsonx42; 09-14-2018 at 09:23 AM.

  6. #6
    Master Untangler
    Join Date
    May 2008
    Posts
    827

    Default

    Could you just port forward that to null or a bad ip? Or back on itself?

  7. #7
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,079

    Default

    Quote Originally Posted by donhwyo View Post
    Could you just port forward that to null or a bad ip? Or back on itself?
    the attack comes from 100's of different IP's, always changing. Here's the top 20 for today; the first number is how many hits for that IP:

    416 125.123.137.248
    412 113.123.32.99
    365 182.38.26.139
    356 125.123.136.146
    315 171.13.115.88
    315 125.106.250.252
    312 125.72.232.160
    302 113.121.244.222
    296 140.250.99.177
    291 115.207.5.74
    288 1.198.179.102
    281 125.72.232.23
    275 140.250.99.147
    272 125.72.232.89
    263 123.169.37.217
    253 123.54.131.226
    247 125.72.232.175
    242 119.7.249.182
    240 182.38.29.232
    233 125.123.143.105

    my logs show this week the attack has come from at least 483 different IP's
    Last edited by johnsonx42; 09-14-2018 at 11:58 AM.

  8. #8
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,079

    Default

    another weird bug I stumbled across, though this one has nothing to do with the IPS module..

    In the packet capture above showing the "421 Service Unavailable" response, I was puzzled by why the response was repeated again with the "4" removed, "21 Service Unavailable". Was this a bug in the mail server?

    No...

    Capture from LAN side:
    Code:
    08:46:58.557447 IP 185.111.75.160.43415 > 192.168.27.11.25: Flags [S], seq 3041934653, win 29200, options [mss 1460,sackOK,TS val 2709765645 ecr 0,nop,wscale 7], length 0
    08:46:58.557911 IP 192.168.27.11.25 > 185.111.75.160.43415: Flags [S.], seq 711178300, ack 3041934654, win 14480, options [mss 1460,sackOK,TS val 2326528588 ecr 2709765645,nop,wscale 7], length 0
    08:46:58.558055 IP 185.111.75.160.43415 > 192.168.27.11.25: Flags [.], ack 1, win 229, options [nop,nop,TS val 2709765646 ecr 2326528588], length 0
    08:46:58.558452 IP 192.168.27.11.25 > 185.111.75.160.43415: Flags [P.], seq 1:59, ack 1, win 114, options [nop,nop,TS val 2326528588 ecr 2709765646], length 58: SMTP: 421 Service not available, closing transmission channel
    08:46:58.558555 IP 185.111.75.160.43415 > 192.168.27.11.25: Flags [.], ack 59, win 229, options [nop,nop,TS val 2709765646 ecr 2326528588], length 0
    08:46:58.558577 IP 192.168.27.11.25 > 185.111.75.160.43415: Flags [F.], seq 59, ack 1, win 114, options [nop,nop,TS val 2326528588 ecr 2709765646], length 0
    08:46:58.597783 IP 185.111.75.160.43415 > 192.168.27.11.25: Flags [.], ack 60, win 229, options [nop,nop,TS val 2709765686 ecr 2326528588], length 0
    08:46:59.275251 IP 185.111.75.160.43415 > 192.168.27.11.25: Flags [F.], seq 1, ack 60, win 229, options [nop,nop,TS val 2709766363 ecr 2326528588], length 0
    08:46:59.275666 IP 192.168.27.11.25 > 185.111.75.160.43415: Flags [.], ack 2, win 114, options [nop,nop,TS val 2326528767 ecr 2709766363], length 0
    No second message. But from the WAN side, same exact conversation:
    Code:
    08:46:58.551307 IP 185.111.75.160.43415 > 216.237.4.245.25: Flags [S], seq 3867307278, win 14100, options [mss 1410,sackOK,TS val 2159891131 ecr 0,nop,wscale 7], length 0
    08:46:58.561891 IP 216.237.4.245.25 > 185.111.75.160.43415: Flags [S.], seq 4212306836, ack 3867307279, win 28960, options [mss 1460,sackOK,TS val 2709765650 ecr 2159891131,nop,wscale 7], length 0
    08:46:58.894797 IP 185.111.75.160.43415 > 216.237.4.245.25: Flags [.], ack 1, win 111, options [nop,nop,TS val 2159891472 ecr 2709765650], length 0
    08:46:58.897338 IP 216.237.4.245.25 > 185.111.75.160.43415: Flags [P.], seq 1:58, ack 1, win 227, options [nop,nop,TS val 2709765985 ecr 2159891472], length 57: SMTP: 421 Service not available, closing transmission channel
    08:46:58.897767 IP 216.237.4.245.25 > 185.111.75.160.43415: Flags [.], seq 58:2854, ack 1, win 227, options [nop,nop,TS val 2709765985 ecr 2159891472], length 2796: SMTP: 21 Service not available, closing transmission channel
    08:46:58.898308 IP 216.237.4.245.25 > 185.111.75.160.43415: Flags [.], seq 2854:5650, ack 1, win 227, options [nop,nop,TS val 2709765986 ecr 2159891472], length 2796: SMTP
    08:46:58.899474 IP 216.237.4.245.25 > 185.111.75.160.43415: Flags [FP.], seq 5650:8249, ack 1, win 227, options [nop,nop,TS val 2709765986 ecr 2159891472], length 2599: SMTP
    08:46:59.274418 IP 185.111.75.160.43415 > 216.237.4.245.25: Flags [.], ack 58, win 111, options [nop,nop,TS val 2159891832 ecr 2709765985], length 0
    08:46:59.274491 IP 185.111.75.160.43415 > 216.237.4.245.25: Flags [R.], seq 1, ack 58, win 111, options [nop,nop,TS val 2159891832 ecr 2709765985], length 0
    08:46:59.274516 IP 185.111.75.160.43415 > 216.237.4.245.25: Flags [R], seq 3867307279, win 0, length 0
    08:46:59.274538 IP 185.111.75.160.43415 > 216.237.4.245.25: Flags [R], seq 3867307279, win 0, length 0
    08:46:59.274559 IP 185.111.75.160.43415 > 216.237.4.245.25: Flags [R], seq 3867307279, win 0, length 0
    so the Untangle VM is injecting the "21 Service Unavailable" message somewhere. Why? No idea.

    Does it matter? well, no idea again; in and of itself, this second message could be considered cosmetic. BUT: there's a bug here, what else is it doing?

    (EDIT: Actually on closer examination, I see the "21 Service unavailable" message isn't really a second response, but part of a bunch of garbage appended to the initial response; from the mail server, the original version of the message is 58 bytes in a single packet - seq 1:59 followed by an ack from the other side. But in the version coming out of the Untangle VM, the initial part is 1 byte shorter - seq 1:58, which is then followed by 2 additional packets of length 2796 (seq 58:2854 and 2854:5640) and then a final packet of length 2599 (seq 5650:8249). This extra data is the "21 Service not available, closing transmission channel" followed by what I presume is 8,135 NULs

    This is weird.)
    Last edited by johnsonx42; 09-15-2018 at 09:59 AM.
    Sam Graf likes this.

  9. #9
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,079

    Default

    The new version of IPS in 14.1 actually works!

    Signature:
    Code:
    reject tcp any any -> any 25 (msg:"ylmf-pc";classtype:unknown;sid:1999999;gid:1;content:"EHLO ylmf-pc";nocase;)
    TCPDUMP from WAN side:
    Code:
    12:23:51.926025 IP 140.250.117.17.61903 > 216.237.4.245.25: Flags [S], seq 4051863863, win 8192, options [mss 1440,nop,wscale 2,nop,nop,sackOK], length 0
    12:23:51.930253 IP 216.237.4.245.25 > 140.250.117.17.61903: Flags [S.], seq 2402575175, ack 4051863864, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    12:23:52.114892 IP 140.250.117.17.61903 > 216.237.4.245.25: Flags [.], ack 1, win 16560, length 0
    12:23:52.117043 IP 216.237.4.245.25 > 140.250.117.17.61903: Flags [P.], seq 1:28, ack 1, win 229, length 27: SMTP: 220 mail.mrmold.com Ready
    12:23:52.300840 IP 140.250.117.17.61903 > 216.237.4.245.25: Flags [P.], seq 1:15, ack 28, win 16553, length 14: SMTP: EHLO ylmf-pc
    12:23:52.306524 IP 216.237.4.245.25 > 140.250.117.17.61903: Flags [R.], seq 28, ack 15, win 16553, length 0
    12:23:52.594807 IP 216.237.4.245.25 > 140.250.117.17.61903: Flags [P.], seq 1:28, ack 1, win 229, length 27: SMTP: 220 mail.mrmold.com Ready
    12:23:52.778002 IP 140.250.117.17.61903 > 216.237.4.245.25: Flags [R], seq 4051863864, win 0, length 0
    TCPDUMP from LAN side (what the mail server actually sees):
    Code:
    12:23:51.928953 IP 140.250.117.17.61903 > 192.168.27.11.25: Flags [S], seq 3722919950, win 29200, options [mss 1460,sackOK,TS val 4220211721 ecr 0,nop,wscale 7], length 0
    12:23:51.929394 IP 192.168.27.11.25 > 140.250.117.17.61903: Flags [S.], seq 4078641965, ack 3722919951, win 14480, options [mss 1460,sackOK,TS val 467706149 ecr 4220211721,nop,wscale 7], length 0
    12:23:51.929538 IP 140.250.117.17.61903 > 192.168.27.11.25: Flags [.], ack 1, win 229, options [nop,nop,TS val 4220211721 ecr 467706149], length 0
    12:23:51.933922 IP 192.168.27.11.25 > 140.250.117.17.61903: Flags [P.], seq 1:28, ack 1, win 114, options [nop,nop,TS val 467706150 ecr 4220211721], length 27: SMTP: 220 mail.mrmold.com Ready
    12:23:51.934003 IP 140.250.117.17.61903 > 192.168.27.11.25: Flags [.], ack 28, win 229, options [nop,nop,TS val 4220211726 ecr 467706150], length 0
    12:23:52.779079 IP 140.250.117.17.61903 > 192.168.27.11.25: Flags [F.], seq 1, ack 28, win 229, options [nop,nop,TS val 4220212571 ecr 467706150], length 0
    12:23:52.779701 IP 140.250.117.17.61903 > 192.168.27.11.25: Flags [R.], seq 2, ack 28, win 229, options [nop,nop,TS val 4220212571 ecr 467706150], length 0
    12:23:52.779804 IP 192.168.27.11.25 > 140.250.117.17.61903: Flags [F.], seq 28, ack 2, win 114, options [nop,nop,TS val 467706361 ecr 4220212571], length 0
    the server never even sees the "EHLO ylmf-pc" greeting.
    Last edited by johnsonx42; 11-21-2018 at 01:46 PM.
    JasonJoel likes this.

  10. #10
    Master Untangler cblaise's Avatar
    Join Date
    Jul 2014
    Location
    Burlington, VT
    Posts
    116

    Default

    Nice!

Page 1 of 2 12 LastLast

Posting Permissions

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

SEO by vBSEO 3.6.0 PL2