grsecurity forums

by **spender** » Tue Apr 24, 2012 10:13 am

What version of curl is this?

-Brad

by **mnalis** » Tue Apr 24, 2012 6:19 pm

It is (mostly) Debian Squeeze, so:

phpinfo() says:

by **timbgo** » Sat May 28, 2016 12:28 pm

mnalis wrote:I'm (sometimes) getting strange "ghost" udp/80 connections in addition to regular tcp/80 ones, has anyone seen this?

udp/0 connections here sometimes.

Now, I don't think udp/0 is normally allowed port anyway...

I guess so too.

Anyway I've looked over and the sites in question do not seem to be cracked.

I browse little, untill I learn to really read the net that I access... developer.mozilla.org
( precisely this location:
https://developer.mozilla.org/en-US/App ... TML5_video
)
that I was tried to view the video with Webvtt capture/subtitle (studying it yet), is likely not cracked...
Those devs are among the best in the world... and still, to my understanding mostly FOSS-faithful, so to say.
(
But it's a few other sites that I had opened, to report fully.... And it could be some of those other sites (just a handful altogether there)... Have some of it in the traffic dump and in the accompanying screencast, in case I go and analyze in depth...
)

Any ideas about what may be the problem? I tried allowing them through grsec, but only udp packets that tcpdump sees are standard udp/53 DNS

Instead of this:

and my udp/514 remote syslog and udp/161 snmp queries,

I don't have anything outside of the single host, which is air-gapped away from my SOHO, only plug-in to aDSL router and dump traffic, and plug off.

none of this 0.0.0.0 udp/0 or udp/80 "ghost" stuff.

I guess it wouldn't be a good idea to allow port 0 udp...

Is this a possible glitch in grsecurity patch?

This is what I get in my logs:

Code: Select all: May 28 16:15:36 g0n kernel: [184729.388178] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.148.84.95 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~er #122:30151] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3230] uid/euid:1000/1000 gid/egid:1000/1000 May 28 16:15:36 g0n kernel: [184729.388194] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.69.143.151 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~er #122:30151] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3230] uid/euid:1000/1000 gid/egid:1000/1000 May 28 16:15:37 g0n kernel: [184729.637906] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.69.143.151 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~er #121:30150] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3230] uid/euid:1000/1000 gid/egid:1000/1000 May 28 16:15:37 g0n kernel: [184729.637916] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.148.84.95 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~er #121:30150] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3230] uid/euid:1000/1000 gid/egid:1000/1000

Doing this command I get what that ip was during that bout of mine online:

Code: Select all: $ tshark -r dump_160528_1609_g0n.pcap -qz hosts | grep 54.69.143.151 54.69.143.151 www.sitepoint.com $

If the analyzing more of what happened when I got those denied connect lines the way to go, I can analyze more and tell more.
I always keep an eye on logs, and that happened when I tried to play the video on that:
https://developer.mozilla.org/en-US/App ... TML5_video
address.
(
Actually that sitepoint.com must be an alias for developer.mozilla.org as I got the same few lines just now, as I was checking the link in preview here on the grsec forum:

Code: Select all: May 28 18:21:58 g0n kernel: [192310.895870] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.230.46.161 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~er #127:1937] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3230] uid/euid:1000/1000 gid/egid:1000/1000

)
I have some positive experience with Mozilla devs (gave me really great advice, on their mailing list), and I can ask them as well.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)

by **timbgo** » Sun May 29, 2016 1:46 pm

A quick (and partial) diagnose of the (likely) issue that occurred in my case here. Will probably be similarly so for some of the readers.

(It took me an entire day to figure this... should have cleared the cache right away...)

I'm a little hesitant to put this here, because grsec only features in this post as the guardian whom we can thank for what we discovered, but nothing more technical about grsec below (just a few more logs).

It's very probably some of the links from Firefox cache, because after I did:

Code: Select all: $ rm -rf /home/miro/.cache/mozilla/firefox/<salt>.default/*

I can browse, and post and all, it seems (only yet started, won't be back to tell about it if what I assume here is right).

Because I restored from backup my entire online clone system (and it is clean from backup).

To get it up to date, I rsync back in what I need from the dump of the system as it was before the backup, when last I was online, such as:

the mail
other data
and...

And also, I wanted Firefox history and bookmarks this time around, which I know are in the /home/<user> (somewhat more selectively than the line below, but I give that line for simplicity), and so I actually resynced, selectively, the whole /home/<user>

Code: Select all: # rsync -av /dirty-long-time-online-system-dump/home/user/ /new-from-backup/home/user/

and that got the Firefox cache and all.

And I tried to post, this morning at these forums, and lo and behold:

Code: Select all: May 29 15:37:29 g0n kernel: [ 7823.362237] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.69.136.250 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:37:29 g0n kernel: [ 7823.362276] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.191.85.92 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:37:29 g0n kernel: [ 7823.362306] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.149.54.54 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:37:30 g0n kernel: [ 7824.566717] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 52.36.105.160 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:37:58 g0n kernel: [ 7852.377330] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.230.46.166 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:37:58 g0n kernel: [ 7852.377341] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.230.46.8 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:37:58 g0n kernel: [ 7852.377348] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.230.46.160 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:37:58 g0n kernel: [ 7852.377355] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.230.46.168 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:38:22 g0n kernel: [ 7876.492185] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 23.53.187.27 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:38:27 g0n kernel: [ 7882.212479] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 63.245.213.48 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #2:4595] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:38:27 g0n kernel: [ 7882.212518] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 63.245.213.49 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #2:4595] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 29 15:38:27 g0n kernel: [ 7882.212548] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 63.245.213.47 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #2:4595] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000

And I can tell you those are all legal! So why are they breaking my system, because the message was soon, upon a few previews of the:

Re: Legal Support
viewtopic.php?f=3&t=4262&p=16331#p16331
(which I only now was able to post)

...the message was, let me tell (I can see it from the screencast (http://github.com/miroR/uncenz):

Secure Connection Failed
The connection to the server was reset while the page was loading.
* The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
* Please contact the website owners to inform them of the problem.

And let me tell why those are legal ip's.

They are these:

Code: Select all: $ cat denied_connect.ls-1 54.69.136.250 54.191.85.92 54.149.54.54 52.36.105.160 54.230.46.166 54.230.46.8 54.230.46.160 54.230.46.168 23.53.187.27 63.245.213.48 63.245.213.49 63.245.213.47 $

(got then by simply grep'ing and sed'ing and such).
And the dump_160529_1536_g0n.hosts is the hosts gotten as I explained in the previous post to this.

And so:

Code: Select all: $ for i in $(cat denied_connect.ls-1); do grep $i dump_160529_1536_g0n.hosts ; done ; 54.69.136.250 search.r53-2.services.mozilla.com 54.191.85.92 search.r53-2.services.mozilla.com 54.149.54.54 search.r53-2.services.mozilla.com 52.36.105.160 shavar.prod.mozaws.net 54.230.46.166 dcky6u1m8u6el.cloudfront.net 54.230.46.8 dcky6u1m8u6el.cloudfront.net 54.230.46.82 dcky6u1m8u6el.cloudfront.net 54.230.46.160 dcky6u1m8u6el.cloudfront.net 54.230.46.168 dcky6u1m8u6el.cloudfront.net 23.53.187.27 e8218.dscb1.akamaiedge.net 63.245.213.48 aus5.external.zlb.scl3.mozilla.com 63.245.213.49 aus5.external.zlb.scl3.mozilla.com 63.245.213.47 aus5.external.zlb.scl3.mozilla.com

So, since after cleaning the cache I can browse, post and all, it's probably an issue, in my case, with Firefox cache.

And it happened so bad, that my SSLKEYLOGFILE (see Wireshark websites for what that is, a note for inexperienced users) wasn't logging keys anymore... (Now it does again. Will be back if some of what I wrote here does not hold true.)

Regards!
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)

by **timbgo** » Tue May 31, 2016 7:24 am

Of course, that was earlier than that post, in the afternoon, and not in the morning:

timbgo wrote:And I tried to post, this morning at these forums, and lo and behold:

Code: Select all
May 29 15:37:29 g0n kernel: [ 7823.362237] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 54.69.136.250 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Resolver #1:4556] uid/euid:1000/1000 gid/egid:1000/1000, ....

And surely, if any reader wants to try and do:

Code: Select all: $ rm -rf /home/miro/.cache/mozilla/firefox/<salt>.default/*

they need to quit firefox first.

There is a stump report with a " port 0 " issue over at:

Mailing List Archive: Gentoo: Hardened
Remote ssh attack: sshd tries to make udp connection to a remote host
http://www.gossamer-threads.com/lists/g ... ?page=last
by atoth at atoth
Dec 29, 2007, 10:11 AM

And, sadly, this issue has not been solved for me here. Whereever I connect, I still get those "denied connect() to port 0 " lines.

Regards!
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)

by **timbgo** » Thu Jun 02, 2016 3:13 pm

NOTICE:. I had forgot to post the keys so that the traces can be decrypted. The keys are now uploaded.
The dLo.sh contains the:
dump_160531_2xxx_SSLKEYLOGFILE.txt file with all the necessary keys, and then when you give the Wireshark or the Tshark the option:

Code: Select all: -o "ssl.keylog_file: dump_160531_2xxx_SSLKEYLOGFILS.txt"

such as the line below that starts:

Code: Select all: tshark -r dump_160531_2119_g0n.pcap ...

change it to:

Code: Select all: tshark -o "ssl.keylog_file: dump_160531_2xxx_SSLKEYLOGFILS.txt" -r dump_160531_2119_g0n.pcap ...

and you'll see all the traffic...
Pls. note that you need to add that option after every tshark... or wireshark... for the commands in this and the next post to workl.
I don't need the -o "ssl.keylog_file: ..." option because I got the SSLKEYLOGFILE environement variable set up and Firefox is logging keys into it... And so I forgot.
See: https://wiki.wireshark.org/SSL
---

Excerpt from my /var/log/messages:

Code: Select all: messages_160531_2300_g0n

(
at this point make sure you download, first the:
http://www.croatiafidelis.hr/foss/cap/c ... t-0/dLo.sh
then:

Code: Select all: chmod 755 dLo.sh ./dLo.sh

That should get you all the files.
)

Code: Select all: $ grep ' port 0 ' messages_160531_2300_g0n | wc -l 74 $

The logs cover my three short intervals on the internet, traces of which are in:

Code: Select all: dump_160531_2119_g0n.pcap dump_160531_2145_g0n.pcap dump_160531_2253_g0n.pcap

The first two I cut out just the packets/frames containing my registering and my login attempts (only last successful) at forums.palemoon.org ,

Code: Select all: tshark -r dump_160531_2119_g0n.pcap -Y \ '!(frame.number in {4427 9945 10181 10461 10740})' \ -w dump_160531_2119_g0n_noRegister_noLogin.pcap

Code: Select all: tshark -r dump_160531_2145_g0n.pcap -Y '!(frame.number in {34 681})' -w \ dump_160531_2145_g0n_noLogin.pcap

So there is just respectively five packets (in stream 94) and two packets (in
stream 0) missing in:

Code: Select all: dump_160531_2119_g0n_noRegister_noLogin.pcap dump_160531_2145_g0n_noLogin.pcap

which I offer instead of the full traces for obvious reasons.

I've been studying this issue since I posted about it some three days ago:

Re: php-cgi and nonexisting connections to udp/80 (and udp/0
viewtopic.php?f=3&t=2951&start=15#p16324
(that's this very topic you're reading this post at ;-)

)

, and I decided I will compare the grsec denied connect lines, such as, e.g.:

Code: Select all: May 31 21:20:01 g0n kernel: [201257.097438] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 96.45.83.209 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~ver #10:28767] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 from the messages_160531_2300_g0n, with what happened online at those aproximate moments (in the above line at May 31 21:20:01 CET which is May 31 19:20:01 GMT) with those traces. To be able to do that more easily I'll be converting the times in the logs excerpts, one operation per each traffic trace, to the offset from the time of the execution of my (primitive) program uncenz ( http://github.com/miroR/uncenz ) which starts dumpcap and ffmpeg screencasting when it is executed, corrected for the time that is recorded in the traces as the 0 time, the start time, which is usually 5 to 6 seconds later. Reason: I first start the uncenz-1st script and then I manually plug into the socket of my aDSL router. That or something additional along it, makes for that different start time in the traces, I think.

According to:

Code: Select all: $ capinfos dump_160531_2???_g0n.pcap | grep -E 'File name|packet time' File name: dump_160531_2119_g0n.pcap First packet time: 2016-05-31 21:19:50.373249619 Last packet time: 2016-05-31 21:27:05.371101231 File name: dump_160531_2145_g0n.pcap First packet time: 2016-05-31 21:46:04.501589864 Last packet time: 2016-05-31 21:51:36.221933010 File name: dump_160531_2253_g0n.pcap First packet time: 2016-05-31 22:53:24.966980372 Last packet time: 2016-05-31 23:00:15.913225176 $

and also by the uncenz-1st exec lines (where the messages_160531_2300_g0n_2???_section I had manually cut out from messages_160531_2300_g0n):

Code: Select all: $ head -1 messages_160531_2300_g0n_2???_section ==> messages_160531_2300_g0n_2119_section <== May 31 21:19:44 g0n kernel: [201240.450830] grsec: (miro:U:/) exec of /usr/local/bin/uncenz-1st (uncenz-1st ) by /usr/local/bin/uncenz-1st[bash:28624] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3287] uid/euid:1000/1000 gid/egid:1000/1000 ==> messages_160531_2300_g0n_2145_section <== May 31 21:45:59 g0n kernel: [202815.613220] grsec: (miro:U:/) exec of /usr/local/bin/uncenz-1st (uncenz-1st ) by /usr/local/bin/uncenz-1st[bash:32285] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3287] uid/euid:1000/1000 gid/egid:1000/1000 ==> messages_160531_2300_g0n_2253_section <== May 31 22:53:20 g0n kernel: [206856.753220] grsec: (miro:U:/) exec of /usr/local/bin/uncenz-1st (uncenz-1st ) by /usr/local/bin/uncenz-1st[bash:32729] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3287] uid/euid:1000/1000 gid/egid:1000/1000 $

As I said, I cut out three chunks from the messages_160531_2300_g0n (and I let the start in each be when I start that uncenz-1st script that starts dumpcap and let the end be when there is "carrier lost", that is when I manually unplug the socket). Find all the files in the download, or complain if any are missing, pls!

I just rewrote yet another time the dirty hhmmss2sec script (which stands for hh mm ss to seconds).

I ran it like this:

Code: Select all: $ ./hhmmss2sec messages_160531_2300_g0n_2119_section 21:19:44 6 $ ./hhmmss2sec messages_160531_2300_g0n_2145_section 21:45:59 5 $ ./hhmmss2sec messages_160531_2300_g0n_2253_section 22:53:20 5

(These may take a while. Slow bash. Dirty clumsy script.)

If you've downloaded as above suggested, you can check all the steps that I posted in this and in the next post.

and I used Vim to replace the "May 31 <hh:mm:ss>" visual block (after I selected it; figure out how to do it in your favorite editor) with the sec_rel block which I got for each logs_section separately (pls. read the script hhmmss2sec), and that got me:

Code: Select all: messages_160531_2300_g0n_2119_section_in_sec messages_160531_2300_g0n_2145_section_in_sec messages_160531_2300_g0n_2253_section_in_sec

which are also in the download for clarity.

Now I can compare what happened in the traces with the "grsec denied connect() to... port 0 " lines much more easily, and it will likely be a sufficiently close approximation (not even decimals --let alone nanoseconds-- in my logs, which is imprecise in comparison with how Wireshark records the timing, but I'm still so much closer than without this work on the logs).

I can now try and grep out only ' port 0 ' lines from each of the: messages_160531_2300_g0n_2???_section_in_sec separately.

And I'll call them:

Code: Select all: messages_160531_2300_g0n_2???_section_in_sec_port_0

I was even starting to think it could have been a legitimate "port 0" call, in the sense of some of the:

Cyber Security Awareness Month - Day 2 - Port 0
https://isc.sans.edu/diary/Cyber+Securi ... ort+0/7216

TCP/UDP Port 0
http://compnetworking.about.com/od/tcpi ... bers-0.htm

but especially (this one is a great read!):

August 28, 2013
The Strange History of Port 0 (by Jim MacLeod)
http://www.lovemytool.com/blog/2013/08/ ... cleod.html

and the links from there! Such as:

NANOG: users
DDoS using port 0 and 53 (DNS)
http://www.gossamer-threads.com/lists/n ... ers/155141
Jul 24, 2012

and further links:

NANOG: users
Attack/DoS
http://www.gossamer-threads.com/lists/nanog/users/18990
Jun 3, 1998

Jim MacLeod especially stressed on:

North American Network Operators Group
Port 0 traffic
http://www.nanog.org/mailinglist/mailar ... 00091.html
Date: Fri Apr 08 15:10:12 2005

I've reached yesterday, or was it the day before?, at starting to even suspect that grsec is denying something here which it should not. Especially after reading that McLeod's page (which I'm not even finished with reading, and to be honest: understanding it more fully, nor all the links of). And the 2005 link above. But after long perusal of the traces and the logs, I think Firefox should not be connecting the udp port 0 way where tcp normal ways is due... But find out more about that in the next post (that I've already prepared; it's proofreading time when I'm writing this line).

I can try and analyze with tshark and the logs that I set up for easier reference and comparison with the traces... on another page, by some of those "denied connect... port 0" lines, starting from the first entries for the first trace.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)

by **timbgo** » Thu Jun 02, 2016 3:27 pm

For each of the dump_160531_2???_g0n.pcap I make a:

Code: Select all: tshark -r dump_160531_2XXX_g0n.pcap -qz hosts > dump_160531_2XXX_g0n.hosts

(
Also In the previous post, so that newbies don't get lost, I forgot to give the
line:

Code: Select all: $ cat messages_160531_2300_g0n_2119_section_in_sec | grep ' port 0 ' > \ messages_160531_2300_g0n_2119_section_in_sec_port_0

)

And now:

Code: Select all: $ for i in $(cat messages_160531_2300_g0n_2119_section_in_sec_port_0 | sed \ 's/.*denied connect() to $.*$ port 0 .*/\1/'); do grep $i \ dump_160531_2119_g0n.hosts ; read FAKE; done ;

(
newbies, that's just a bash loop, see what the alone:

Code: Select all: $ cat messages_160531_2300_g0n_2119_section_in_sec_port_0 | sed \ 's/.*denied connect() to $.*$ port 0 .*/\1/'

does for you first.
)

So, that gets me:

Code: Select all: 96.45.83.209 ddg.gg 96.45.83.40 ddg.gg 96.45.82.53 ddg.gg 96.45.82.134 ddg.gg 216.58.214.206 encrypted-tbn0.gstatic.com 216.58.214.225 tpc.googlesyndication.com 216.58.214.227 www.gstatic.com 74.125.206.103 www.google.com 216.58.214.206 encrypted-tbn0.gstatic.com 63.245.213.49 aus5.external.zlb.scl3.mozilla.com 63.245.213.47 aus5.external.zlb.scl3.mozilla.com 63.245.213.48 aus5.external.zlb.scl3.mozilla.com 104.20.54.69 forum.palemoon.org 104.20.55.69 forum.palemoon.org 216.58.209.194 googleads.g.doubleclick.net 216.58.209.194 googleads.g.doubleclick.net 216.58.209.194 googleads.g.doubleclick.net 104.20.55.69 forum.palemoon.org 104.20.54.69 forum.palemoon.org 104.20.54.69 forum.palemoon.org 104.20.55.69 forum.palemoon.org

It get's me nothing for local ip's, the 127.0.0.1 and 192.168.3.4 (even though it's not on the SOHO, this box has an address as if it were, but this is an Air-Gapped online-only no-SOHO box, clone of the master Air-Gap which is on the SOHO). Local ip's are not gotten from the trace, but from /etc/hosts by dumpcap.

And it's getmail that gets denied 127.0.0.1 and 192.168.3.4 port 0. More about it in the future, I hope, maybe not so soon. Beacuse I'm left scratching my head about getmail going udp port 0. Probably legit, but I want to phathom it some day.

Code: Select all: 104.20.55.69 forum.palemoon.org 216.58.213.35 csi.gstatic.com 216.58.218.3 csi.gstatic.com 216.58.213.35 csi.gstatic.com 216.58.213.3 csi.gstatic.com 216.58.209.131 csi.gstatic.com 216.58.209.162 googleads.g.doubleclick.net 216.58.209.162 googleads.g.doubleclick.net 216.58.211.33 tpc.googlesyndication.com 216.58.211.46 encrypted-tbn3.gstatic.com

The ddg.gg has four entries, but traffic only for one of them:

Code: Select all: $ tshark -r dump_160531_2119_g0n.pcap -Y 'ip.addr in {96.45.83.209 96.45.83.40 96.45.82.53 96.45.82.134}'

gets only traffic to and from 96.45.83.209. I think it is because it is /usr/lib64/firefox that issues connect to those, and it does not have any ports set, but the 'port 0 ' shorthand instead, and I thought for a while that it should not be denied that connect. But why udp? When tcp is the normal way to go!

And the connection that ddg.gg opens, takes a few SYN packets resending to be delivered. At time 12 seconds roughly in the trace.

The next bunch is my beloved (oh yeah...) Schmoog... yeah... I don't see what called it. I know I didn't, and if there were pages opened with some Google ad or whatever, those were in the background... not active in any legal way, but that is a different issue. DuckDuckGo.com surely didn't call Google, I don't think...

Code: Select all: 216.58.214.206 encrypted-tbn0.gstatic.com 216.58.214.225 tpc.googlesyndication.com 216.58.214.227 www.gstatic.com 74.125.206.103 www.google.com 216.58.214.206 encrypted-tbn0.gstatic.com

And here grsec I like that it blocked it...

And also I checked, and the 216.58.214.0/24 family of google addresses do not appear in this trace untill after packet 10000:

Code: Select all: tshark -r dump_160531_2119_g0n.pcap -Y '(ip.addr in {216.58.214.0/24})'

(probably pipe to less or somehow, it's a lot of output)

(It's in frame 1079 that one of them makes the first appearance.)

Only somewhat similarly:

Code: Select all: tshark -r dump_160531_2119_g0n.pcap -Y '(ip.addr==74.125.206.0/24)'

makes the appearance only after frame 1732. And only the memeber 74.125.206.103 of the family, no other.

The conversation with 74.125.206.103 occurs indeed at second 24 from start
(
remember to look it up in the logs with:

Code: Select all: $ grep 74.125.206.103 messages_160531_2300_g0n_2119_section_in_sec

see just a few lines below here
)
, frame 1732 and a number of frames afterwords, with bad frame coloring applied to quite a fraction of those.

It appears to me to be the consequence of grsec's denied connect() to it:

Code: Select all: $ grep 74.125.206.103 messages_160531_2300_g0n_2119_section_in_sec 24 g0n kernel: [201270.080550] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 74.125.206.103 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~ver #10:28767] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000

when that conversation goes on per 10 seconds interval denials, IIUC:

Code: Select all: 1761 24.414029896 192.168.1.2 -> 74.125.206.103 TCP 68 58586 → https [ACK] Seq=637 Ack=4442 Win=43520 Len=0 TSval=200950685 TSecr=1237785781 1992 34.373983029 192.168.1.2 -> 74.125.206.103 TCP 68 [TCP Keep-Alive] 58586 → https [ACK] Seq=636 Ack=4442 Win=43520 Len=0 TSval=200960645 TSecr=1237785781 1993 34.417338750 74.125.206.103 -> 192.168.1.2 TCP 68 [TCP Keep-Alive ACK] https → 58586 [ACK] Seq=4442 Ack=637 Win=44928 Len=0 TSval=1237795826 TSecr=200950685 2172 44.448984676 192.168.1.2 -> 74.125.206.103 TCP 68 [TCP Keep-Alive] 58586 → https [ACK] Seq=636 Ack=4442 Win=43520 Len=0 TSval=200970720 TSecr=1237795826 2173 44.492386193 74.125.206.103 -> 192.168.1.2 TCP 68 [TCP Keep-Alive ACK] https → 58586 [ACK] Seq=4442 Ack=637 Win=44928 Len=0 TSval=1237805900 TSecr=200950685 2223 54.496996738 192.168.1.2 -> 74.125.206.103 TCP 68 [TCP Keep-Alive] 58586 → https [ACK] Seq=636 Ack=4442 Win=43520 Len=0 TSval=200980768 TSecr=1237805900 2224 54.540377386 74.125.206.103 -> 192.168.1.2 TCP 68 [TCP Keep-Alive ACK] https → 58586 [ACK] Seq=4442 Ack=637 Win=44928 Len=0 TSval=1237815948 TSecr=200950685

The seconds from the 'First packet time' are at 24, 34, 44 and 54 seconds. It happened right when grsec denied connect() to it, and also 10 seconds is the logging disabled interval:

Code: Select all: $ grep -A1 74.125.206.103 messages_160531_2300_g0n May 31 21:20:14 g0n kernel: [201270.080550] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 74.125.206.103 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~ver #10:28767] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 May 31 21:20:14 g0n kernel: [201270.080571] grsec: more alerts, logging disabled for 10 seconds $

, and also that ip didn't make any more traffic in those intervals, according to the trace, that I saved separately from the conversation with that ip:

Code: Select all: $ tshark -r dump_160531_2119_g0n.pcap -Y '(ip.addr==74.125.206.103)' -w \ dump_160531_2119_g0n_74.125.206.103.pcap

The next bunch I'd like to know about is:

Code: Select all: $ cat messages_160531_2300_g0n_2119_section_in_sec_port_0 | head -12|tail -3 68 g0n kernel: [201313.605205] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 63.245.213.49 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~ver #11:28769] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 68 g0n kernel: [201313.605216] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 63.245.213.47 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~ver #11:28769] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 68 g0n kernel: [201313.605223] grsec: (miro:U:/usr/lib64/firefox/firefox) denied connect() to 63.245.213.48 port 0 sock type dgram protocol udp by /usr/lib64/firefox/firefox[DNS Res~ver #11:28769] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3213] uid/euid:1000/1000 gid/egid:1000/1000 $

The denied connect was successful:

Code: Select all: $ tshark -r dump_160531_2119_g0n.pcap -Y '(ip.addr==74.125.206.103)&&(udp)' $

returns empty.

Those are Mozilla:

Code: Select all: $ grep '63.245.213.' dump_160531_2119_g0n.hosts 63.245.213.47 aus5.external.zlb.scl3.mozilla.com 63.245.213.48 aus5.external.zlb.scl3.mozilla.com 63.245.213.49 aus5.external.zlb.scl3.mozilla.com $

I didn't find any bad or suspicious coloring in the conversation that went fine with 63.245.213.49, but on tcp and ssl, not on udp:

Code: Select all: $ tshark -r dump_160531_2119_g0n.pcap -Y '(ip.addr==63.245.213.0/24)&&(udp)' $

(returns empty)

And I just want to generally state that putting in the wireshark the filter 'udp' with dump_160531_2119_g0n.pcap opened in it, or running:

Code: Select all: $ tshark -r dump_160531_2119_g0n.pcap -Y udp $

returns a smallish number of packets, yes:

Code: Select all: $ tshark -r dump_160531_2119_g0n.pcap -Y udp | wc -l 245 $

, but they're all local (even this IPv6 6 4 frames, but I speak too little
IPv6 to tell):

Code: Select all: $ tshark -r dump_160531_2119_g0n.pcap -Y udp | grep -v 192.168.1 1 0.000000000 0.0.0.0 -> 255.255.255.255 DHCP 410 DHCP Request - Transaction ID 0xd38a7989 5 4.559007652 0.0.0.0 -> 255.255.255.255 DHCP 410 DHCP Request - Transaction ID 0xd38a7989 8 4.616281016 fe80::20e:2eff:fe2e:d230 -> ff02::1:2 DHCPv6 197 Information-request XID: 0x3f267d CID: 000100011ae527808e64d7e7d3d8 9 4.634550413 fe80::1 -> fe80::20e:2eff:fe2e:d230 DHCPv6 128 Reply XID: 0x3f267d CID: 000100011ae527808e64d7e7d3d8 $

And I think I'll settle with these results and analysis for now (I've studied this for four days dedicatedly, oh dear!), because this:

Code: Select all: $ cat messages_160531_2300_g0n_2119_section_in_sec_port_0 | \ grep -v 'dgram protocol udp' $

tells that the sole connections that grsec denies are udp to where tcp is due, IIUC.

Why would firefox ever need to connect to ip's via udp? is a question that I'd like to read an explanation about, dear reader, if you can tell us.

But now I got to go about other business, calmed down in my understanding (a little less vague then when I started this quest) that grsec does a good job when it denied port 0 udp connections where tcp and ssl are the protocols to use.

I don't think I'm done with this, other than for the time being, temporarily. I'm overwhelmed, amazed and in a state of wonder, I find this really interesting, getting into these secrets... But I'm also very much exhausted at this point. And I'm unable to work it all out completely... Quite a few secrets unrevealed left there for me.

If you have read carefully the previous posts, you will have remembered that I had a breakage which I realized some maybe five days ago now. The SSLKEYLOGFILE wouldn't log the keys, and part of the network traces, those with the SSL protocol, weren't being dumped for a short time. I can't now go into that, too tired, it was more important to me to see that when recovered from backup, my system works correctly again, as it seems to me.

I'm not an expert, and there may be revisions to my current understnading that I posted above, in the future.

Also you can see I planned more analysis that I was able to find time... For now.

Regards,

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)

by **timbgo** » Sat Jun 11, 2016 12:49 am

Probably I found what is wrong. It's in the router, the only little comp, not under my control, but provider's:

http://www.croatiafidelis.hr/foss/cap/c ... 0-ZTE-ssl/

Currently busy. Will likely be back to tell more.

Regards,

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)