Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Fri Sep 05, 2014 7:22 pm    Post subject: Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion Reply with quote

EDIT START Sun 8 Feb 02:20:23 CET 2015: change title to:

Postfix smtp/TLS, Backup/Cloning Method, and Documenting Censorship/Intrusion

[EDIT END]
previous title:

Postfix in smtp-tls-wrapper, a Backup/Cloning Method and A Zerk Provider

PART 1
======

The logging below is chronological with the commented commands.

I'm offline and only go hit-and-run online. Do the work and go safely offline.

First is connecting (physically plugging in the cable plug to ADSL router's
socket).

/var/log/messages:
Code:

Sep  4 19:26:24 localhost dhcpcd[2351]: eth0: IAID 3f:d2:c3:22
Sep  4 19:26:24 localhost dhcpcd[2351]: eth0: soliciting an IPv6 router
Sep  4 19:26:25 localhost dhcpcd[2351]: eth0: rebinding lease of 192.168.8.94
Sep  4 19:26:30 localhost dhcpcd[2351]: eth0: leased 192.168.8.94 for 86400 seconds
Sep  4 19:26:30 localhost dhcpcd[2351]: eth0: adding route to 192.168.8.0/24
Sep  4 19:26:30 localhost dhcpcd[2351]: eth0: adding default route via 192.168.8.1
Sep  4 19:26:36 localhost dhcpcd[2351]: eth0: no IPv6 Routers available


Issuing to see what I have in my mail queue:
Code:

$ mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
29D7B28E1FF     4928 Thu Sep  4 18:56:35  mrovis.fake@croatiafidelis.hr
(lost connection with 127.0.0.1[127.0.0.1] while receiving the initial server greeting)
                                          support@plus.hr

-- 5 Kbytes in 1 Request.
$


So let's flush that message.
Code:

$ postqueue -f


And sure enough, it shows in the messages log.

(continuation of /var/log/messages;)
Code:

Sep  4 19:26:44 localhost postfix/qmgr[12295]: 29D7B28E1FF: from=<mrovis.fake@croatiafidelis.hr>, size=4928, nrcpt=1 (queue active)
Sep  4 19:26:44 localhost stunnel: LOG5[13735]: Service [smtp-tls-wrapper] accepted connection from 127.0.0.1:39011
Sep  4 19:26:44 localhost stunnel: LOG5[13735]: s_connect: connected 178.218.164.164:465
Sep  4 19:26:44 localhost stunnel: LOG5[13735]: Service [smtp-tls-wrapper] connected remote server from 192.168.8.94:41958


But, equally obvious, it doesn't work all the way. It's: "authentication
failed", "no mechanism available",

(continuation of /var/log/messages)
Code:

Sep  4 19:26:44 localhost postfix/smtp[13734]: warning: SASL authentication failure: No worthy mechs found
Sep  4 19:26:44 localhost postfix/smtp[13734]: 29D7B28E1FF: to=<support@plus.hr>, relay=127.0.0.1[127.0.0.1]:11125, delay=1809, delays=1809/0.01/0.17/0, dsn=4.7.0, status=deferred (SASL authentication failed; cannot authenticate to server 127.0.0.1[127.0.0.1]: no mechanism available)
Sep  4 19:26:44 localhost stunnel: LOG5[13735]: Connection closed: 28 byte(s) sent to SSL, 365 byte(s) sent to socket


I'm curious to see what I will get with testsaslauthd.

Code:

$ testsaslauthd -u mrovis.fake@croatiafidelis.hr -p thepassphrase
0: NO "authentication failed"
$


And, just to remind, this presentation is chronological, after that command,
the following shows in the messages log:

(continuation of /var/log/messages)
Code:

Sep  4 19:26:51 localhost saslauthd[12425]: pam_warn(imap:auth): function=[pam_sm_authenticate] service=[imap] terminal=[<unknown>] user=[mrovis.fake@croatiafidelis.hr] ruser=[<unknown>] rhost=[<unknown>]
Sep  4 19:26:51 localhost saslauthd[12425]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
Sep  4 19:26:51 localhost saslauthd[12425]: do_auth         : auth failure: [user=mrovis.fake@croatiafidelis.hr] [service=imap] [realm=] [mech=pam] [reason=PAM auth error]


Lastly, disonnecting (physically unplugging the cable plug from ADSL router's
socket).

(continuation of /var/log/messages)
Code:

Sep  4 19:27:16 localhost dhcpcd[2351]: eth0: carrier lost
Sep  4 19:27:16 localhost dhcpcd[2351]: eth0: deleting route to 192.168.8.0/24
Sep  4 19:27:16 localhost dhcpcd[2351]: eth0: deleting default route via 192.168.8.1


============================
[smtp-tls-wrapper] in /var/log/messages comes from the section in
stunnel.conf.

Code:

# cat /etc/stunnel/stunnel.conf | grep -v '#'

setuid = stunnel
setgid = stunnel
pid = /run/stunnel/stunnel.pid

socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1

[smtp-tls-wrapper]
accept = 11125
client = yes
connect = 178.218.164.164:smtps


and that part of my configuration is doing the work right, because I can do:

Code:

# telnet localhost 11125
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220-lin16.mojsite.com ESMTP Exim 4.80 #2 Thu, 04 Sep 2014 22:34:59 +0200
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
quit
221 lin16.mojsite.com closing connection
Connection closed by foreign host.
#

The "quit" above is what I typed.
============================
But I'm not clear about sasl and about pam. What am I doing, or what is, or
where is what, wrong, in the configuration, in the system...?
============================
Code:

# equery k cyrus-sasl
* Checking dev-libs/cyrus-sasl-2.1.26-r7 ...
!!! /etc/conf.d/saslauthd has incorrect MD5sum
   175 out of 176 files passed
#

which tells us that only that file of the entire package is changed from
default.

I use the signed portage snapshots and update my system with emerge-webrsync, I
also have a local private mirror for my systems, and I rsync and update those
away from my air-gapped master Gentoo system, then thoroughly check the rsync
downloads and only then update my master Gentoo, from which I clone any other
of my other two or three Gentoo systems, the air-gapped install can be found
explained, among other places, in

Air-Gapped Gentoo Install, Tentative
https://forums.gentoo.org/viewtopic-t-987268.html

so, that very likely is a pretty hefty assurance!

But this is just one minor component of this old tls-wrapper-method, and this
is the hardest method of all SSL/TLS methods for mail clients:

postfix SMTP authentication
https://forums.gentoo.org/viewtopic-p-6495963.html#6495077
(that's a developer complaining how difficult it is)

So there's so many things to check or figure out yet.

Let's keep with that package (cyrus-sasl) and that file
Code:

# cat /etc/conf.d/saslauthd | grep -v '#'
SASLAUTHD_OPTS="-a pam"
#


Oh, I remember I tried adding debugging and other stuff to it:
Code:

#SASLAUTHD_OPTS="-d -r -a pam -O localhost -c 128 -t 10"

but I rolled it back, that is I commented that line because it never helped
much.
But when I remove that uncommented line, the equery shows:
Code:

# equery k cyrus-sasl
* Checking dev-libs/cyrus-sasl-2.1.26-r7 ...
!!! /etc/conf.d/saslauthd has wrong mtime (is 1409861797, should be 1408828486)
   175 out of 176 files passed
#

that only the mtime is not as in the original package.

That does tell, silently, that the MD5sum is correct.

I could certainly try the -r switch. It joins the user
("mrovis.fake") and the realm ("croatiafidelis.hr"), which is the old way.

Changing:
Code:

SASLAUTHD_OPTS="-a pam"

to:
Code:

SASLAUTHD_OPTS="-a pam -r"


Tried, no improvement.

Let's see, as the comments in the /etc/conf.d/saslauthd say:

Code:

# saslauthd -v
saslauthd 2.1.26
authentication mechanisms: sasldb getpwent pam rimap shadow
#


And let's try and change "-a pam" to "-a sasldb"

Code:

SASLAUTHD_OPTS="-a sasldb -r"


No, the logs still look pretty much the same as in the beginning of this
post... So rolling that one back to just:

Code:

SASLAUTHD_OPTS="-a pam"


============================
Code:

# ls -l /etc/postfix/saslpass
-rw------- 1 root root 244 2014-09-04 16:55 /etc/postfix/saslpass
#


It's postfix's:
Code:

# equery b /etc/postfix/saslpass
 * Searching for /etc/postfix/saslpass ...
mail-mta/postfix-2.11.1-r1 (/etc/postfix/saslpass)
#


But is it wrong that I put the localhost and not the destination server in it?

Code:

# cat /etc/postfix/saslpass
# $Header: /var/cvsroot/gentoo-x86/mail-mta/postfix/files/smtp.pass,v 1.2
# 2004/07/18 03:26:56 dragonheart Exp $
#
[127.0.0.1]:11125 mrovis.fake@croatiafidelis.hr:<the password here>
#

Trying to put the server instead. Did it, the line is now:
Code:

[178.218.164.164]  mrovis.fake@croatiafidelis.hr:<the password here>
and:
# postmap hash:/etc/postfix/saslpass
# postfix reload


Bingo! That did it!
If you want just to see how it worked, go to PART 3.
If you want the whole story, read all as posted.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
======= cut off from this line to end if verifying hashes =======
File corresponding to this post: Gen_140905_smtp-tls-wrapper-mode_and_beserk_provider_PART1.txt,
which has some data concealed
has Publictimestamp # 1240484
and is based on non-concealed, unprotected, so not
published full data file Gen_140905_smtp-tls-wrapper-mode_and_beserk_provider.txt
with Publictimestamp # 1240508
--
publictimestamp.org/ptb/PTB-21547 sha256 2014-09-05 18:01:46
E19499140167F375D4D69952569EFBBDB2AB10842FDD26E7EC75509CD1736FDD


Last edited by miroR on Sun Feb 08, 2015 1:23 am; edited 4 times in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Fri Sep 05, 2014 7:30 pm    Post subject: Reply with quote

Don't forget to read the update at:
https://forums.gentoo.org/viewtopic-t-999436.html#7817962
further below
====== cut out this line and above if checking PTS ====
PART 2
======
The Backup/Cloning Method in Poor User's Security

I really shouldn't be risking coming out with my poor user's security methods,
but when you see what is up against my freedom, you will probably agree that
it's worth disclosing it.

It's nothing new in the GNU/Linux world, but less experienced users than me
will find it useful.

This is how I basically clone my systems.

It's not strictly necessary for the systems to be same MBO-based, but they
surely have to be of the same architecture, and if they are of same model MBO,
all is actually very easy. (If they're not same model, can be much more
difficult.)

This part needs your true understanding, else don't try to do it, you can very
easily ruin your installation (the software), and maybe, although not so
likely, even worse scenarios are possible.

I have to change the numbers a little, but this is very similar to what my HD
drive actually is, HDD onto which my installation, that is perfectly
cloneable, is on, and that installation is up and running as I speak. This one
actually was cloned from another one, and this one is destined to be the
online air-gapped system (no SOHO access, standalone from SOHO), while there
are other two or three, that remain offline (only SOHO access, no online
access). But, in matter of principle, they are all inter-cloneable.

Code:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           15000   6.3 MiB     EF02  BIOS boot partition
   2           16384         1100000   529.1 MiB   8300  Linux filesystem
   3         1101824       150000000   71.0 GiB    8300  Linux filesystem
   4       150001664      3750000639   1.7 TiB     8300  Linux filesystem
   5      3750000640      3907029134   74.9 GiB    0700  Microsoft basic data


I can't go here into details about gdisk. I read what the author of that new
boot architecture (or whatever to describe it) wrote, and understood some,

GPT fdisk Tutorial
http://www.rodsbooks.com/gdisk/

...and learned to use it. You should do likewise, say on a weekend.

For our purposes of cloning a system, we need to know what we installed where.
You have enough on the issue of partitions and things in the Gentoo
Installation Guide

Gentoo Linux AMD64 Handbook
http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml
(or find your arch)

You can have a different setup. But mine is simple. Only two system
partitions.

(the:
Code:

   1            2048           15000   6.3 MiB     EF02  BIOS boot partition

is the gdisk's own partition with no directly related OS-stuff installed)

The /boot is:
Code:

   2           16384         1100000   529.1 MiB   8300  Linux filesystem


and the / (root, the partition, not /root the home of the root user) is:
Code:

   3         1101824       150000000   71.0 GiB    8300  Linux filesystem



Since the HDD is /dev/sda (unless there's more HDD's or USB's or other stuff),
what I need to do to back up my entire system, from a rescue system like the
fine French developers' Gentoo based:

SystemRescueCd
http://www.sysresccd.org/

and cd into a directory somewhere completely out of that system that must not
be mounted, and must not be used in any way by any process (which is just
generally the case upon booting into a machine from a CD- or USB-installed
system like sysresccd).

It's best if you mkdir an empty directory on a whole different another disk
and cd into there, because an installation is a lot of GB to dump (and it's
not too expensive nowadays to get a USB-3 storage adapter and HD drives are
not that dear either), and once we are sure we have room enough, we need to
dump those partitions.

Again, it really depends for you, how you installed your system. It really can
be something totally different.

But in my case, it's pretty simple. I just need to dd ([d]isk [d]ump)
/dev/sda2 and /dev/sda3 (or if they are named differently, see above). So I
only need to:

[ I have lots of files starting with dates, and to cut shorter their names, I
decided to use A-K instead of 10 10-19, so E is 14, in all the files in this
text named E09... and similar ]

[ The n4m3 is the hostname part of the name. ]

Code:

# dd if=/dev/sda2 of=E0904_sda2_n4m3.dd
...
This one is quickly done, and it'll throw out the size of the partition that
it has dumped soon. (not reproducing it, because I'm writing from memory
now), and return the command line prompt.
#


The same notice, followed by "Done" will me thrown on the same standard output
by the next one command below, but that one will take much longer time:

Code:

# dd if=/dev/sda3 of=E0904_sda3_n4m3.dd
...
#


In my case I got:
Code:

# ls -l
-rw-r--r-- 1 root root   558709056 2014-09-05 00:15 E0904_n4m3_sda2.dd
-rw-r--r-- 1 root root 76767246848 2014-09-05 00:31 E0904_n4m3_sda3.dd
# ls -lh
-rw-r--r-- 1 root root 523M 2014-09-05 00:15 E0904_n4m3_sda2.dd
-rw-r--r-- 1 root root  75G 2014-09-05 00:31 E0904_n4m3_sda3.dd
#


The sizes are not exactly my numbers, but the method is.

Just for this article to contain complete info on cloning, these dumps (only
two) suffice for me to clone the system onto another same size/model HDD on
same model MBO computer. After, in case of an empty, for being zeroed out, or
for being new, HDD, having created the exact sam gpt partitions on it, as
previously shown, I just run:

Code:

# dd if=E0904_sda2_n4m3.dd of=/dev/sda2
# dd if=E0904_sda3_n4m3.dd of=/dev/sda3


And there is, first, to do chrooting into the cloned system (see the Gentoo
Installation Guide) and installing grub2, and there sure are tweaks to do to
assign different local ip to it on the SOHO, but there is hardly any other
work, and it's up.

Now while the sizes I changed, these sha256 sums below are very much exactly
my numbers, for those exact disk dumps.

Namely, I have evidence on particular workings against me in this disk dumped
system that is now frozen in time and will be publictimestamped, and then only
police brute force and stuff like breaking into my appartment to vandalize my
computers could destroy that evidence, which I hope won't yet happen, but in
Croatia we have slowly been starting to fear in the early morning hours...

Excuse me for the one line "digression" above, but the story wouldn't be really
complete without it. So quoted. Because it is not really a digression.

This is poor user's forensics in action. I didn't learn this at university or
elsewhere, I taught this myself from GNU/Linux man pages, forums, tutorials,
tips and tricks and the rest, and I can see that it works.

Now my / (root) partition is some 70G, and that's a lot. You can't put that on
the internet, right?

But this kind of freezing of a state of a system can be used not just for
cloning (which in itself is backup and restore, only not on same but another
system). It can also serve for evidence of what happened in a particuler
period or around a very particular (more on that later) moment in your use of
your computer.

And that is what I dd'ed my system for, this time around. Not for cloning,
because it has been freshly cloned from the air-gapped SOHO-only system some
now twenty something hours ago, have been on the internet just in brief
intervals, very carefully monitoring everything I did (had recently installed
iptables as well, and proper ulogd-logging).

Configuring iptables firewall on Gentoo
http://gentoovps.net/configuring-iptables-firewall/

But you will be able to see in much technical details what happened.

I was saying how my / (root) partition was some 70G and how I couldn't put
that on the internet.

On the other hand, what is necessary to do, if one wants to identify a
particular something of any kind of electronic document, and that huge 70G
file is one single electronic entity too... What is necessary to do, is
identify these partitions by calculating their checksum.

And I did so.

Code:

$ cat /mnt/sde1/dd_Add_3/dd_E0904_n4m3.sum
eb7a44755984b38c13e37dfb33cf3e647223ddb8cbbe3dc62e422297277a6028  E0904_n4m3_sda2.dd
fab838ed26e8f42fa995b5b1b7f92cef5e26fd811999f9c1f8c95ea092e720ba  E0904_n4m3_sda3.dd
$


Code:

$ cat /mnt/sdf1/dd_Add_3/dd_E0904_n4m3.sum
eb7a44755984b38c13e37dfb33cf3e647223ddb8cbbe3dc62e422297277a6028  E0904_n4m3_sda2.dd
fab838ed26e8f42fa995b5b1b7f92cef5e26fd811999f9c1f8c95ea092e720ba  E0904_n4m3_sda3.dd
$


That is those two partitions, very real ones, are the sole ones in extremely
great likelihood in the whole of the universe to have those hashes. Any
mathematician will tell you that. Well, the universe, Eistein is reported to
have said, was not sure was infinite, but the chances are so unimaginably slim
anything else in the, say world, has sensically those numbers in any case.

However, while that's certainly evidence, you can't really put it anywhere...
If circumstances arise though, say in court, I could (less those brutalities
that regimes do didn't previously happen on me and my possessions), I could
produce those, for sure...

But for practical purpose if, say, a discussion ensued where people wanted to
check on my claims, and that discussion was happening on some GNU/Linux fori,
no, I couldn't easily use those.

But I found another one of my poor user's forensics methods to apply here and
with it be able to use something a little less, but still very, convincing.

Here it is, in command lines:

Code:

n4m3 ~ # losetup /dev/loop1 /mnt/sde1/dd_Add_3/dd_E0904_n4m3/E0904_n4m3_sda3.dd
n4m3 ~ # losetup /dev/loop2 /mnt/sde1/dd_Add_3/dd_E0904_n4m3/E0904_n4m3_sda2.dd
n4m3 ~ # losetup /dev/loop6 /mnt/sdf1/dd_Add_3/dd_E0904_n4m3/E0904_n4m3_sda3.dd
n4m3 ~ # losetup /dev/loop7 /mnt/sdf1/dd_Add_3/dd_E0904_n4m3/E0904_n4m3_sda2.dd
n4m3 ~ # blockdev --setro /dev/loop1
n4m3 ~ # blockdev --setro /dev/loop2
n4m3 ~ # blockdev --setro /dev/loop6
n4m3 ~ # blockdev --setro /dev/loop7
n4m3 ~ # blockdev --getro /dev/loop1
1
n4m3 ~ # blockdev --getro /dev/loop2
1
n4m3 ~ # blockdev --getro /dev/loop6
1
n4m3 ~ # blockdev --getro /dev/loop7
1
n4m3 ~ # mkdir /mnt/gentooE /mnt/gentooF
n4m3 ~ # mount /dev/loop1 /mnt/gentooE/
mount: /dev/loop/1 is write-protected, mounting read-only
n4m3 ~ # mount /dev/loop2 /mnt/gentooE/boot/
mount: /dev/loop/2 is write-protected, mounting read-only
n4m3 ~ # mount /dev/loop6 /mnt/gentooF/
mount: /dev/loop/6 is write-protected, mounting read-only
n4m3 ~ # mount /dev/loop7 /mnt/gentooF/boot/
mount: /dev/loop/7 is write-protected, mounting read-only
n4m3 ~ # cd /mnt/gentooE/ && jacksum -V summary -a sha256 \
    -r -d -f -m ./ > /some/where/dd_140904_2317_n4m3_GentooE.sum &
[5] 3181
n4m3 ~ # cd /mnt/gentooF/ && jacksum -V summary -a sha256 \
    -r -d -f -m ./ > /some/where/dd_140904_2317_n4m3_GentooF.sum &
[6] 3205
n4m3 ~ #


I believe even interested lower level intermediate users, or very bright
beginners can understand these commands above, if they dedicate a certain
amount of time to study the good ole apparently dry and of the proverbial
steep learning curve, but so fine and friendly in the end, GNU/Linux man
pages... and many GNU people tutorials and things. GNU has informal meaning
for me. Richard Matthew Stallman has started the movement, but it's anybody's
and it's anywhere. It still shines and it really still rules. And it's really
one of the last defenses for freedom and democracy in the world which is still
strong in our Orwellian now post-Snowden age.

Let me just point out how those dumped partitions SHA256 hashes would be gone
forever if I didn't do the "losetup " commands followed by especially the
"blockdev --setro" commands...

If I had done the "mount " commands, or if I were to do them ever after I
publish this article, without assuring myself that the loop device with the
partition on it was returning "1" when "blockdev --getro " command was run on
it, the dumped partitions would have been mounted read-write and would have
lost it's identity which they had before, at the time the hashes were
calculated on them!

But there's more to say here. I didn't say it before, because it is much more
easily to say why now, while it wouldn't have been so obvious and
understandable before.

You can see that I dumped the partitions in two different storages. That
increases my chances to have these huge identifiable documents intact at some
later date. I haven't read anything mathematical in long time, but that
increases my chances something like exponentially, I guess.

And what's more, those jacksum lines tell that I run jacksum on both the
mounted partitions. Those are two instances of the same frozen Gentoo system
of mine, in two different storages, and I run jacksum on them to get the
hashes of all (sic!) the files in them!

These are the two files upon completion of the jacksum run:
Code:

# ls -l dd_140904_2317_n4m3_Gentoo?.sum
-rw-r--r-- 1 root root 85879889 2014-09-05 02:29 dd_140904_2317_n4m3_GentooE.sum
-rw-r--r-- 1 root root 85879889 2014-09-05 02:29 dd_140904_2317_n4m3_GentooF.sum
$ ls -ltrh dd_140904_2317_n4m3_Gentoo?.sum
-rw-r--r-- 1 root root 82M 2014-09-05 02:29 dd_140904_2317_n4m3_GentooE.sum
-rw-r--r-- 1 root root 82M 2014-09-05 02:29 dd_140904_2317_n4m3_GentooF.sum
#


And now somebody tell me what will the diff be, if:
Code:

# sha256sum /some/where/dd_140904_2317_n4m3_Gentoo?.sum
a116bdf3fd8c828c80c0d1a1e45e8d9ebb7cecdfb98eb8a1548d078576c4c291
/some/where/dd_140904_2317_n4m3_GentooE.sum
ad793a80085fbb048b7f2965e69a110d31bca06aeccfe669a4169d8a576d3ff9
/some/where/dd_140904_2317_n4m3_GentooF.sum
#


What will the diff be? The question is for newbies, sure. Big boys, don't get
annoyed, I always write with a desire to get more newbies into GNU/Linux.

I guess a lot is clear about what I wrote above, just that very particular
moment in my use of my computer that I want this whole affair to serve as
evidence for, is not yet clear, is it? No, it's not yet. It can't be clear
yet. Patience please, just a little longer. Some things take time to present.

Let's go back to my configuration of smtp-tls-wrapper and friends, because
therein will lie the very particular moment in the electronic processes of this
computer in service of my electronic mailing needs, so big boys, skim through
this and find that piece of information quickly yourself if you're impatient,
in the text some distance below from here.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
======= cut off from this line to end if verifying hashes =======
File corresponding to this post: Gen_140905_smtp-tls-wrapper-mode_and_beserk_provider_PART2.txt,
which has some data concealed
has Publictimestamp # 1240490
and is based on non-concealed, unprotected, so not
published full data file Gen_140905_smtp-tls-wrapper-mode_and_beserk_provider.txt
with Publictimestamp # 1240508
--
publictimestamp.org/ptb/PTB-21547 sha256 2014-09-05 18:01:46
E19499140167F375D4D69952569EFBBDB2AB10842FDD26E7EC75509CD1736FDD


Last edited by miroR on Mon Sep 21, 2015 11:08 pm; edited 2 times in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Fri Sep 05, 2014 7:44 pm    Post subject: Reply with quote

PART 3
======
Postfix Good in smtp-tls-wrapper Mode But Provider Zerk

Back a few hours ago, I understood I got my /etc/postfix/saslpass wrong,
replaced the localhost with the destination host, and I succeeded in sending
the message.

Here's how it went.

It really should suffice to see where the story went just seeing this relevant
little chunk of my /var/log/messages (only some substitutions are in place for
protection of my data):

Code:

Sep  4 23:18:25 localhost dhcpcd[2351]: eth0: carrier acquired
Sep  4 23:18:25 localhost dhcpcd[2351]: eth0: IAID 3f:d2:c3:22
Sep  4 23:18:26 localhost dhcpcd[2351]: eth0: soliciting an IPv6 router
Sep  4 23:18:26 localhost dhcpcd[2351]: eth0: rebinding lease of 192.168.8.94
Sep  4 23:18:31 localhost dhcpcd[2351]: eth0: leased 192.168.8.94 for 86400 seconds
Sep  4 23:18:31 localhost dhcpcd[2351]: eth0: adding route to 192.168.8.0/24
Sep  4 23:18:31 localhost dhcpcd[2351]: eth0: adding default route via 192.168.8.1
Sep  4 23:18:38 localhost dhcpcd[2351]: eth0: no IPv6 Routers available


Here I issued
$ postueue -f

Code:

Sep  4 23:18:45 localhost postfix/qmgr[14544]: 29D7B28E1FF: from=<mrovis.fake@croatiafidelis.hr>, size=4928, nrcpt=1 (queue active)
Sep  4 23:18:45 localhost stunnel: LOG5[14603]: Service [smtp-tls-wrapper] accepted connection from 127.0.0.1:39025
Sep  4 23:18:45 localhost stunnel: LOG5[14603]: s_connect: connected 178.218.164.164:465
Sep  4 23:18:45 localhost stunnel: LOG5[14603]: Service [smtp-tls-wrapper] connected remote server from 192.168.8.94:41972
Sep  4 23:18:46 localhost stunnel: LOG5[14603]: Connection closed: 107 byte(s) sent to SSL, 499 byte(s) sent to socket
Sep  4 23:18:46 localhost postfix/smtp[14602]: 29D7B28E1FF: to=<support@plus.hr>, relay=127.0.0.1[127.0.0.1]:11125, delay=15731, delays=15731/0.01/0.18/0.52, dsn=5.0.0, status=bounced (host 127.0.0.1[127.0.0.1] said: 550-"JunkMail rejected - 147-226.dsl.iskon.hr (n4m3.localdomain) 550-[89.164.147.226]:41972 is in an RBL, see 550 http://www.spamhaus.org/query/bl?ip=89.164.147.226" (in reply to RCPT TO command))
Sep  4 23:18:46 localhost postfix/cleanup[14605]: 7F2AF390629: message-id=<20140904211846.7F2AF390629@n4m3.localdomain>
Sep  4 23:18:46 localhost postfix/bounce[14604]: 29D7B28E1FF: sender non-delivery notification: 7F2AF390629
Sep  4 23:18:46 localhost postfix/qmgr[14544]: 7F2AF390629: from=<>, size=7074, nrcpt=1 (queue active)
Sep  4 23:18:46 localhost postfix/qmgr[14544]: 29D7B28E1FF: removed
Sep  4 23:18:46 localhost stunnel: LOG5[14607]: Service [smtp-tls-wrapper] accepted connection from 127.0.0.1:39027
Sep  4 23:18:46 localhost stunnel: LOG5[14607]: s_connect: connected 178.218.164.164:465
Sep  4 23:18:46 localhost stunnel: LOG5[14607]: Service [smtp-tls-wrapper] connected remote server from 192.168.8.94:41974
Sep  4 23:18:46 localhost stunnel: LOG5[14607]: Connection closed: 92 byte(s) sent to SSL, 499 byte(s) sent to socket
Sep  4 23:18:46 localhost postfix/smtp[14602]: 7F2AF390629: to=<mrovis.fake@croatiafidelis.hr>, relay=127.0.0.1[127.0.0.1]:11125, delay=0.32, delays=0.03/0/0.19/0.1, dsn=5.0.0, status=bounced (host 127.0.0.1[127.0.0.1] said: 550-"JunkMail rejected - 147-226.dsl.iskon.hr (n4m3.localdomain) 550-[89.164.147.226]:41974 is in an RBL, see 550 http://www.spamhaus.org/query/bl?ip=89.164.147.226" (in reply to RCPT TO command))
Sep  4 23:18:46 localhost postfix/qmgr[14544]: 7F2AF390629: removed
Sep  4 23:19:23 localhost dhcpcd[2351]: eth0: carrier lost
Sep  4 23:19:23 localhost dhcpcd[2351]: eth0: deleting route to 192.168.8.0/24
Sep  4 23:19:23 localhost dhcpcd[2351]: eth0: deleting default route via 192.168.8.1


It says there all for the trained eye.

I started writing this article ( which I will try and post on forums.gentoo.org
as simple user's short series of posts under a title like:

Connecting smtp-tls-wrapper mode in postcommunist countries with providers
going beserk
-- well... --

and I really do believe that there are good tips in this entire article, useful
tips for people, and I am also proud of my success in solving this non-trivial
mail configuration issue, but...

...[I will try and post on forums.gentoo.org] but who knows if my provider
haven't gone so beserk in the meantime and have cut my connection out all the
way ... or if other issues prevent my posting of this )

But when I started writing this article, let me assure you that I didn't expect
the "JunkMail rejected" line, as I really haven't mailed other than a few mails
in months. Not tens of mails, let alone hundreds of mails, let absolutely alone
thousands of mails, no! I have only mailed less than a few dozen electronic
messages, if not less, and a lot less, of e-mails in the recent quite a few
months altogether!

So I didn't initially mean this article about that part of the story. It
really made my eye pupils go wide, I believe, when I saw that line, but I
started this article upon some two weeks of study of postfix, sasl, pam,
stunnel and friends, sensing that I was close to getting it right, and wanting
to post it for the benefit of other users, or, in case that I would still
remain stuck, to ask for help from Gentoo community.

I have a few things left to do.

The first is to sift through all the above which in non-public version (but
with publictimestamp to prove its existence) will have all the data intact, the
first thing is sifting through it and changing whatever of the data is not good
to remain public. Of which data some, such as https://plus.hr who are working
fine (they host my www.CroatiaFidelis.hr domain) and this is actually a fine
recommendation for them, while http://iskon.hr , the provider gone beserk; oh,
it is my pride to disclose on them, because now it's obvious how they like to
do the truly arrogant and senseless censoring on their users. But the numbers,
and various processes and stuff, no, can't remain, lots of changes needed
before publishing this.

The second thing to do is connect with Tor and try and anonymously see the
entry in... http://www.spamhaus.org/query/bl?ip=89.164.147.226 (see it in the
log above)... No! That's just the temporary ip that Iskon gave me. That could
only have been a one time thing. So the second thing is to see whatever this
beserk provider might be doing next on me... Aarrrgghhh!!...

I might also end up needing some help from the bigger Gentoo boys on this. Who
knows yet. I hope you people in your majority still support me in my quest for
knowledge, and freedom, as well as stand with me in the passion for GNU/Linux.

And third thing, there is one Addendum to add right after publishing this, on
my screencast/dumpcap-ing technique generally, and in this affair, and some
more on the hashing plus publicstamping methods for evidence identifying that I
employed.

As far as strictly the smtp-tls-wrapper mode issues, as well as on
backup/cloning methods, I'll be happy to help, if I can, if anyone needs
advice. (However, allow time, I work really slowly on top of being politically
persecuted and therefore unsafe in my own Homeland.)

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
======= cut off from this line to end if verifying hashes =======
File corresponding to this post: Gen_140905_smtp-tls-wrapper-mode_and_beserk_provider_PART3.txt,
which has some data concealed
has Publictimestamp # 1240496
and is based on non-concealed, unprotected, so not
published full data file Gen_140905_smtp-tls-wrapper-mode_and_beserk_provider.txt
with Publictimestamp # 1240508
--
publictimestamp.org/ptb/PTB-21547 sha256 2014-09-05 18:01:46
E19499140167F375D4D69952569EFBBDB2AB10842FDD26E7EC75509CD1736FDD


Last edited by miroR on Fri Sep 05, 2014 8:46 pm; edited 1 time in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Fri Sep 05, 2014 7:51 pm    Post subject: Reply with quote

Addendum
========
More on Some Issues Previous to This Post

This Addendum is apart because the main body of the article (separated in three
parts) has already become too complex, but it is integral part of the article.

These are the commands that I deploy to record what happens when I go online:

As root:
Code:

# touch dump_`date +%y%m%d_%H%M%S`_`hostname`.pcap && \
    dumpcap -i any -w dump_`date +%y%m%d_%H%M`_`hostname`.pcap &


As normal user:
Code:

$ ffmpeg -f x11grab -s xga -r 25 -i :0.0 -c:v libx264 -preset ultrafast \
    -threads 0 Screen_`date +%y%m%d_%H%M`_`hostname`.mkv


(read more in the previous section of this article:

[ this same topic ]
https://forums.gentoo.org/viewtopic-t-999436.html#7613038

find there "physically plugging in the cable plug to ADSL router")

Now, on the hashing and publicstamping methods for evidence gathering that I
deployed here.

The jacksum commands, as already explained,

(read more on

[ this same topic ]
https://forums.gentoo.org/viewtopic-t-999436.html#7613044

find there "jacksum -V summary -a sha256")

gave two files exactly of the same identifying hash on two different storage
units (hard disks attached via USB-3 adaptor).

Surely it's huge text, 82M, not reproducible here, but it's minute in
comparison to the 70G plus 1/2 G of the two dumped partitions. That could be
gzipped to just a few megabytes, encrypted and posted somewhere, no big deal,
in case there were to be a discussion; I'm talking generally for people having
similar issues, which are rare, but it's the persecuted dissidents that push
for and eventually bring about changes in political landscapes, so we are not
a kind to be underestimated and we are not an unimportant kind.

And then what you can do is take any file whichever from that huge list of
thousands of files and safely claim that it was there at that particular time
(sure, if you also timely publictimestamped it).

I can easily prove (in my case, I sure could trust a small number of few
people so much in among the Gentoo community, if they gave me their word to
not allow any further that file, and encrypt that file to their PGP key, and
they could confirm or not confirm that I was saying the truth; applies
generally in similar cirumstances for anyone else with issues like mine, or
just with needs for hashed and public time stamped evidence like mine).

As far as the http://publictimestamp.org goes, their explanations are online
and suffice. Nothing to add there. Just that I really like like their program
and service. It's a fine GNU thing, a thing like so many other free things,
thankfully, for us free people on the internet, and by free people on the
internet.

Part of my list produced by the jacksum contains also:

Code:

...[snip]...
./var/log:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 .keep
0865284e0ad073d61bd4bea63ec8c1919d22f3dabfa8cccc372af43f6b5377ee dmesg
9c85830fdb7ec273cf385f6fe7b60175756cc210808988b9f00e3d5c3ecbc895 emerge-fetch.log
69372f01d295b0d76e1908e941dc586beaec3c6ac37f2aa7cfea29d3956b5fd1 emerge.log
e18db14a91744f2560b9333483407eecdb871982d511db9a7c41f198b8e2cfde faillog
181c93e1b98bc221a9927c7a4aed22b79365aa94dba22ef7885c627d24e5909a lastlog
5994c0468b34429d285cae992186d1cadecbe4ac801eb228702868118dea46a3 messages
...[snip]...


And that last line contains the hashed main Gentoo logfile messages that I
cited heavily from in the main article.

The screencast/dumpcap-ing helped me compare the logs with the network traffic
captures, and so I was able to say that "the logging below" was "chronological
with the commented commands" and produce technically correct reports.

The analysis of network traffic captures, or packet dumps, is however still
not my strong side, such as, I haven't yet figured out what really happened
with what this screencast shows (I also have an accompanying dump there)

http://www.CroatiaFidelis.hr/gnu/zerk/Screen_140902_1926_g0n.mkv

but there is the same one suspect certainly there to not dismiss, now with
this knowledge and evidence.

I always, well really most of the time, it is a hefty overhead of work on
top of whatever that I'm doing when I go online, I, nearly, always keep
screencast/dumpcap-ing along...

By the way, the adding of me to spamhaus.org RBL has nothing to do with the
email that I sent. The email was to the hoster of my domain CroatiaFidelis.hr.
It was a support issue connectied exactly to the problem in the above
screencast.

It also has nothing to do with the n4m3.localdomain being not accepted for
being a phantasy domain either, because, and if someone doubted that, I could
present the email, because the email was regularly sent with all the necessary
translations previously put in the /etc/postfix/generic, so was sent with the
Code:

From: mrovis.fake@croatiafidelis.hr

(only with my real address), so that was pure arrogance on me the user.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
======= cut off from this line to end if verifying hashes =======
File corresponding to this post: Gen_140905_smtp-tls-wrapper-mode_and_beserk_provider_ADDENDUM.txt,
which has some data concealed
has Publictimestamp # 1240502
and is based on non-concealed, unprotected, so not
published full data file Gen_140905_smtp-tls-wrapper-mode_and_beserk_provider.txt
with Publictimestamp # 1240508
--
publictimestamp.org/ptb/PTB-21547 sha256 2014-09-05 18:01:46
E19499140167F375D4D69952569EFBBDB2AB10842FDD26E7EC75509CD1736FDD
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sun Sep 07, 2014 10:21 pm    Post subject: Reply with quote

Talking of this outdated smtp-tls-wrapper-mode it will be useful here for
users who may have not spent so much time as me configuring it, to know why it
is still around.

While I presume (haven't mailed in many years with any tool by Billy the legal
plunderer of the wealth of the lazy and/or stupid, or plain underinformed and
unhelped majority of the world, so a moral criminal, turned eugenical
phylantropist, aarrgghhh!!)... So while Windoze 7/8 I presume is on terms with
STARTTLS, the ole glorious (oh yeah...) XP is not, and it's still very much
used:

https://en.wikipedia.org/wiki/Usage_share_of_operating_systems

Couple that information with a recent thread, August 2014, from postfix-users
mailing-list.

That one M$ instance, the XP Windoze, IIUC, has the Outlook client as default.
Lots of those, I'd believe, in my country and many other countries, so my
Plus.hr hoster will keep catering for them, and that means smtp-tls-wrapper
mode isn't going anywhere for years to come.

Couple that information with this recent thread, in which you can see, the
information of our interest, what postfix developers say about it:

(the thread):
Configuring postfix for outgoing SSL
http://archives.neohapsis.com/archives/postfix/2014-08/thread.html#140

but you don't need all of it, just see here:

http://archives.neohapsis.com/archives/postfix/2014-08/0144.html
where it reads:
Quote:

Some systems don't accept STARTTLS but can use the long-deprecated
"wrappermode" smtps, typically on port 465.


and here:

http://archives.neohapsis.com/archives/postfix/2014-08/0146.html
where it reads:
Quote:

To support Outlook as an SSL/TLS submission client, you need to
setup the smtps (input) wrapper-mode service as described in
TLS_README. Outlook indeed does not support "TLS" (that is
STARTTLS) and only supports SSL encapsulated SMTP on port 465.


Let me just résumé:

"Outlook indeed does not support "TLS" (that is STARTTLS)" (Viktor Dukhovni),
the STARTTLS which would have been much easier to configure on the client
side, which this topic of mine here on Gentoo Forums that you're reading right
now is about, as well as on the server side, which that thread on
postfix-users is about.

So much for this (difficult to deal with) legacy case to stay longer with us.

But I'm actually a little relieved, because I tried for weeks last year and
wasn't able to configure postfix for this smtp-tls-wrapper scenario, and had
to go for the incomplete (no local mail) sSTMP, which is much easier to
configure.

Namespace with/without on dovecot server on/off and issues
https://www.mail-archive.com/mutt-users@mutt.org/msg47119.html

That's where I admited defeat.

As a digression for people configuring their mail non-GUI with Mutt and good
programs like Getmail and Maildrop and Dovecot, I suggest you go from the
start of that thread:

https://www.mail-archive.com/mutt-users@mutt.org/msg47120.html

discarding/skimming through wrong guesses and unsuccessful configurations, and
you should be able to find a fine advice there somewhere, and, importantly, in
the links from there, such as my really successful getmail, and maildrop
deployment.

And if you are using Iptables, which is another basic need for Air-Gapped,

( I was advised to set them here:
https://forums.gentoo.org/viewtopic-p-7558880.html#7546202
jonathan183 wrote:

I'd set iptables to block incoming (except established connections), and only
allow outgoing ports you require

and he says more there, which I don't yet fully understand (and I didn't have
iptables back than either, I now do! :-) ) ... )

So for Iptables, that you need to deploy for Air-Gapped, read here:

Linux: Iptables # 16 How to allow secure mail SMTPS?
http://www.cyberciti.biz/tips/linux-iptables-16-how-to-allow-secure-mail-smtps.html

Next in this topic, I thought I'd put a summary from the dumpcap network
packet capture of those few moments that I stowed away the entire snapshot of
my Gentoo installed system in two different storages for.

For the newer users of Gentoo, if they reach here, to understand a little more
easily, there is one unknown to go clear now. The urd which wasn't in the
previous texts, but is only a synonym for the other names for the same port
already used, which are dealt with in the previous posts.

Code:

$ cat /etc/services | grep urd
urd        465/tcp        smtps ssmtp    # URL Rendesvous Directory for SSM / smtp protocol over TLS/SSL
$


Now there will be less unknowns in the Wireshark dump_140904_2317_g0n.pcap
network packet capture file, which gives us another angle at those moments of
my first successful sending with Postfix with stunnel, sasl and friends.

Code:

ca500c45eab18322e3dfa96faf5c8d6a0538393bdd69f72f504aa6927dddb88b dump_140904_2317_g0n.pcap


The dumpcap (which installs with wireshark) captures in pcapng format (packet
capture new generation, IIUC), which for this analysis is unsuitable like any
non-text.

I opened it in Wireshark, where the capture is best viewed, and from the menu:

File > Export Packet Dissections > as "Plain Text" file

where I specified the packet range 13-116.

The packets shown are not easy for a newbie to understand, but the
no-poetteringware Gentoo system:

Uninstalling dbus and *kits (to Unfacilitate Remote Seats)
https://forums.gentoo.org/viewtopic-t-992146.html

[the no-poetteringware Gentoo system] that I had decided to install for me and
then successfully attained to install, which tentative:

Air-Gapped Gentoo Install, Tentative
https://forums.gentoo.org/viewtopic-t-987268.html

[which tentative] now, as imperfect as it has been, and as imperfect as I have
been able to express myself there in that topic and topics linked to, for you
to rummage through and figure out your own Air-Gapped, or some other, way,
that tentative does seem to be successful...

[The packets shown are not easy for a newbie to understand], but the
Air-Gapped Gentoo system how I install it, and which I recommend to anyone who
wants to live free, free like true GNU, like true GNU/Linux the dying and
being exterminated kind:

Defeat and Hope for GNU/Linux
http://forums.debian.net/viewtopic.php?t=116472

[which I recommend to anyone who wants to live free], which freedom there is
none, nada, zilch, without privacy, and only liers or stupids could claim that
there were no backdoors, so noone did so here:

NSA SELinux Support???
https://forums.gentoo.org/viewtopic-t-984066.html

[only liers or stupids could claim that there were no backdoors], no surveillance
wholesale, no intrusion in your privacy in the mainstream GNU/Linux the
defeated kind of today, on you dear gentle poor Joe user like me, in this day
and age of the post-Snowden Orwellian time.

[The packets shown are not easy for a newbie to understand,] but the
Air-Gapped Gentoo Install that I recommend to any thinking GNU/Linuxer, needs
at least fair understanding of matters like packet captures, for its
successful deployment in defence of your privacy, conditio sine qua non,
condition without which there isn't any, freedom.

Fair understanding. I don't understand those in full either, but I am heading
toward possessing a reliable Gentoo GNU/Linux that is not owned by anyone but
me who installed it, which is just not the usual case, other than with the
elite, who not all tell you all they know, and not even all that you really
need to know, and in terms of the GNU freedom, are entitled to know, dear
fellow user.

There would be other issues that a newbie would not understand, like
certificates. Those can be studied in two places where knowledge is freely
given to public by real experts.

First, though, to goodnaturely tease you, I read those offline as I in most
cases emerge programs with "doc" flag like this (will look clickable, but
generally won't open anything):
http://localhost/docs/apache-2.4.10-r1/manual/
and:
http://localhost/docs/postfix-2.11.1-r1/html/
or in case of Apache, simply:
http://localhost/manual/
but that also takes installing and configuring Apache.

So here is where I spent long hours reading and now understand a little on the
certificates:
http://www.postfix.org/TLS_README.html
Postfix TLS Support
and
https://httpd.apache.org/docs/2.4/ssl/
esp.
https://httpd.apache.org/docs/2.4/ssl/ssl_faq.html

There, I gave enough tips for even a brave and diligent newbie, if he went the
steep curve, to go, and come back ready to understand what the network packets
will tell us.

Here's the pcap export file (CEAL in the name for conCEALed some of the data):

http://www.croatiafidelis.hr/gnu/zerk/Gen_140904_2317_dump_n4m3_TLS_CEAL.txt

Next, some egrepping and some choice packets from that file.

Miroslav Rovis
Zagreb, Croatia
http://www.croatiafidelis.hr
======= cut off from this line to end if verifying hashes =======
File corresponding to this post: Gen_140904_2317_dump_n4m3_TLS_divers_Outlook_to_stay.txt,
has Publictimestamp # 1240742
--
publictimestamp.org/ptb/PTB-21564 sha256 2014-09-07 21:01:45
FF9C8DA3C10A938B7E53262E65CB81CC634A467945B60CC3FC978C7E3FBE1B64


Last edited by miroR on Sun Sep 07, 2014 10:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sun Sep 07, 2014 10:40 pm    Post subject: Reply with quote

A short presentation of that pcap export that I posted on my NGO's domain, for
a few more separate key packets exports, can be gotten by downloading that
file:
wget -nc http://www.croatiafidelis.hr/gnu/zerk/Gen_140904_2317_dump_n4m3_TLS_CEAL.txt

and egrep'ing it with:

Code:

$ egrep -C1 "     1[3-9] 41|     2[0-9] 41|     3[0-9] 41|     4[0-9] 41| \
4[0-9] 42|     5[0-9] 42"  dump_140904_2317_n4m3_TLS_CEAL.txt


That should get you this short list.

Code:

No.     Time           Source                Destination           Protocol Length Info
     13 41.561625000   127.0.0.1             127.0.0.1             TCP      76     39025→11125 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=166610668 TSecr=0 WS=128

--
No.     Time           Source                Destination           Protocol Length Info
     14 41.561641000   127.0.0.1             127.0.0.1             TCP      76     11125→39025 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=166610668 TSecr=166610668 WS=128

--
No.     Time           Source                Destination           Protocol Length Info
     15 41.561668000   127.0.0.1             127.0.0.1             TCP      68     39025→11125 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=166610668 TSecr=166610668

--
No.     Time           Source                Destination           Protocol Length Info
     16 41.561930000
                   === data withheld by the author ;-) ===
--
No.     Time           Source                Destination           Protocol Length Info
     17 41.562250000
                   === data withheld by the author ;-) ===
--
No.     Time           Source                Destination           Protocol Length Info
     18 41.562258000   192.168.8.94          178.218.164.164       TCP      76     41972→urd [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=166610669 TSecr=0 WS=128

--
No.     Time           Source                Destination           Protocol Length Info
     19 41.584647000   178.218.164.164       192.168.8.94          TCP      76     urd→41972 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1420 SACK_PERM=1 TSval=956256092 TSecr=166610669 WS=128

--
No.     Time           Source                Destination           Protocol Length Info
     20 41.584716000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=166610691 TSecr=956256092

--
No.     Time           Source                Destination           Protocol Length Info
     21 41.584997000   192.168.8.94          178.218.164.164       TLSv1    227    Client Hello

--
No.     Time           Source                Destination           Protocol Length Info
     22 41.610709000   178.218.164.164       192.168.8.94          TCP      68     urd→41972 [ACK] Seq=1 Ack=160 Win=6912 Len=0 TSval=956256118 TSecr=166610692

--
No.     Time           Source                Destination           Protocol Length Info
     23 41.628909000   178.218.164.164       192.168.8.94          TLSv1    1476   Server Hello

--
No.     Time           Source                Destination           Protocol Length Info
     24 41.628947000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=160 Ack=1409 Win=32128 Len=0 TSval=166610736 TSecr=956256134

--
No.     Time           Source                Destination           Protocol Length Info
     25 41.630414000   178.218.164.164       192.168.8.94          TCP      1476   [TCP segment of a reassembled PDU]

--
No.     Time           Source                Destination           Protocol Length Info
     26 41.630430000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=160 Ack=2817 Win=35072 Len=0 TSval=166610737 TSecr=956256134

--
No.     Time           Source                Destination           Protocol Length Info
     27 41.633585000   178.218.164.164       192.168.8.94          TCP      1348   [TCP segment of a reassembled PDU]

--
No.     Time           Source                Destination           Protocol Length Info
     28 41.633609000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=160 Ack=4097 Win=37888 Len=0 TSval=166610740 TSecr=956256134

--
No.     Time           Source                Destination           Protocol Length Info
     29 41.654203000   178.218.164.164       192.168.8.94          TLSv1    1077   Certificate

--
No.     Time           Source                Destination           Protocol Length Info
     30 41.654238000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=160 Ack=5106 Win=40704 Len=0 TSval=166610761 TSecr=956256160

--
No.     Time           Source                Destination           Protocol Length Info
     31 41.656897000   192.168.8.94          178.218.164.164       TLSv1    394    Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

--
No.     Time           Source                Destination           Protocol Length Info
     32 41.694746000   178.218.164.164       192.168.8.94          TLSv1    127    Change Cipher Spec, Encrypted Handshake Message

--
No.     Time           Source                Destination           Protocol Length Info
     33 41.710009000   178.218.164.164       192.168.8.94          TLSv1    318    Application Data, Application Data

--
No.     Time           Source                Destination           Protocol Length Info
     34 41.710168000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=486 Ack=5415 Win=43520 Len=0 TSval=166610817 TSecr=956256200

--
No.     Time           Source                Destination           Protocol Length Info
     35 41.710246000   127.0.0.1             127.0.0.1             TCP      243    11125→39025 [PSH, ACK] Seq=1 Ack=1 Win=43776 Len=175 TSval=166610817 TSecr=166610668

--
No.     Time           Source                Destination           Protocol Length Info
     36 41.710272000   127.0.0.1             127.0.0.1             TCP      68     39025→11125 [ACK] Seq=1 Ack=176 Win=44800 Len=0 TSval=166610817 TSecr=166610817

--
No.     Time           Source                Destination           Protocol Length Info
     37 41.710397000   127.0.0.1             127.0.0.1             TCP      90     39025→11125 [PSH, ACK] Seq=1 Ack=176 Win=44800 Len=22 TSval=166610817 TSecr=166610817

--
No.     Time           Source                Destination           Protocol Length Info
     38 41.710420000   127.0.0.1             127.0.0.1             TCP      68     11125→39025 [ACK] Seq=176 Ack=23 Win=43776 Len=0 TSval=166610817 TSecr=166610817

--
No.     Time           Source                Destination           Protocol Length Info
     39 41.710507000   192.168.8.94          178.218.164.164       TLSv1    158    Application Data, Application Data

--
No.     Time           Source                Destination           Protocol Length Info
     40 41.740571000   178.218.164.164       192.168.8.94          TLSv1    286    Application Data, Application Data

--
No.     Time           Source                Destination           Protocol Length Info
     41 41.740736000   127.0.0.1             127.0.0.1             TCP      216    11125→39025 [PSH, ACK] Seq=176 Ack=23 Win=43776 Len=148 TSval=166610847 TSecr=166610817

--
No.     Time           Source                Destination           Protocol Length Info
     42 41.740953000   127.0.0.1             127.0.0.1             TCP      153    39025→11125 [PSH, ACK] Seq=23 Ack=324 Win=45952 Len=85 TSval=166610848 TSecr=166610847

--
No.     Time           Source                Destination           Protocol Length Info
     43 41.741011000   192.168.8.94          178.218.164.164       TLSv1    222    Application Data, Application Data

--
No.     Time           Source                Destination           Protocol Length Info
     44 41.774254000   178.218.164.164       192.168.8.94          TLSv1    142    Application Data, Application Data

--
No.     Time           Source                Destination           Protocol Length Info
     45 41.774417000   127.0.0.1             127.0.0.1             TCP      76     11125→39025 [PSH, ACK] Seq=324 Ack=108 Win=43776 Len=8 TSval=166610881 TSecr=166610848

--
No.     Time           Source                Destination           Protocol Length Info
     46 41.813844000   127.0.0.1             127.0.0.1             TCP      68     39025→11125 [ACK] Seq=108 Ack=332 Win=45952 Len=0 TSval=166610921 TSecr=166610881

--
No.     Time           Source                Destination           Protocol Length Info
     47 41.813867000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=730 Ack=5707 Win=46336 Len=0 TSval=166610921 TSecr=956256277

--
No.     Time           Source                Destination           Protocol Length Info
     48 42.226400000   178.218.164.164       192.168.8.94          TLSv1    206    Application Data, Application Data

--
No.     Time           Source                Destination           Protocol Length Info
     49 42.226452000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=730 Ack=5845 Win=49152 Len=0 TSval=166611333 TSecr=956256730

--
No.     Time           Source                Destination           Protocol Length Info
     50 42.226616000   178.218.164.164       192.168.8.94          TLSv1    190    Application Data, Application Data

--
No.     Time           Source                Destination           Protocol Length Info
     51 42.226640000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=730 Ack=5967 Win=49152 Len=0 TSval=166611333 TSecr=956256730

--
No.     Time           Source                Destination           Protocol Length Info
     52 42.226690000   127.0.0.1             127.0.0.1             TCP      133    11125→39025 [PSH, ACK] Seq=332 Ack=108 Win=43776 Len=65 TSval=166611333 TSecr=166610921

--
No.     Time           Source                Destination           Protocol Length Info
     53 42.226742000   127.0.0.1             127.0.0.1             TCP      68     39025→11125 [ACK] Seq=108 Ack=397 Win=45952 Len=0 TSval=166611333 TSecr=166611333

--
No.     Time           Source                Destination           Protocol Length Info
     54 42.226943000   127.0.0.1             127.0.0.1             TCP      114    11125→39025 [PSH, ACK] Seq=397 Ack=108 Win=43776 Len=46 TSval=166611334 TSecr=166611333

--
No.     Time           Source                Destination           Protocol Length Info
     55 42.226968000   127.0.0.1             127.0.0.1             TCP      68     39025→11125 [ACK] Seq=108 Ack=443 Win=45952 Len=0 TSval=166611334 TSecr=166611334

--
No.     Time           Source                Destination           Protocol Length Info
     56 42.227049000   178.218.164.164       192.168.8.94          TLSv1    190    Application Data, Application Data

--
No.     Time           Source                Destination           Protocol Length Info
     57 42.227062000   192.168.8.94          178.218.164.164       TCP      68     41972→urd [ACK] Seq=730 Ack=6089 Win=49152 Len=0 TSval=166611334 TSecr=956256730

--
No.     Time           Source                Destination           Protocol Length Info
     58 42.227069000   178.218.164.164       192.168.8.94          TCP      68     urd→41972 [FIN, ACK] Seq=6089 Ack=730 Win=9088 Len=0 TSval=956256730 TSecr=166610921

--
No.     Time           Source                Destination           Protocol Length Info
     59 42.227104000   127.0.0.1             127.0.0.1             TCP      125    11125→39025 [PSH, ACK] Seq=443 Ack=108 Win=43776 Len=57 TSval=166611334 TSecr=166611334


And here are some of the packets with the critical information, the packets
23, 29, 41, 42, 52 and 59, for our figuring out how the network handshakes,
the certificates and the encryption (which encrypts not the headers which are
visible, but only the body of the message) goes:

Code:

No.     Time           Source                Destination           Protocol Length Info
     23 41.628909000   178.218.164.164       192.168.8.94          TLSv1    1476   Server Hello

Frame 23: 1476 bytes on wire (11808 bits), 1476 bytes captured (11808 bits) on interface 0
    Interface id: 0 (any)

...[snip]...

Linux cooked capture
    Packet type: Unicast to us (0)
    Link-layer address type: 1
    Link-layer address length: 6
    Source: 00:23:45:ad:ff:81 (00:23:45:ad:ff:81)
    Protocol: IP (0x0800)
Internet Protocol Version 4, Src: 178.218.164.164 (178.218.164.164), Dst: 192.168.8.94 (192.168.8.94)
    Version: 4

...[snip]...

    Source: 178.218.164.164 (178.218.164.164)
    Destination: 192.168.8.94 (192.168.8.94)
Transmission Control Protocol, Src Port: urd (465), Dst Port: 41972 (41972), Seq: 1, Ack: 160, Len: 1408
    Source Port: urd (465)
    Destination Port: 41972 (41972)

...[snip]...

Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 81
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 77
            Version: TLS 1.0 (0x0301)
            Random
                GMT Unix Time: Sep  4, 2014 23:18:37.000000000 CEST
                Random Bytes: 6c9bb3a64c67ba12fac17478139b0647a9b03f736f496c73...
            Session ID Length: 32
            Session ID: bd1ae72fee72d5edeb9f2826a6faf6e93971476976c1f042...
            Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

...[snip]...

0000  00 00 00 01 00 06 00 26 91 f9 58 11 00 00 08 00   .......&..X.....
...[snip]...
00e0  04 06 13 02 47 42 31 1b 30 19 06 03 55 04 08 13   ....GB1.0...U...
00f0  12 47 72 65 61 74 65 72 20 4d 61 6e 63 68 65 73   .Greater Manches
0100  74 65 72 31 10 30 0e 06 03 55 04 07 13 07 53 61   ter1.0...U....Sa
0110  6c 66 6f 72 64 31 1a 30 18 06 03 55 04 0a 13 11   lford1.0...U....
0120  43 4f 4d 4f 44 4f 20 43 41 20 4c 69 6d 69 74 65   COMODO CA Limite
0130  64 31 18 30 16 06 03 55 04 03 13 0f 45 73 73 65   d1.0...U....Esse
0140  6e 74 69 61 6c 53 53 4c 20 43 41 30 1e 17 0d 31   ntialSSL CA0...1
0150  32 30 31 31 38 30 30 30 30 30 30 5a 17 0d 31 35   20118000000Z..15
0160  30 32 31 36 32 33 35 39 35 39 5a 30 5b 31 21 30   0216235959Z0[1!0
0170  1f 06 03 55 04 0b 13 18 44 6f 6d 61 69 6e 20 43   ...U....Domain C
0180  6f 6e 74 72 6f 6c 20 56 61 6c 69 64 61 74 65 64   ontrol Validated
0190  31 1e 30 1c 06 03 55 04 0b 13 15 45 73 73 65 6e   1.0...U....Essen
01a0  74 69 61 6c 53 53 4c 20 57 69 6c 64 63 61 72 64   tialSSL Wildcard
01b0  31 16 30 14 06 03 55 04 03 14 0d 2a 2e 6d 6f 6a   1.0...U....*.moj
01c0  73 69 74 65 2e 63 6f 6d 30 82 01 22 30 0d 06 09   site.com0.."0...
...[snip]...
03a0  01 02 02 07 30 2b 30 29 06 08 2b 06 01 05 05 07   ....0+0)..+.....
03b0  02 01 16 1d 68 74 74 70 73 3a 2f 2f 73 65 63 75   ....https://secu
03c0  72 65 2e 63 6f 6d 6f 64 6f 2e 63 6f 6d 2f 43 50   re.comodo.com/CP
03d0  53 30 08 06 06 67 81 0c 01 02 01 30 3b 06 03 55   S0...g.....0;..U
03e0  1d 1f 04 34 30 32 30 30 a0 2e a0 2c 86 2a 68 74   ...40200...,.*ht
03f0  74 70 3a 2f 2f 63 72 6c 2e 63 6f 6d 6f 64 6f 63   tp://crl.comodoc
0400  61 2e 63 6f 6d 2f 45 73 73 65 6e 74 69 61 6c 53   a.com/EssentialS
0410  53 4c 43 41 2e 63 72 6c 30 6e 06 08 2b 06 01 05   SLCA.crl0n..+...
0420  05 07 01 01 04 62 30 60 30 38 06 08 2b 06 01 05   .....b0`08..+...
0430  05 07 30 02 86 2c 68 74 74 70 3a 2f 2f 63 72 74   ..0..,http://crt
0440  2e 63 6f 6d 6f 64 6f 63 61 2e 63 6f 6d 2f 45 73   .comodoca.com/Es
0450  73 65 6e 74 69 61 6c 53 53 4c 43 41 5f 32 2e 63   sentialSSLCA_2.c
0460  72 74 30 24 06 08 2b 06 01 05 05 07 30 01 86 18   rt0$..+.....0...
0470  68 74 74 70 3a 2f 2f 6f 63 73 70 2e 63 6f 6d 6f   http://ocsp.como
0480  64 6f 63 61 2e 63 6f 6d 30 25 06 03 55 1d 11 04   doca.com0%..U...
0490  1e 30 1c 82 0d 2a 2e 6d 6f 6a 73 69 74 65 2e 63   .0...*.mojsite.c
04a0  6f 6d 82 0b 6d 6f 6a 73 69 74 65 2e 63 6f 6d 30   om..mojsite.com0
04b0  0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 03 82   ...*.H..........
...[snip]...
05c0  d2 f3 08 00                                       ....

No.     Time           Source                Destination           Protocol Length Info
     29 41.654203000   178.218.164.164       192.168.8.94          TLSv1    1077   Certificate

Frame 29: 1077 bytes on wire (8616 bits), 1077 bytes captured (8616 bits) on interface 0
  Interface id: 0 (any)
  Encapsulation type: Linux cooked-mode capture (25)
  Arrival Time: Sep  4, 2014 23:18:45.906540000 CEST

...[snip]...

  [Protocols in frame [truncated]: sll:ethertype:ip:tcp:ssl:pkcs-1:x509sat:x509sat:
  x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:pkcs-1:x509ce:x509ce:x509ce:x509ce:
  x509ce:x509ce:pkix1explicit:x509ce:pkix1implicit:x509ce:pkcs-1:pkcs-1:x509sa]

...[snip]...

Linux cooked capture
  Packet type: Unicast to us (0)
  Link-layer address type: 1
  Link-layer address length: 6
  Source: 00:23:45:ad:ff:81 (00:23:45:ad:ff:81)
  Protocol: IP (0x0800)
Internet Protocol Version 4, Src: 178.218.164.164 (178.218.164.164), Dst: 192.168.8.94 (192.168.8.94)
  Version: 4

...[snip]...

  Source: 178.218.164.164 (178.218.164.164)
  Destination: 192.168.8.94 (192.168.8.94)

Transmission Control Protocol, Src Port: urd (465), Dst Port: 41972 (41972),
Seq: 4097, Ack: 160, Len: 1009

  Source Port: urd (465)
  Destination Port: 41972 (41972)
  [Stream index: 1]

...[snip]...

Secure Sockets Layer
  TLSv1 Record Layer: Handshake Protocol: Certificate
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 5005
    Handshake Protocol: Certificate
      Handshake Type: Certificate (11)
      Length: 5001
      Certificates Length: 4998
      Certificates (4998 bytes)
        Certificate Length: 1306

        Certificate
        (id-at-commonName=*.mojsite.com,id-at-organizationalUnitName=EssentialSSL
        Wildcard,id-at-organizationalUnitName=Domain Control Validated)

          signedCertificate
            version: v3 (2)
            serialNumber : 0x5cd84a4a3037d6e342a56357d34ba635
            signature (shaWithRSAEncryption)
              Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)
            issuer: rdnSequence (0)

              rdnSequence: 5 items (id-at-commonName=EssentialSSL
              CA,id-at-organizationName=COMODO CA
              Limited,id-at-localityName=Salford,id-at-stateOrProvinceName=Greater
              Manchester,id-at-countryName=GB)


...[snip]...

            validity
              notBefore: utcTime (0)
                utcTime: 12-01-18 00:00:00 (UTC)
              notAfter: utcTime (0)
                utcTime: 15-02-16 23:59:59 (UTC)

...[snip]...

              Extension (id-pe-authorityInfoAccessSyntax)
                Extension Id: 1.3.6.1.5.5.7.1.1 (id-pe-authorityInfoAccessSyntax)
                AuthorityInfoAccessSyntax: 2 items
                  AccessDescription
                    accessMethod: 1.3.6.1.5.5.7.48.2 (id-pkix.48.2)
                    accessLocation: 6
                      uniformResourceIdentifier: http://crt.comodoca.com/EssentialSSLCA_2.crt
                  AccessDescription
                    accessMethod: 1.3.6.1.5.5.7.48.1 (id-pkix.48.1)
                    accessLocation: 6
                      uniformResourceIdentifier: http://ocsp.comodoca.com

...[snip]...

                RDNSequence item: 1 item (id-at-commonName=COMODO Certification Authority)
                  RelativeDistinguishedName item (id-at-commonName=COMODO Certification Authority)
                    Id: 2.5.4.3 (id-at-commonName)
                    DirectoryString: printableString (1)
                      printableString: COMODO Certification Authority
            validity
              notBefore: utcTime (0)
                utcTime: 06-12-01 00:00:00 (UTC)
              notAfter: utcTime (0)
                utcTime: 19-12-31 23:59:59 (UTC)

...[snip]...

        Certificate Length: 1199

        Certificate (id-at-commonName=COMODO Certification
        Authority,id-at-organizationName=COMODO CA
        Limited,id-at-localityName=Salford,id-at-stateOrProvinceName=Greater
        Manchester,id-at-countryName=GB)

          signedCertificate
            version: v3 (2)
            serialNumber : 0x2e79832e908887ea8b8ef31a6ee67a44
            signature (shaWithRSAEncryption)
              Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)
            issuer: rdnSequence (0)

              rdnSequence: 6 items (id-at-commonName=UTN - DATACorp
              SGC,id-at-organizationalUnitName=http://www.usertrust.com,id-at-organizationName=The
              USERTRUST Network,id-at-localityName=Salt Lake
              City,id-at-stateOrProvinceName=UT,id-at-countryName=U

                RDNSequence item: 1 item (id-at-countryName=US)
                  RelativeDistinguishedName item (id-at-countryName=US)
                    Id: 2.5.4.6 (id-at-countryName)
                    CountryName: US
                RDNSequence item: 1 item (id-at-stateOrProvinceName=UT)
                  RelativeDistinguishedName item (id-at-stateOrProvinceName=UT)
                    Id: 2.5.4.8 (id-at-stateOrProvinceName)
                    DirectoryString: printableString (1)
                      printableString: UT
                RDNSequence item: 1 item (id-at-localityName=Salt Lake City)
                  RelativeDistinguishedName item (id-at-localityName=Salt Lake City)
                    Id: 2.5.4.7 (id-at-localityName)
                    DirectoryString: printableString (1)
                      printableString: Salt Lake City
                RDNSequence item: 1 item (id-at-organizationName=The USERTRUST Network)
                  RelativeDistinguishedName item (id-at-organizationName=The USERTRUST Network)
                    Id: 2.5.4.10 (id-at-organizationName)
                    DirectoryString: printableString (1)
                      printableString: The USERTRUST Network
                RDNSequence item: 1 item (id-at-organizationalUnitName=http://www.usertrust.com)
                  RelativeDistinguishedName item (id-at-organizationalUnitName=http://www.usertrust.com)

...[snip]...

        Certificate (id-at-commonName=UTN - DATACorp
        SGC,id-at-organizationalUnitName=http://www.usertrust.com,id-at-organizationName=The
        USERTRUST Network,id-at-localityName=Salt Lake
        City,id-at-stateOrProvinceName=UT,id-at-countryName=US)

          signedCertificate
            version: v3 (2)
            serialNumber : 0x46eaf096054cc5e3fa65ea6e9f42c664
            signature (shaWithRSAEncryption)
              Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)
            issuer: rdnSequence (0)

...[snip]...

            validity
              notBefore: utcTime (0)
                utcTime: 05-06-07 08:09:10 (UTC)
              notAfter: utcTime (0)
                utcTime: 20-05-30 10:48:38 (UTC)
            subject: rdnSequence (0)

              rdnSequence: 6 items (id-at-commonName=UTN - DATACorp
              SGC,id-at-organizationalUnitName=http://www.usertrust.com,id-at-organizationName=The
              USERTRUST Network,id-at-localityName=Salt Lake
              City,id-at-stateOrProvinceName=UT,id-at-countryName=U

...[snip]...

              Extension (id-ce-extKeyUsage)
                Extension Id: 2.5.29.37 (id-ce-extKeyUsage)
                KeyPurposeIDs: 2 items
                  KeyPurposeId: 1.3.6.1.4.1.311.10.3.3 (iso.3.6.1.4.1.311.10.3.3)
                  KeyPurposeId: 2.16.840.1.113730.4.1 (joint-iso-itu-t.16.840.1.113730.4.1)
              Extension (id-ce-certificatePolicies)
                Extension Id: 2.5.29.32 (id-ce-certificatePolicies)
                CertificatePoliciesSyntax: 1 item
                  PolicyInformation
                    policyIdentifier: 2.5.29.32.0 (id-ce-certificatePolicies.0)
              Extension (id-ce-cRLDistributionPoints)
                Extension Id: 2.5.29.31 (id-ce-cRLDistributionPoints)
                CRLDistPointsSyntax: 2 items
                  DistributionPoint
                    distributionPoint: fullName (0)
                      fullName: 1 item
                        GeneralName: uniformResourceIdentifier (6)
                          uniformResourceIdentifier: http://crl.comodoca.com/AddTrustExternalCARoot.crl
                  DistributionPoint
                    distributionPoint: fullName (0)
                      fullName: 1 item
                        GeneralName: uniformResourceIdentifier (6)
                          uniformResourceIdentifier: http://crl.comodo.net/AddTrustExternalCARoot.crl
          algorithmIdentifier (shaWithRSAEncryption)
            Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)
          Padding: 0
          encrypted: 63869210b113fa37be8e2ab61b8a43f55cae0e14dff76940...
Secure Sockets Layer
  TLSv1 Record Layer: Handshake Protocol: Server Hello Done
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 4
    Handshake Protocol: Server Hello Done
      Handshake Type: Server Hello Done (14)
      Length: 0

No.     Time           Source                Destination           Protocol Length Info
     41 41.740736000   127.0.0.1             127.0.0.1             TCP      216    11125→39025 [PSH, ACK] Seq=176 Ack=23 Win=43776 Len=148 TSval=166610847 TSecr=166610817

Frame 41: 216 bytes on wire (1728 bits), 216 bytes captured (1728 bits) on interface 0
    Interface id: 0 (any)
    Encapsulation type: Linux cooked-mode capture (25)
    Arrival Time: Sep  4, 2014 23:18:45.993073000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1409865525.993073000 seconds
    [Time delta from previous captured frame: 0.000165000 seconds]
    [Time delta from previous displayed frame: 0.000165000 seconds]
    [Time since reference or first frame: 41.740736000 seconds]

...[snip]...

Linux cooked capture
    Packet type: Unicast to us (0)
    Link-layer address type: 772
    Link-layer address length: 6
    Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Protocol: IP (0x0800)
Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
    Version: 4

...[snip]...

    Source: 127.0.0.1 (127.0.0.1)
    Destination: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 11125 (11125), Dst Port: 39025 (39025), Seq: 176, Ack: 23, Len: 148
    Source Port: 11125 (11125)
    Destination Port: 39025 (39025)

...[snip]...

Data (148 bytes)

0000  32 35 30 2d 6c 69 6e 31 36 2e 6d 6f 6a 73 69 74   250-lin16.mojsit
0010  65 2e 63 6f 6d 20 48 65 6c 6c 6f 20 31 34 37 2d   e.com Hello 147-
0020  32 32 36 2e 64 73 6c 2e 69 73 6b 6f 6e 2e 68 72   226.dsl.iskon.hr
0030  20 5b 38 39 2e 31 36 34 2e 31 34 37 2e 32 32 36    [89.164.147.226
0040  5d 0d 0a 32 35 30 2d 53 49 5a 45 20 35 32 34 32   ]..250-SIZE 5242
0050  38 38 30 30 0d 0a 32 35 30 2d 38 42 49 54 4d 49   8800..250-8BITMI
0060  4d 45 0d 0a 32 35 30 2d 50 49 50 45 4c 49 4e 49   ME..250-PIPELINI
0070  4e 47 0d 0a 32 35 30 2d 41 55 54 48 20 50 4c 41   NG..250-AUTH PLA
0080  49 4e 20 4c 4f 47 49 4e 0d 0a 32 35 30 20 48 45   IN LOGIN..250 HE
0090  4c 50 0d 0a                                       LP..
    Data: 3235302d6c696e31362e6d6f6a736974652e636f6d204865...
    [Length: 148]

No.     Time           Source                Destination           Protocol Length Info
     42 41.740953000   127.0.0.1             127.0.0.1             TCP      153    39025→11125 [PSH, ACK] Seq=23 Ack=324 Win=45952 Len=85 TSval=166610848 TSecr=166610847

Frame 42: 153 bytes on wire (1224 bits), 153 bytes captured (1224 bits) on interface 0
    Interface id: 0 (any)
    Encapsulation type: Linux cooked-mode capture (25)
    Arrival Time: Sep  4, 2014 23:18:45.993290000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1409865525.993290000 seconds

...[snip]...

Linux cooked capture
    Packet type: Unicast to us (0)
    Link-layer address type: 772
    Link-layer address length: 6
    Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Protocol: IP (0x0800)
Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
    Version: 4

...[snip]...

    Source: 127.0.0.1 (127.0.0.1)
    Destination: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 39025 (39025), Dst Port: 11125 (11125), Seq: 23, Ack: 324, Len: 85
    Source Port: 39025 (39025)
    Destination Port: 11125 (11125)

...[snip]...

Data (85 bytes)

0000  4d 41 49 4c 20 46 52 4f 4d 3a 3c 6d 69 72 6f 2e   MAIL FROM:<miro.
0010  72 6f 76 69 73 40 63 72 6f 61 74 69 61 66 69 64   rovis@croatiafid
0020  65 6c 69 73 2e 68 72 3e 20 53 49 5a 45 3d 34 39   elis.hr> SIZE=49
0030  32 38 0d 0a 52 43 50 54 20 54 4f 3a 3c 73 75 70   28..RCPT TO:<sup
0040  70 6f 72 74 40 70 6c 75 73 2e 68 72 3e 0d 0a 44   port@plus.hr>..D
0050  41 54 41 0d 0a                                    ATA..
    Data: 4d41494c2046524f4d3a3c6d69726f2e726f766973406372...
    [Length: 85]

No.     Time           Source                Destination           Protocol Length Info
     52 42.226690000   127.0.0.1             127.0.0.1             TCP      133    11125→39025 [PSH, ACK] Seq=332 Ack=108 Win=43776 Len=65 TSval=166611333 TSecr=166610921

Frame 52: 133 bytes on wire (1064 bits), 133 bytes captured (1064 bits) on interface 0
    Interface id: 0 (any)
    Encapsulation type: Linux cooked-mode capture (25)
    Arrival Time: Sep  4, 2014 23:18:46.479027000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1409865526.479027000 seconds
    [Time delta from previous captured frame: 0.000050000 seconds]
    [Time delta from previous displayed frame: 0.000050000 seconds]
    [Time since reference or first frame: 42.226690000 seconds]

...[snip]...

Linux cooked capture
    Packet type: Unicast to us (0)
    Link-layer address type: 772
    Link-layer address length: 6
    Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Protocol: IP (0x0800)
Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
    Version: 4
    Header Length: 20 bytes

...[snip]...

    Source: 127.0.0.1 (127.0.0.1)
    Destination: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 11125 (11125), Dst Port: 39025 (39025), Seq: 332, Ack: 108, Len: 65
    Source Port: 11125 (11125)
    Destination Port: 39025 (39025)

...[snip]...

Data (65 bytes)

0000  35 35 30 2d 22 4a 75 6e 6b 4d 61 69 6c 20 72 65   550-"JunkMail re
0010  6a 65 63 74 65 64 20 2d 20 31 34 37 2d 32 32 36   jected - 147-226
0020  2e 64 73 6c 2e 69 73 6b 6f 6e 2e 68 72 xx xx xx   .dsl.iskon.hr (n
0030  xx xx xx 6c 6f 63 61 6c 64 6f 6d 61 69 6e 29 0d   4m3.localdomain)
0040  0a                                                .
    Data: 3535302d224a756e6b4d61696c2072656a6563746564202d...
    [Length: 65]

No.     Time           Source                Destination           Protocol Length Info
     59 42.227104000   127.0.0.1             127.0.0.1             TCP      125    11125→39025 [PSH, ACK] Seq=443 Ack=108 Win=43776 Len=57 TSval=166611334 TSecr=166611334

Frame 59: 125 bytes on wire (1000 bits), 125 bytes captured (1000 bits) on interface 0
    Interface id: 0 (any)
Linux cooked capture

...[snip]...

    Packet type: Unicast to us (0)
    Link-layer address type: 772
    Link-layer address length: 6
    Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Protocol: IP (0x0800)
Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
    Version: 4

...[snip]...

    Source: 127.0.0.1 (127.0.0.1)
    Destination: 127.0.0.1 (127.0.0.1)
Transmission Control Protocol, Src Port: 11125 (11125), Dst Port: 39025 (39025), Seq: 443, Ack: 108, Len: 57
    Source Port: 11125 (11125)
    Destination Port: 39025 (39025)

...[snip]...

0000  35 35 30 20 68 74 74 70 3a 2f 2f 77 77 77 2e 73   550 http://www.s
0010  70 61 6d 68 61 75 73 2e 6f 72 67 2f 71 75 65 72   pamhaus.org/quer
0020  79 2f 62 6c 3f 69 70 3d 38 39 2e 31 36 34 2e 31   y/bl?ip=89.164.1
0030  34 37 2e 32 32 36 22 0d 0a                        47.226"..
    Data: 35353020687474703a2f2f7777772e7370616d686175732e...
    [Length: 57]



That is how a free GNU/Linuxer (which I'm not a model of, just striving to be),
once she or he gets their mail configured should be able to check on their sent
mail and see there are certificates and TLS lines, and all.

Sure, if the provider is fine, the mail will be sent with these great programs
that I have employed and shown here.

Thanks everybody for the patience, and thanks Gentoo GNU/Linux community for
great opportunity for a real Operating System, however non-mainstream and so
necessarily so much more difficult to compile it, that it may have been.

I'll be around for a little longer if there are replies. More than probably a
day or so later replierer might need to wait for me to find time to visit here.
I am oldish and not very healthy, and I work really slowly.

Miroslav Rovis
Zagreb, Croatia
http://www.croatiafidelis.hr
======= cut off from this line to end if verifying hashes =======
File corresponding to this post: Gen_140904_2317_dump_n4m3_TLS_divers_analysis.txt,
has the Publictimestamp # 1240742
I noticed and applied some corrections to it soon afterwards
the new file Gen_140904_2317_dump_n4m3_TLS_divers_analysis_COR.txt
has Publictimestamp # 1240754
--
publictimestamp.org/ptb/PTB-21564 sha256 2014-09-07 21:01:45
FF9C8DA3C10A938B7E53262E65CB81CC634A467945B60CC3FC978C7E3FBE1B64
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Fri Oct 31, 2014 6:01 pm    Post subject: Reply with quote

miroR wrote:

...[snip]...
(had recently installed
iptables as well, and proper ulogd-logging).

Configuring iptables firewall on Gentoo
http://gentoovps.net/configuring-iptables-firewall/
...[snip]...

That link is obsolete way to configure your iptables (for newbies not to get taken the wrong way, wrong because deprecated).
You need to configure them with conntrack module...

Update :2016-03-21 13:12+01:00 No! I was wrong. It is not deprecated! Pls see "Update no. 2" in this link:
(thist same topic)
https://forums.gentoo.org/viewtopic-t-999436.html#7895428


Last edited by miroR on Mon Mar 21, 2016 12:12 pm; edited 1 time in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Tue Jan 13, 2015 9:51 pm    Post subject: Reply with quote

EDIT Sun 18 Jan 21:21 CET 2015 Reformatted for better viewing.
and if I may ad one thing, about Gentoo. I don't think there is anything more important than security for your computor in virtual life, just as are the keys to your home in real life. And I regret not having mentioned that when I wrote to T-com and readers here how I get security in my system.

Gentoo is the leader in the world in security, and I mean real user-empowering, true security: the Grsecurity. See on Gentoo Wiki about: Hardened/Grsecurity2 Quickstart, which bundles Pax Hardened/PaX Quickstart.

There is no more powerful system today by design than Grsecurity/Hardened Gentoo (or Funtoo, I can't help but give a link here to a dream of mine....)
When I wrote below about how safe my system relatively is, the info of today was missing.
EDIT END
--
This is, first the header, then the text of the email, that I will be sending to the address shown below, and I'll be sending it from my address shown below, in the headers, after posting it here.

The sole difference between the email proper and the post I converted it into, is in formatting which I may try to adapt a little better yet for viewing on these forums, while I wait to see possible reactions.

But later, if this part of the entire story which has three topics in itself so far: cloning/backup method, postfix-tls-configuration, and censorship revealed by analysis of the packets captured...

But I will reformat this text, more nicely for viewing, later, if this part which is about hard-to-deny censorship, and which part is somewhat more on the social then the technical side of the entire, predominantly technical, story that I have deployed here so far, if this part is allowed here as I ask more clearly and in detail towards the end of the email/post, in bottom.

This is, however, necessary for the understanding of the entire topic, and is pretty healthy for your mind to really understand the dire need that we, as a community of freedom loving hackers (not crackers, but hackers, not criminals, but lovers of honesty and truth and common good in the internet and computing world, hackers of which I am certainly more of an aspirant than a member, my technical prowess being far too low, as yet, and likely to remain so)...

This somewhat more social part of this story is, however, healthy for the minds of especially new Gentoo and generally FOSS Linux users, to grasp the necessity and the dire need to build methods in the fight for our privacy.

I am not talking about the necessity of only the ideas and the methods that I learned and put in practice so far, I'm actually saying that when you read this, you will clearly understand that even more, even much more, might really be needed. This fight may yet be getting, as it already has for some of the best hackers in the world, some actually completely innocent or just minimally to blame... [This fight] for freedom and privacy [may yet be getting], here and there, for some and for other people, really hard.

(This text above is actually the last that I wrote in this post. Bear in mind when reading especially the end part of the email/post. The final thoughts are in this text above, not in bottom.)
---

Code:

Date: Tue, 13 Jan 2015 18:10:03 +0100
From: miroslav.rovis1@zg.ht.hr
To: abuse.admin@t-com.hr
Subject: Re: Upozorenje T-Com administratora
Message-ID: <20150113171003.GC5585@g0n>
References: <201501071514.t07FEl0h016593@ls239.t-com.hr>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature";
        boundary="FsscpQKzF/jJk6ya"
Content-Disposition: inline
In-Reply-To: <201501071514.t07FEl0h016593@ls239.t-com.hr>
User-Agent: Mutt/1.5.23 (2014-03-12)


I'll give a translation, so my English speaking friends can see the problem imposed on me (probably for no reason, or even completely invented, for purposes of censorship; but let's see if we can talk with those at all...).

I'll try and keep to literal translation when I can, will resort to more descriptive and equivalent translation where it fits better.

Štovani T-com! (Respectable T-com!) moj odgovor nađite nakon prievoda vašeg teksta! (find my reply after the translation of your text).

On Wed, Jan 07, 2015 at 04:14:47PM +0100, abuse.admin@t-com.hr wrote:

HR T-com wrote:

Postovani,

Dear Customer,
HR T-com wrote:

Nadzorom naseg servera uocili smo da je s Vaseg korisnickog imena: rovismi1 generiran mail potencijalnog reklamnog sadrzaja (spam mail).

After inspecting our server we have noticed that from Your user account: rovismi1 there has been generated a mail of potentially promotive content (spam mail).
HR T-com wrote:

Molimo Vas da to vise ne cinite.

We kindly ask you not to do that any more.
HR T-com wrote:

Ukoliko je to pocinjeno bez Vaseg znanja najvjerojatnije imate virus (ili trojanskog konja) na racunalu. Stoga Vas molimo da sto prije instalirate neki od antivirusnih programa (odnosno trojan removal tool) koji ima informaciju o novim virusima (trojanima) i pocistite sva racunala s kojih ste se spajali na internet.

In case that the above has been committed without your knowledge you probably have a virus (or a trojan) in your computor. So we kindly ask you to install some antivirus software (or some trojan removal tool) as soon as possible, which would be up to date with the new viri (trojans), and to cleanse all yout computors from which you connected to the internet.
HR T-com wrote:

Ukoliko Vas mail klijent ima podeseno slanje preko mail.t-com.hr servera, Vasa usluga ce nastaviti raditi nesmetano.

In case that your mail client is set to sending mail via mail.t-com.hr servers, the service that we provide for you will be unaffected.
HR T-com wrote:

Radi Vase zastite, na Vas korisnicki racun postavljena je zabrana slanja mailova preko svih mail servera osim preko mail.t-com.hr.

For your protection, on your user account a ban has been placed for sending e-mails from any other servers but mail.t-com.hr.
HR T-com wrote:

Napominjemo da ova mjera nema nikakvog utjecaja na webmail usluge kao sto su gmail, hotmail, yahoo i slicne.

Do take notice that this measure has no influence on webmail services like gmail, hotmail, yahoo and the likes.
HR T-com wrote:

U slucaju da trebate dodatna pojasnjenja, molimo Vas da kontaktirate nasu sluzbu za korisnike na 0800 9000 (privatni korisnici) Ili 0800 9100 (poslovni korisnici).

In case you have additional queries or unclarities, please contact our user service at +385 1 800 9000 (private users) or +385 1 0800 9100 (business users).
HR T-com wrote:

Hvala

Thank you.
HR T-com wrote:

--

Hrvatski Telekom d.d.
Abuse sluzba

sluzba = Service
HR T-com wrote:

e-mail: abuse@t.ht.hr
tel: 0800 9000 (privatni korisnici)
0800 9100 (poslovni korisnici)


I know you speak English fine, dear T-com, and anyway I noticed it is possible as well to ask for and correspond with you in English. So:

Dear T-com Abuse Service!
==========================

I wouldn't say that what you claim above is true, especially I am absolutely in the certain and clear knowledge that I didn't send any spam myself, on the one hand.

But, although is is very unlikely, I, on the other hand, really can not say that there has been no intrusion ever and in whichsoever way into my computors, in any of some perticular periods within the time that I have been your user (just please make sure you read how unlikely it is).

So, what I know, is that I did not send, let alone spam, no!, but almost not any emails whatsoever, almost anywhere at all. So really we can completely dismiss that I were to have spammed other people! Please read on.

The emails that I have sent in, we generally talk just since September 17 2014 when I became your user (although there will be a mention of the immediately previous period), the emails that I sent in this period since September 17, number hardly once or twice the number of fingers on two human hands; although I'd need to go and count those to come with the exact number, that is the order of that number: not even a few dozen mails, let alone hundreds or thousands of mails, no! And, I'm trying to remember, but, no, I don't think other then one single time, only one single time to two recipients, to helpdesk@iskon.hr and support@plus.hr, all the other emails to one single email address only.

And I am talking mails that I successfully sent from my computor, but most of which weren't ever sent forth by you, T-com, at all, so the numbers not discarded, completely baselessly, as junk by you number even less than that already minuscule number.

So, again, the emails that I sent since September 17 when I became your user are hardly more then maybe twenty or fourty emails (and most of those were not sent forth by you at all), but were in brazen and obnoxious fashion discared as junk by you (via other subjects, read on).

Also, since I joined T-com, it's one sole computor which I have any mail agents/programs configured for receiving and sending mails and I send and receive mails from no other computor but that sole one.

And that computor is running probably the best among all FOSS Linux flavors. It is running the Gentoo FOSS Linux, and I built that Gentoo box of mine in particular way that has, through time, even gained some notice in Gentoo community among the more knowledgeable Gentoo circles, and which way of building my Gentoo box has even gained me promotion from lower intermediate level user to somewhat advanced level Gentoo status, since from that method that I described in various posts on Gentoo Forums, newbies to Gentoo can actually learn from, and apply for themselves this particular Air-Gapped method that I described of installing Gentoo.

And please allow me to stress to you that Gentoo FOSS Linux is probably the hardest of FOSS Linux flavors, pretty knowledge learning curve steep and intensive.

And on that Gentoo FOSS Linux of mine I use probably the best and cleanest and most user-enpowering mail receiving and sending programs that are really the least prone to snooping and intrusion of probably all and any programs for sending and receiving emails, in the world of today: Mutt, Postfix, Getmail, Maildrop, Dovecot...

And, back to the emails that I sent, again, hardly did any more than a handful of those emails really go past your servers to be forwarded on to the actual recipients. Rather, you sent them, via other subjects, to junk, most of the my mails.

Via other subjects such as some spam internet "policing" sites that likely get some sleazy money for, on top of some real spam prevention that they nominally exist for, squeezing and clamping down on political dissent and activism.

Let us be in the clear here, that we are talking e-mail account which I pay for, privately, to Plus d.o.o Pula, www.plus.hr (Pula is a Croatian city in Istra, on the Adriatic coast, near Italian border), and the email address of that account which I pay for is:

miro.rovis@croatiafidelis.hr

Yes, we are talking you, dear T-com, not allowing me to use what I legitimately paid for in my country Croatia, and which is my mail-account about which it can easily be looked up with that provider, www.plus.hr, whether any spam, and when, and in what manner, and by what means, and by which intrusion, if any (I'm speaking theoretically; I know it could only have been intrusion, but you, lets say, don't yet know), [whether any spam] was sent, if any (this is really the moot point: if any!), from their servers.

Glad I am, on the one hand, that you are with this "abuse notice" admitting to sending my emails that I send from miro.rovis@croatiafidelis.hr, to spam, as I proved for Iskon that they did (Iskon who I was a user of, previously to becoming your user), and as I can still demonstrate that you, T-com, have done.

This here, about Iskon, is the mention of the previous period that I promised above, and it can be found out about at:

Postfix smtp-tls-wrapper, Bkp/Cloning Mthd, A Zerk Provider
https://forums.gentoo.org/viewtopic-t-999436.html

By the way. I'll try and post this message in another post on that topic on that address. Or you will find a link to this message there in that topic on Gentoo Forums and on that address, today hopefully.

That much about your claim of my, possible (as you thankfully do correct your accusation, but only afterwards, it really sounds despicable!... Thankfully you are not claiming certainty about my "spamming")... That much about your claim of my deliberate "sending" of "spam".

Still, you really really could in just the same fashion, accuse me of, say, jumping from building to building with springs mounted on my shoes, from my Zapruđe block all the way to downtown Zagreb and up to Sljeme over the traitor Government and the outgoing traitor Presidential Palace, over the skyline and without previously having obtained permission from the City authorities for my pranks...

Or you could really really downright accuse me for flying from my appartment in Zapruđe, over the river Sava and all the way over Count Jelačić Square and over the Traitor Prime Minister Milanović's goverment and over the Presidential Palace where the Traitor President Josipović is about to finally be purged from on February 18 2015, and onto our beautiful Sljeme Mount on the North of the City, there and back with, say, portable wings.

Yeah, you could accuse me, exampli gratia, of flying with portable wings, or jumping through the skyline on springs, to Sljeme.

You really could do that with just about the same level of plausability as goes for your claim that I were spamming from my computors.

Just about the same level of plausability you can get for those!

On the other hand, as I took care to put it up front in the top, truly I can not say that there has been no intrusion ever whensoever and in whichsoever way into my computors.

Some snoopers, most notably Google, and others such as various secret services (oh but the latter find the former the best of all accomplices and associates and the paramount spying services provider)... But some snoopers, most notably Google, are still without my reach as to what exactly they do when they snoop into my computors, for the little, really tiny amount of the time that I am online.

Now this is important. T-com knows it, but not all the other readers of this text yet do.

The time that I am online usually measures in a few minutes per day. Some days just a little longer but it still hardly amounts to say one hour, per day. Very rarely, but very rarely, and I mean very rarely, do I stay longer yet online.

For all the rest of the time, I am offline.

For completeness, there is just the IPTV the Croatian T-com's brand name for it being MaxTV. However, if any emails whatsoever get to be sent from it, it can only be up to you, T-com. As far as I go, I have not, and don't intend to use the internet surfing option or any option close to emailing, that it may provide.

For completeness, likewise, anything that may happen with the adsl-router is up to you as well, you check those.

It is, however, true that in some of those periods that I am online, I, as yet, do not have complete control. But plese read on; and do not take this nor any other of my claims out of context.

Because no, I'm not saying that I lack control for those short periods, short intervals online in my rare-presence-online days. Those I can mostly see through what exactly happened... Mostly I have those under my control, although even there a stretch here or there is sadly possible where I may not be able to know what exactly happened...

But I am talking about the lack of control to a major extent only for my time online in those rare longer periods that I am online. There, sadly, sometimes I sill can not put all the pieces together as to who and what might have intruded and done what exactly...

I intend to learn to deal with that, so I may improve in that respect, in the future.

However, notice again, that those, the longer periods of my being on-line, have been rare.

Dear T-com, allow me to point out, here, to you, that I don't probably need to bother particularly about your advice on viri and trojans. I'll explain, even though that advice of yours is a usual bugbear that can be used by providers in their sleazy setups to politically dissenting users like me...

(Just for more of completeness, as far as viri and trojans go, no, ClamAV, which I sometimes run, doesn't find real viri nor trojans in my computors, just the usual unavoidable Structurals and Heuristics and the like.)

So let me, as I said, explain. I keep my computors that I allow online, strictly only online. They don't see any of the computors which live on my SOHO at all. And vice versa, the computors communicating between themselves from the SOHO don't see those that are allowed online at all. Not through wire, let alone through wireless, and also little or no use of media unsafe by design such as USB sticks, to not go into detail.

Hard and arduous air-gapping I apply. And cloning, as you can read about in:

Postfix smtp-tls-wrapper, Bkp/Cloning Mthd, A Zerk Provider [ link already given above ]

Also see here:

Air-Gapped Gentoo Install, Tentative
https://forums.gentoo.org/viewtopic-t-987268.html

There is also my "Air-Gapped Debian Install for Newbies" tip on Debian Forums in the Tips and Tricks section.

The cloning that I use may not protect me from some mass-surveillance and mass-control retail Stuxnet kind of virus (oh, it's those M$ Hotmail, and gmail and yahoo that you mention you would allow me to use, that know soo well about the mass-surveillance and control, those gmails and yahoos and M$ hotmails and the likes, so lets not bother here, just don't tell me you don't know what I am talking about)...

But while if, say, you or UDBA (the secret service in Tito's Yugoslavia, of Tito the Slaughterer and the Oppressor of Croats; it's past, but the neocommunists still holding the reins of power, like Milanović and Josipović, both sons of Titoist worse followers, we then still call the secret service in Croatia UDBA just the same)...

But I was saying, while my methods can not protect me from some very intricate and elaborate retail Stuxnet kind of virus if, say, you or UDBA decide to plant something in my computor, something like some such virus (and, again, sure you can ask Google the Surveillance Engine about those), still these methods of mine most certainly provide a very reliable way of restoring my system into clean state. Because I build my system in the SOHO that sees no internet whatsoever and I use the best methods there are for Air-Gapping.

It's pretty technical for avarage readers (and I do hope my connationals will read this, as there we have bright young men and women that can follow here just fine), but it's the emerge-webrsync and portage snapshots and a local mirror the methods that I use and which are superb methods, matchlesss methods, and so nothing goes in my quiet and humming SOHO easily to corrupt and plant viri...

But I was saying, while my methods might not be an impenetrable barrier for retail Schmoog the Surveillance Engine Snooper Secret Service Friend Big Octopus of the Internet whose tentacles no one can avoid for long...

I was saying, while my methods are not an completely impenetrable barrier, aren't you, my provider, Croatian T-com there to provide some aditional barrier for my safety and not instead ad difficulty in the equation as you seem to do?

Please, do prove to me that you want to help, and not aggravate.

I'll suggest to you a way to do so now.

Because, back to talking about what might have happened in the rare cases when I didn't have complete insight into what might have happened during my stay online, on the bright side of things, I really can investigate that which might have happened. Because I take network captures of what happened online with my computor...

Unless you, dear T-com, want to keep your claim unsubstantiated, such as if you have rigged it in collusion with some snoopers of the internet that rig people for reasons such as persecution of activists and political opponents, that is: unless your claim really has no meat, we can, together, find out, maybe even precisely, what happened, and when that exact what happened, by means of which intrusion into which of my computors it happened and similar.

I certainly do hope that you either will not stick to your claim if it has no meat, or that you will help me understand when exactly which email, and to whom, was sent from some of my computors.

Because, as I said, I take network captures and keep pretty comprehensive logs anyhow, and especially of my time online, so I don't think you can go with a complete non-disclosure regarding of which email was sent and when from my connection to your servers when I went online.

I can really tell you with some likelihood, that if you give me the time when that mail was, or times when those mails were, sent from some of my computors connected to your servers, that I am likely to give you more data as to whence the intrusion came.

Namely, I just very rarely go online without a complete network capture, along with screencasting what I do online, and more. (And, again, even that is about to hopefully improve for the better.)

So, dear T-com, do dress your claim with some meat and let's solve this problem.

I really hope for your sensible reply.

I want to stress only one last thing that to any reasonable reader sticks way out of the strange abuse claims by my provider here.

Dear T-com, I don't have any problems that you ban any other mail server but your own, mail.t-com.hr, and pls. take good notice, and:

lin16.mojsite.com

that is, in IPv4: 178.218.164.164

which I pay for the hosting of, along with my other domains that are hosted there, http://www.CroatiaFidelis.hr , http://www.exDeo.com , http://www.rovis.org and http://www.vankina2-10.com.

As far as email address, I can not accept that you ban me from using my miro.rovis@croatiafidelis.hr unless spam has been sent from there, which I don't think you could get http://www.plus.hr to accept such accusation of on your part. No! No spam has been sent from miro.rovis@croatiafidelis.hr, unless you or the Internet's own despicable Octopus set up some medium level Stuxnet kind against them, to purposefully find them at fault!

Do ban everything else, if you really have to, just give me the freaking back my freedom to use what I pay for!

Thank you!

And thank you, Gentoo community. Surveillance-free FOSS Linux is best built with Gentoo!

--
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

Any errors, corrections, and improvements to the methods to use, as well as further issues, likely more technical and more fitting for the Gentoo Forums, I will try and post on:

Postfix smtp-tls-wrapper, Bkp/Cloning Mthd, A Zerk Provider https://forums.gentoo.org/viewtopic-t-999436.html
(giving the link one last time in this text)

Pls bear with me, this is stressful, freedom endangering, time consuming, and it is breaking my back, and all this after about a week of high fever illness that drained my forces up unto a few days ago.

Dear Gentoo community, do report this page if this isn't sufficiently in your view about Gentoo, and if most of the senior members decide that it is not acceptable, I will remove it with a link to this text that you currently read underneath the:

Postfix smtp-tls-wrapper, Bkp/Cloning Mthd, A Zerk Provider
(link given the second and last time in this text a few lines above)

I will not oppose if a few senior members decide this text does not belong here, but will comply. Pls. give me a few hours in that case. Ny back is a little broken with all the effort, and my nerves a little shattered. Thank you.

This text, on the other hand, is identical with what I am about to send to Croatian T-com. First though, I posted it on Gentoo Forums. Those are freaking dangerous bunch of control freaks, you really don't know how they will react. So I have to beg you for more time, in case I get really, really censored by them and can't even get to Gentoo Forums (although that is hopefully not so likely).

Do notice, again, that, with time, not promptly, I intend to deploy here issues more technical and more fitting for the Gentoo Forums. There should be not at all much social stuff next for quite a while here from me in this topic but rather really techie stuff, network packets and stories and queries and research... With time, Vis Major (Latin), permitting...


Last edited by miroR on Sun Jan 18, 2015 8:37 pm; edited 2 times in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sun Jan 18, 2015 1:37 am    Post subject: Reply with quote

Pls. read also the "Update no.1" at:
(this same topic)
https://forums.gentoo.org/viewtopic-t-999436.html#7895428
and just imagine how this clickjacking would have been plain and undeniable if I had known at the ime of my dumpcap'ing and screencasting of these files in this post you are reading, what I know now, by the time of that update just linked to.
---
Here's something yummy from my analysis of my latest surfing some two days:

Schmoog and Yooch in (What?) Action
http://www.croatiafidelis.hr/cap/cap-150117-1423_Schm-Yooch/

Will try and formulate the issue clearer yet, Vis Major permitting.

Good night, I think (but I never know about that).

EDIT Thu 5 Feb 00:21:30 CET 2015 START
Perhaps some aditional explanation, together with an insight into the road that I traveled since I started understanding these matters, can be read in my old topic that I revisited today:

System attacked, Konqueror went on window-popping spree!
https://forums.gentoo.org/viewtopic-t-905472-start-25.html#7696040

Namely, study the capture file that I gave, and the screencast.

That
is
clickjacking

(same link as already given in this post).

EDIT END


Last edited by miroR on Mon Mar 21, 2016 12:10 pm; edited 5 times in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sat Jan 31, 2015 8:00 pm    Post subject: Reply with quote

Only 4:14 online (just over four minutes), and a clipboard-jacking (if there is such a term) happened.

Since it is best when files' hashes are recorded A.S.A.P., these are the files:

Code:

38e443e61f0417a3d39591b4a8e9afa1e8b57f4887e10e06b9526602f3108ba7 dump_150131_1721_g0n.pcap
ef7a43e7dbed9c3c957dc3f734300772e5a91bdb46e43a23fe4eb799c7b47cf7 Screen_150131_1721_g0n.mkv


And as far as conntrack, which I used to run "conntrack -E ..." previously, I did (and I suggest to readers, after they "emerge conntrack-tools" or similarly of course):

Code:

# rc-update add conntrackd default


and some configuration, and then after you issue:

Code:

# tailf /var/log/conntrackd-stats.log


in, say, the same rxvt-unicode (or other terminal) where you do "dumpcap ..." (or "tcpdump ...") network capture, you get lots of timely info.

I also suggest the package iptstate.

I'm working very hard. Deployed tripwire and rkhunter (which, just checked, haven't reported anything really suspicious).

But pls. allow time for me to present this recent event.

I have postponed work on my Debian Forums Tip:

Grsecurity/Pax installation on Debian GNU/Linux
http://forums.debian.net/viewtopic.php?f=16&t=108616&start=45#p566911

because of my work to secure my Gentoo system.

I absolutely now first need to secure what Grsecurity can not do via kernel hardening (and where it does a marvelous job), but I need to properly deploy Gradm policies and all, id est the grsecurity RBAC system. This is currently the major weekness in my system... Racing against time... (but at a slow pace, I work so sloowly...)
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sat Jan 31, 2015 11:15 pm    Post subject: Reply with quote

Will reformat this post when I find time.

Why is Postfix a true FOSS program from free people for free people? Such as Grsecurity is, among programs, and such as Gentoo/Funtoo is among OS'es?

Read the shiny truth that brave and honest developers don't hide, cost what it may:

TO CHECK and POST:
Piece of honest information first:
http://www.postfix.org/postconf.5.html#tls_eecdh_strong_curve

where it reads:

The default "strong" curve is rated in NSA

Suite B
http://www.nsa.gov/ia/programs/suiteb_cryptography/

for information classified up to SECRET.

Piece of honest information second:
http://www.postfix.org/postconf.5.html#tls_eecdh_ultra_curve

where it reads:

This default "ultra" curve is rated in NSA

Suite B
(warning: same link as just given above)
http://www.nsa.gov/ia/programs/suiteb_cryptography/

for information classified up to TOP SECRET.

And everybody relies on these IIUC! They go and mail from the Schmoog or Yooch (pronounced like the "ch" in Loch Ness), and don't get it that they're harvested. All that they write. No secrets!

In fact, it is secrets! It is secrets! Secret it is for you and me what Schmoog and Yooch and such do in our machines! Those are secrets!

I just can not tire to remind of the absolutely marvelous video presentation by Poul-Heening Kamp, FOSDEM Conference in 2014 IIRC:

http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm

where listen, among other things, about the secrecy by design (sic!), on us, on all of us, on the general public, of the SSL!

Piece of information third, nay, a shiny page on the web made of warm and loving-kind intellectual offer:

TLS Forward Secrecy
http://www.postfix.org/FORWARD_SECRECY_README.html

So of course my goal is to, some day, hopefully before I'm of the age of Metusaleh, Vis Major allowing, learn to use the TLS Forward Secrecy.

I just had to post this, it fits here, for free people from me, free thinking oldish man Miroslav Rovis.

I mean when am I going to learn to decrypt and read the encrypted conversations that those surveillors do on my computer when I'm online? Can you when they sniff into your machines? Only really Seniors even in Gentoo, can, I'm afraid.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon Feb 02, 2015 9:40 pm    Post subject: Reply with quote

My problems with the provider may be nearing Chinese style clampdown on dissidents, and it seems to me it is being performed by means of deploying Chinese programs developed for that purpose. It seems to me they're deploying those programs on me at level designed for potentially knowledgeable, and in their eyes, pretty obnoxious users.

There was a longer intro here, a plead for some patience to Moderators concerning my style of writing, and you can hopefully (some kind of sly censorship never to exclude) still read it from http://www.CroatiaFidelis.hr:

http://www.CroatiaFidelis.hr/cap/cap-150131-0232_T-com/my-Gentoo-intro-plead.html

The story is layered and complex for a non-expert like me. I was pushed to investigate after I got a "bruteforce prevention initiated" message by PAX:

PAX terminating task on /usr/bin/gdb
https://forums.grsecurity.net/viewtopic.php?f=3&t=4137&p=14928

But I have to start from somewhere.

In my iptables rules, I have the classic:

Code:

/sbin/iptables -P INPUT DROP


then a few other rules not of our concern here at this time, and then

Code:

# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-level error \
   --log-prefix mrfw_no_syn
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP


and also:

Code:

# DROP everything else and Log it
/sbin/iptables -A INPUT -j LOG --log-level error --log-prefix mrfw_drop
/sbin/iptables -A INPUT -j DROP


In my logs the string "mrfw_no_syn" didn't show in the period I am investigating.

But the string "mrfw_drop" does show. And yet everything works fine, other than gdb crashes while debugging postfix.

PAX terminating task on /usr/bin/gdb
https://forums.grsecurity.net/viewtopic.php?f=3&t=4137&p=14928
(same link as in the top)

As you can see, I really thought almost that PaX was at fault, and that it was a false positive "bruteforce prevention initiated" and so I... (I did at very first believe what PaX said in the logs, and only after some while doubted...)

So, rethinking that it was a false positive I even decided, while preparing it, for the initial title of this post from something that I, initially, at the very first, thought should contain the "bruteforce" word in it, to "PAX terminating task on /usr/bin/gdb", but I might yet go back. I might yet go back on that one!

These Wizards there at grsecurity and Pax I think they know all the reasons for what they write in their code...

But let me tell you what made me rethink the very first impression that it was an attack (which I am rethinking back to in these days of intense research).

I build my Gentoo system in air-gapped conditions. It's a poor user's air gap, not an expert one, as neither do I know all the tricks and arcane knowledge nor do I have means to pay for expert work.

My master Gentoo system that I build is never connected to the internet. I have another, same MBO and same HDD capacity system onto which I clone the air-gapped master, via disk dumping (with the command "dd") the system partitions of the master and restoring them onto the clone, and doing some reconfiguration, not so much, and the clone, on its part, never sees the SOHO via wired or wireless.

( this same topic)
https://forums.gentoo.org/viewtopic-t-999436.html#7613044

However, the data that I need for my SOHO, and which I can obviously only get by means of the cloned system from the internet, that data need to be transferred somehow.

Wireless -- too dangerous, so much risk that I have it disabled in T-com (the local Croatian provider) ADSL router and never use it anyway, neither in the smartphone which I also basically disabled completely (only the Regime can still tap me on it, or if they engage some cracker thugs by giving them the information, namely it has old chipcard inside, just so I can use it's sound recorder or camera; you can't otherwise! the freaking Schmoog! --it's and old Samsung Galaxy, unFOSSed Linux in it, total surveillance... It does concern the topic: you enable wireless on such, and on your router, and they can get into your machine).

And neither do I use wired connection to my SOHO via Ethernet card from this cloned online system.

But I use BluRay discs to tansfer my data. I take the hashes of what I prepare for transfer, and check them after the transfer. Never any mismatches, or very rarely, by some mistake of my own.

I also check for rootkits with rkhunter, but I did notice that there hasn't been any updates in the rootkit sourceforge.net central database (I ran rkhunter --update when online a day or two ago, rkhunter had databases up to date, and my system is nearing 2 months without update)... I am sure the zero day people from say Daly Dave mailing list

CHECK Daly Dave
LINK HERE

could tell us more about it, if somebody found a kind and effective way to ask them. To me, this does look strange. People no more inventing rootkits? Or there has been more development beneath the tip of the iceberg on which the rkhunter remains, unable to cope with all of it? It can't cope because things in rootkit tech have gone so perfect as to steal the lustre from and make the perfection of the old Stuxnet look pale?... I don't know.

I rechecked the Maildir (I did check the entire system, but the Maildir is usually the most risky) for viruses where I receive mail, and (this is why I am explaining about it) which I transfer via BluRay discs burning, onto my master system, where I keep another, safer copy of the Mailbox from the online machine.

For the people visiting this topic because they are building their mailing programs for Air-Gapped, I can explain this, because it is really a great thing to have your mail safe and away from the online machine. But I'll make a separate post only about it.

(this same topic)
https://forums.gentoo.org/viewtopic-t-999436.html#7696102

Both those instances of the same Maildir (the online one and the one in my master machine) had the same 21 viruses found, but it's those kind that is not even searched for by default, which means if I didn't set the phishing, structured and pua flags on, there would be no viruses found.

Here the result of this online one. Running this command:
Code:

clamscan -r -i --detect-pua=yes --detect-structured=yes --phishing-sigs=yes /home/miro/Maildir/ 2>&1 > /Cmn/m/clamav/clamscan-r-i-pua-struct-phish_Maidir_`date +%y%m%d_%H`_`hostname`.txt

gave:
Code:

/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409660799.M481148P16773V0000000000000803I00000000003EB308_0.gbn,S=30495:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409661126.M741000P16239V0000000000000803I00000000003EC23E_0.gbn,S=5354:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409660834.M916487P20186V0000000000000803I00000000003EB427_0.gbn,S=9662:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409660799.M890073P16809V0000000000000803I00000000003EB30B_0.gbn,S=33209:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409660799.M192096P16749V0000000000000803I00000000003EB306_0.gbn,S=29340:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1421249417.M1558P8325V0000000000000803I0000000000029AD0_0.g0n,S=80104:2,Sa: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409660834.M781261P20174V0000000000000803I00000000003EB426_0.gbn,S=14447:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409661273.M40629P30460V0000000000000803I00000000003EC6DC_0.gbn,S=14369:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409661274.M138345P30569V0000000000000803I00000000003EC6E5_0.gbn,S=7857:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1409661126.M852229P16251V0000000000000803I00000000003EC23F_0.gbn,S=3035:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.postfix-users@postfixorg/cur/1418256470.M768147P8390V0000000000000803I00000000000E1AAC_0.g0n,S=20653:2,Sa: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr.dovecotdovecotorg/cur/1409661698.M854674P6697V0000000000000803I00000000003ED413_0.gbn,S=12666:2,S: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mrovis@inethr.djecamedjugorja@gmailcom/new/1409660007.M193551P7033V0000000000000803I00000000003E9A29_0.gbn,S=3509948: Heuristics.Structured.CreditCardNumber FOUND
/home/miro/Maildir/.mrovis@inethr.djecamedjugorja@gmailcom/new/1409660003.M444410P6973V0000000000000803I00000000003E9A24_0.gbn,S=3403175: Heuristics.Structured.CreditCardNumber FOUND
/home/miro/Maildir/.mrovis@inethr.djecamedjugorja@gmailcom/new/1409660005.M350589P6997V0000000000000803I00000000003E9A26_0.gbn,S=4132191: Heuristics.Structured.CreditCardNumber FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr/cur/1409660626.M301958P621V0000000000000803I00000000003EAD7C_0.gbn,S=6654:2,: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr/cur/1409660626.M187430P613V0000000000000803I00000000003EAD7B_0.gbn,S=4872:2,: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mirorovis@croatiafidelishr/cur/1409660626.M58667P605V0000000000000803I00000000003EAD7A_0.gbn,S=8173:2,: Heuristics.Structured.SSN FOUND
/home/miro/Maildir/.mrovis@inethr/cur/1409659364.M345146P13521V0000000000000803I00000000003E10EA_0.gbn,S=4364:2,S: PUA.Phishing.Bank FOUND
/home/miro/Maildir/.mrovis@inethr/cur/1409659372.M161293P13978V0000000000000803I00000000003E1123_0.gbn,S=4453:2,S: PUA.Phishing.Bank FOUND
/home/miro/Maildir/.mrovis@inethr/cur/1409659429.M54245P16709V0000000000000803I00000000003E128A_0.gbn,S=1437069:2,: PUA.Win32.Packer.Upx-48 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 3739345
Engine version: 0.98.5
Scanned directories: 384
Scanned files: 23490
Infected files: 21
Data scanned: 422.61 MB
Data read: 208.89 MB (ratio 2.02:1)
Time: 130.358 sec (2 m 10 s)

Again, that would have been "Infected files: 0" without those flags.

Pls. compare that with the huge number of such non-default viruses found in any Gentoo mirror! It's oldish scan, but it serves the purpose. Why I took it and posted it, read here:

Air-Gapped Gentoo Install, Tentative
https://forums.gentoo.org/viewtopic-t-987268-start-0.html#7536056

and the viruses found with those flags mentioned above are here:

http://www.croatiafidelis.hr/gnu/gentoo/clamscan_on_my-local-Gentoo-mirror_140414_16.txt.gz
http://www.croatiafidelis.hr/gnu/gentoo/clamscan_on_my-local-Gentoo-mirror_140414_16.txt.sig

BTW, some of the data scanned in my Maildir is compressed, because:
Code:

$ du -sh ~/Maildir
306M   /home/miro/Maildir
$

which is some 100+MB less volume than clamscan reported.

I think I'll try and see about this on the Clamav mailing list. But this does not look suspicious and other things do look suspicious and/or fishy and/or other, which will therefore be my priority.

So, clamscan findings aside, for now, let me go back to the suspicious and/or fishy and/or other.

The "mrfw_drop" drop lines, the packets that iptables didn't allow in. It dropped them, but also logged them.

The /var/log/messages-20150201.gz comprises the time from well before the first mail, to ElektraZagreb@hep.hr, and up to well after the second mail, to centarzakorisnike@zgh.hr.

To ElektraZagreb@hep.hr my email was sent:
Code:

Jan 31 02:42:12 g0n postfix/smtp[17303]: 2A8B238092F: to=<ElektraZagreb@hep.hr>, relay=mail.t-com.hr[195.29.150.5]:25, delay=4629, delays=4619/10/0.27/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 12A9B120224)

It happened during my 21 minutes of paying online, via the service of the name "Internet banking" from http://www.zaba.hr , Zagrebačka banka (name of the bank --robbers like most of the bankers-- which in Croatian stands for Zagrebian bank).

To centarzakorisnike@zgh.hr my mail was sent:
Code:

Feb  1 01:43:06 g0n postfix/smtp[3711]: A415438092E: to=<centarzakorisnike@zgh.hr>, relay=mail.t-com.hr[195.29.150.2]:25, delay=89928, delays=89917/10/0.26/0.06, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 6A86C20B023C)


centarzakorisnike@zgh.hr translates as usercenter@zgh.hr, where zgh is Zagrebački Holding, Zagrebian Holding.

========= MOVE THESE START =============
Zagreb has an honest leftist mayor, Milan Bandić, whom many rightwingers like me support as he is a true Patriot and did so many good things in Zagreb, but he was rigged by the Regime, sent to jail innocent, and hardly made it out to fight the legal battle from freedom against the Traitors.

The message to Elektra, the power company, which overcharged me purposefully; running the machines on my SOHO cost me more for some six months than I really spent simply because they decided to play a prank with the bills of overcharging the poor user Miro. But they now need to return the money, and the deadline for me to let them know that I want the moneys and not for them to keep it and pay my next bills with those moneys is within two or three days from now if I calculate correctly.
========= MOVE THESE END =============

The mail to Eletra is important to me, as they need to return some overpaid money to me, and then I will finally be able to buy a 4TB HDD and work on the really kind advice that NeddySeagoon gave me on:

Recover partly overwritten luks volume?
https://forums.gentoo.org/viewtopic-t-1004014.html

However, the T-com don't know yet that I got the logs that, especially the first message to Elektra, was regularly accepted by their servers and queued for delivery to Elektra. At this time they probably think that I don't have the logs in that regard. Not until they read here. And the problem is they may have decided to send it to spam (just see previous posts, about Iskon, my previous provider and about this T-com, the current one), and if they sent it to spam then I don't get the money! Which they probably would not do, if they knew that I would expose them on it.

And they likely think that I don't know that the mails were accepted, because these emails were sent via a special use of TLSv1, which I believe readers will find very curious. In a minute about that.

But first the dropped packets, which I've started explaining now for the third and final time in this post.

Again, it's a risk to give data unaltered in any way which I will do now, but the overhead of pondering over which exact info to hide is more time than I can afford (such as when I remember how I need to finally save my partly overwritten luks volume)...

All the packets containing the string mrfw_drop from the messages-20150201 syslog-ng log are available from:

http://www.CroatiaFidelis.hr/cap/cap-150131-0232_T-com/messages-20150201_mrfw_drop.txt

I'll post some of it here:
Code:

Jan 30 23:08:37 g0n kernel: [60150.823386] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=18572 PROTO=2
...[snipped 4 lines containing string "SRC=10.16.96.1 DST=224.0.0.1"]...

Jan 31 02:38:20 g0n kernel: [72741.746764] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=173.194.112.109 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=55230 PROTO=TCP SPT=443 DPT=37586 WINDOW=0 RES=0x00 RST URGP=0
Jan 31 02:39:02 g0n kernel: [72783.252133] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=48376 PROTO=2
Jan 31 02:41:07 g0n kernel: [72908.326556] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=15678 PROTO=2
Jan 31 02:42:12 g0n kernel: [72973.410867] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=195.29.150.5 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=TCP SPT=25 DPT=35796 WINDOW=0 RES=0x00 RST URGP=0
Jan 31 02:43:12 g0n kernel: [73033.401105] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=6346 PROTO=2
...[snipped 21 lines containing string "SRC=10.16.96.1 DST=224.0.0.1"]...

Feb  1 00:12:49 g0n kernel: [150453.893565] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=42012 PROTO=2
Feb  1 00:12:58 g0n kernel: [150463.126747] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=216.58.209.168 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=14124 PROTO=TCP SPT=443 DPT=52802 WINDOW=0 RES=0x00 RST URGP=0
Feb  1 00:14:54 g0n kernel: [150578.966823] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=63396 PROTO=2
Feb  1 01:04:54 g0n kernel: [153580.719549] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=26146 PROTO=2
Feb  1 01:06:59 g0n kernel: [153705.792581] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=7074 PROTO=2
Feb  1 01:43:06 g0n kernel: [155873.854559] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=195.29.150.2 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=0 DF PROTO=TCP SPT=25 DPT=50399 WINDOW=0 RES=0x00 RST URGP=0
Feb  1 02:03:14 g0n kernel: [157082.783616] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=40958 PROTO=2
Feb  1 02:28:14 g0n kernel: [158583.665759] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:3c:94:d5:cf:8f:f0:08:00 SRC=10.16.96.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=9072 PROTO=2

Now the lines not containing the string "SRC=10.16.96.1 DST=224.0.0.1" are these 4 lines only:
Code:

Jan 31 02:38:20 g0n kernel: [72741.746764] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=173.194.112.109 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=55230 PROTO=TCP SPT=443 DPT=37586 WINDOW=0 RES=0x00 RST URGP=0
Jan 31 02:42:12 g0n kernel: [72973.410867] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=195.29.150.5 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=TCP SPT=25 DPT=35796 WINDOW=0 RES=0x00 RST URGP=0
Feb  1 00:12:58 g0n kernel: [150463.126747] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=216.58.209.168 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=14124 PROTO=TCP SPT=443 DPT=52802 WINDOW=0 RES=0x00 RST URGP=0
Feb  1 01:43:06 g0n kernel: [155873.854559] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=195.29.150.2 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=0 DF PROTO=TCP SPT=25 DPT=50399 WINDOW=0 RES=0x00 RST URGP=0


And now, the address 173.194.112.109 is pagead.l.doubleclick.net (I looked it up in what Wireshark store bout it with the corresponding pcapng file, and which corresponding pcapng file is:

Code:

b90aa52118489c0c0c20f91ca260daafa4412c7269c15ba342647ee4d2c90ca7  dump_150131_0232_g0n_Zaba.pcap

(but I need yet decide if I can post it, or probably hex-edit some first and and then post it)

), but 173.194.112.0/24 are the Schmoog really (pagead-googlehosted.l.google.com . Wow! this's the first time in this topic after the open email to T-com --I mention it there three times!-- that I use the word for Schmoog! Dija see that?)... In other words exactly at the time I was paying my bills online, the code veiled with the ad on the freaking Zaba bank's page decided it needed to play its fishy packet on my computer.

Here are the packets that my machine received/sent from/to Schmoog (just displayed only that connection from the above dump_150131_0232_g0n_Zaba.pcap file in Wireshark and saved that):

http://www.CroatiaFidelis.hr/cap/cap-150131-0232_T-com/dump_150131_0232_g0n_Zaba_Schmoog.pcap

and it only logged, and then dropped, this one packet, or stream or what (I'm still not deep into the packet capturing):
Code:

Jan 31 02:38:20 g0n kernel: [72741.746764] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=173.194.112.109 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=55230 PROTO=TCP SPT=443 DPT=37586 WINDOW=0 RES=0x00 RST URGP=0


Now this:
Code:

Feb  1 00:12:58 g0n kernel: [150463.126747] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=216.58.209.168 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=14124 PROTO=TCP SPT=443 DPT=52802 WINDOW=0 RES=0x00 RST URGP=0

is ssl-google-analytics.l.google.com (Wow! this's the second time in this topic after the open email to T-com --I mention it there three times!-- that I use the word for Schmoog!). These guys are behaving like the real pests of the internet. Hard to kill (the *nix word for making processes die, no real life, only pun).

And there was also this one packet that was dropped and which wasn't of the "SRC=10.16.96.1 DST=224.0.0.1" kind. (

BTW, that "SRC=10.16.96.1 DST=224.0.0.1" I think is my IPTV connection --branded MaxTV by Croatian T-com--, but what is interesting about those many lines of logged and then dropped packages from the IPTV connection is that at most of those times I wasn't watching it on my old Hauppauge card. Never mind for now.
)

[So there was also] this one packet that was dropped and which wasn't the IPTV src/dst, during the time I was paying online on http://www.zaba.hr :
Code:

Jan 31 02:42:12 g0n kernel: [72973.410867] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=195.29.150.5 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=TCP SPT=25 DPT=35796 WINDOW=0 RES=0x00 RST URGP=0

where 195.29.150.5 is mail.t-com.hr, and here we go what users knowledgeable enough, and in Gentoo and generally FOSS Linux and the whole of the *nixdom there's a host of such, may find interesting:

There are no data about the two emails, which I explained above to whom and why I sent them, that a poor user like me could, as we usually can, recover in the pcapng network capture dumps! I didn't recover those data with the Wireshark and/or its gentle suite of programs! No such thing as "miroslav.FAKE@zg.ht.hr" or "ElektraZagreb@hep.hr"or "Ok: queued as" for the naked eye to see in the entire capture dump!

Feel free to find such unencrypted strings if you can in the capture file:

http://www.CroatiaFidelis.hr/cap/cap-150131-0232_T-com/dump_150131_0232_g0n_Zaba_T-com.pcap

Or if you're a Senior, teach us how us poor users can decrypt and read such conversations!

Nope, of the 39 packets that pertain to the conversation btwn my machine and mail.t-com.hr, the packets:
Code:

22, 23, 24, 25, 28, 30

encrypted with the old TLSv1, that I expect contain those data with strings "miro.FAKE@zg.ht.hr" and "ElektraZagreb@hep.hr" and "Ok: queued as", as was similarly the case --just the To: address was: "support@plus.hr" and the From: was: mrovis.fake@croatiafidelis.hr and the provider was Iskon-- and which can be searched and read on:

(this same topic)
https://forums.gentoo.org/viewtopic-t-999436.html#7613908

almost five months ago now
)

Instead...

In Wireshark, the File > Export Packet Dissections > as "Plain Text" file... is 26k, but here it is for you on http://www.CroatiaFidelis.hr :

http://www.CroatiaFidelis.hr/cap/cap-150131-0232_T-com/dump_150131_0232_g0n_Zaba_T-com_PRIVATE.txt

(as you can see I decided to give to that text file the infix _PRIVATE, and that is because I have an inclination to believe that the Chinese regime's IT wisdom has been used; I'm yet far from explaining that, many other aspects are needed to be explained first, sorry for the delay!)

However I offer you here where those strings "miro.FAKE@zg.ht.hr" and "ElektraZagreb@hep.hr" and "Ok: queued as" should be (as they are in any normal sending/receiving) visible (but are not visible) for me the poor user to see.

The grep command used:
Code:

$ egrep '     2|     3|Encrypted Application Data:' dump_150131_0232_g0n_Zaba_T-com_PRIVATE.txt

Just for easier understanding of the less advanced user, this legend:
Code:

No.     Time           Source                Destination           Protocol Length Info

pertains to the numbered lines.
Code:

     22 0.233400000    192.168.1.2           mail.t-com.hr         TLSv1    121    Application Data
        Encrypted Application Data: 55fd3204fda4146257ea9b8f72e038d8106bc20201ff47a8...

     23 0.250845000    mail.t-com.hr         192.168.1.2           TLSv1    201    Application Data
        Encrypted Application Data: fda81296502174a22998e1e427b743374023a6bdadeeb7ac...

     24 0.252275000    192.168.1.2           mail.t-com.hr         TLSv1    185    Application Data
        Encrypted Application Data: d9bcd40933a19024fedbd2858c1bb07ce4003a42429d7455...

     25 0.275728000    mail.t-com.hr         192.168.1.2           TLSv1    169    Application Data
        Encrypted Application Data: f67a2d6505152a021ba1cd92294a2fee8a03dd7bfb7ec546...

     28 0.276117000    192.168.1.2           mail.t-com.hr         TLSv1    169    Application Data
        Encrypted Application Data: 4908cc770fd7b1f57d53bf9313d00113cd2a171075865868...

     30 0.320352000    mail.t-com.hr         192.168.1.2           TLSv1    153    Application Data
        Encrypted Application Data: 2ff536c5d862c91b9c51c8a9f0e590a6373164f68e9de8ab...


The information that the user in normal free mail server applications such as Postfix server or even Exim server, Courier server, Dovecot server (if I understand correctly), sees, he/she does not see that information in this (I guess, Chinese, but pls. wait, it's a guess as I say in the opening paragraph of this post) private server. That information I believe is encrypted in those
Code:

        Encrypted Application Data: ...[snip]...


The packet 34 is colored red in my Wireshark display, and the packets 35-39 are colored black and described as Spurious Retransmission.

Code:




Notice that it coincides with the mrfw_drop line from /var/log/messages reported time:

(this is a COPY of the line already brought up above)
Code:

Jan 31 02:42:12 g0n kernel: [72973.410867] mrfw_dropIN=eth1 OUT= MAC=00:0e:2e:00:80:45:2c:95:7f:14:4e:c6:08:00 SRC=195.29.150.5 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=TCP SPT=25 DPT=35796 WINDOW=0 RES=0x00 RST URGP=0


One would think that this whether bad packet or a good packet that should have been allowed (but have not much idea in concern yet), that was dropped and only logged, had it been accepted, those red and black colored packets would have been accepted normally instead.

But, two things.

First, this is where PAX terminates the gdb process, apparently every time an email is sent via smtp to the server.

And second, it happens with the local mail delivery.

But where then did I get my information and how then do I know that the message was sent, and when and how?

Some of the answers have been hinted in my new topic on Grsecurity Forums:

PAX terminating task on /usr/bin/gdb
https://forums.grsecurity.net/viewtopic.php?f=3&t=4137&p=14928
(same link as as in the top)

(so how I set up the debugging in Postfix I don't need to explain here).

And I'll try and post and explain now what that setup got me in my /var/log/messages, archived as messages-20150201.gz.

http://www.CroatiaFidelis.hr/cap/cap-150131-0232_T-com/messages-20150201_150131_0232_Zaba.txt

contains excerpt from that system log, taken during my 21 minutes internet banking bout of online paying of my bills, just the part of it when my message to ElektraZagreb@hep.hr, for the return of the moneys they (very likely deliberately) overcharged, was sent (by Postfix flushing the mailqueue without my manually doing anything).

And:

http://www.CroatiaFidelis.hr/cap/cap-150131-0232_T-com/messages-20150201_150201_0142.txt

contains excerpt from that system log, taken during my 6 minutes posting to Grsecurity Forums. just the part of it when my message to centarzakorisnike@zgh.hr was sent (with a short message of support for the treacherously, hyenatically persecuted good mayor of Zagreb Milan Bandić). It was also sent by Postfix flushing the mailqueue without me even being aware of it at the time.

---
I still haven't finished this. Just a little more removing is to be done of "political" text, but I believe it is best that I now first post the files.

Continuing after I take some rest. Don't forget that every time I go online, for me, as yet, is a dozen or a few dozen longer time checking up what happened online.

If anything is missing, check if it is a typo by opening this page, maybe it's there:

http://www.CroatiaFidelis.hr/cap/cap-150131-0232_T-com/

or wait for me to complete this research. Thank you!

---
I have a SHA256 sum that as soon, as I publish and publictimestamp this entire post, the better:
Code:

351f8eb46cdb4131a71e27eba44d11717896c3aeb256020854f3046ff9b778d6  Compo_F0202_2110_SBTV_KEEP.avi

Will explain later.

Below is correct publictimestamp, but for the previous version of this post. I'll publictimestamp this the one last time when I finish this, Vis Major allowing, in a few hours.
#======= cut off from this line to end if verifying hashes =======
#File corresponding to this post: Gen_150202_Postfix-Zerk_T-com.txt,
#has Publictimestamp # 1255298
#--
#publictimestamp.org/ptb/PTB-22746 sha256 2015-02-02 21:01:45
#CFC18F14FD724FA49C7868933F2F4B11C0F69E79B13CDE8CDCCADA14588F1C60


Last edited by miroR on Thu Feb 05, 2015 1:04 am; edited 1 time in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Thu Feb 05, 2015 1:00 am    Post subject: Reply with quote

For people that visit this topic as they're choosing/configuring their mailing programs
for Air-Gapped Installs

To get my mail, I use Getmail. It's very probably the best, better than the old Fetchmail. Lean and mean, never any issues, after my initial ineptitude about it.

The mail that Getmail fetches needs to be dropped into proper mailboxes. For that I use (Courier) Maildrop. Just great!

It's surely Maildir mailboxes type to use nowadays. And I serve them to Mutt with Dovecot via TLS login.
EDIT 2015-09-22 00:26+02:00:
No Dovecot is better probably. Currently in the process of removing it. Does not work so great with Mutt.
(But I'm leaving the old text intact around this and another note below.)
EDIT END
This is how the login looks like.

Mutt without Portage/in Local Overlay, for Air-Gappers
https://forums.gentoo.org/viewtopic-t-1002146.html#7633914
where search for, say: "Officium Centralis"

Mutt I'd never change for any other mailer, even though I'm not yet at advanced stage of using it.

And I use Postfix for sneding mail only (not the server, just the client). Lots of people use that setup nowadays.

It you have same configuration (just the few things I reconfigured in the clone from the master configuration once I restore the master system partitions onto the clone with dd, such as the hostname and the SOHO address; the clone needs to have the SOHO address, regardlee of not seeing any SOHO, so that Apache can serve documents from /usr/share/doc/ for you, or if you have cgit serving you git archives, you also need it)...

It you have same configuration, and in my Air-Gapped method you can't have much difference at all btwn the clone and the master, unless you heavily depart from the same MBO same-or-similar-other-hardware rule, in which case good luck to you, to have your safe Maildir copy which even remembers in Mutt what post you saw and which is new, which has already been answered and all; really exactly the same copy in the master, you need to copy the Maildir (I have the Sent and the Drafts in it too for that reason), and the .getmail folder, and the .mailfilter.log and, most importantly the .duplicate.cache file.

The .duplicate.cache file belongs to Maildrop. If you don't delete on the server straight what Getmail fetches and delivers to Maildrop (and leaving it on the server sometimes might be necessary or safer, esp. for newbies familiarizing with these mailing programs), you will end up re-downloading same mail, and having duplicates in your mailbox, which is very annoying.

I posted my Maildrop .mailfiter configuration file both on the Mutt mailing list and on the Maildrop mailing list. Can't search for it now, but you should be able to find it by my name, it's usique enough: Miroslav Rovis. Also about what is necessary about Getmail, where I solved some issues and posted about them. You can find it in the same way.

EDIT 2015-09-22 00:29+02:00:
It's, if I manage to keep my NGO's www.CroatiaFidelis.hr, still (but signed with my revoked key that I used then; signature is good though) at:

http://www.croatiafidelis.hr/gnu/maildrop/
It is to be:
http://www.croatiafidelis.hr/foss/maildrop/

And it is what I mailed to Courier Maildrop list on SourceForge:

My standalone maildrop configuration files
http://sourceforge.net/p/courier/mailman/message/31585709/
( the first message, and it seems some troubles SF has with web for mail, you can only see it if you, near 2013-10-31 19:18:00,
click on:
Message as HTML which opens it...)

But I also mailed it to mutt-users Mailing List! Where find it in the second of two messages:

Namespace with/without on dovecot server on/off and issues
http://marc.info/?l=mutt-users&m=138178557223737&w=2

this one (of same subject line):
http://marc.info/?l=mutt-users&m=138178696024182&w=2
(But I'm leaving the old text intact around this as around the other note above.)
EDIT END

I'll leave this post a stub, as I have more urgent things to do now.


Last edited by miroR on Mon Sep 21, 2015 10:42 pm; edited 1 time in total
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Sun Feb 08, 2015 1:19 am    Post subject: Reply with quote

In all these adverse and sad censorship and intrusions, I have the joy to present you my idea for a program:

The uncenz
https://github.com/miroR/uncenz

And I'll leave it to your assessment, gentle readers.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Thu Feb 19, 2015 5:15 am    Post subject: Reply with quote

miroR wrote:

...[snip]...
Some of the answers have been hinted in my new topic on Grsecurity Forums:

PAX terminating task on /usr/bin/gdb
https://forums.grsecurity.net/viewtopic.php?f=3&t=4137&p=14928
(same link as as in the top)

(so how I set up the debugging in Postfix I don't need to explain here).


This problem has been identified. Pls. if you want to discuss about it, do it in this other, new, post of mine:

GNU debugger checking for PaX and refusing to work with it
https://forums.gentoo.org/viewtopic-t-1011162.html

or on the Grsecurity Forums (link above).
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon Mar 30, 2015 3:59 am    Post subject: Reply with quote

For those of the readers who have followed this topic, and seen the censorship on me, as well as the intrusions, clearly proven in the posts above, there has been a new foltering of an important activation message by my provider's on me, and I am unable to access the Sleuthkit Forum because of that censorship.

Pls. read here:

Recover partly overwritten luks volume?
https://forums.gentoo.org/viewtopic-t-1004014.html#7724054
and please help me!

I'll post, if you want, the name of you who will hopefully, help me, or I'll keep you anonymous if you like better (but do tell me so when you help me), but if this problem has been solved, a notice will be right on top of that link to that partly overwritten luks volume recovery topic. You don't have to be a Gentoo Forums member to help, anyone with freedom to use email can help me.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Fri Apr 17, 2015 1:16 am    Post subject: Reply with quote

As you can read here:

Air-Gapped Gentoo Install, Tentative
https://forums.gentoo.org/viewtopic-t-987268-start-50.html#7741670

previously at the address of this post there was a post misplaced by me. I actually like it better it having been so, as I can trust Gentoo, in among so much on the internet that I can not and should not trust..

And now the post is useful, while previously it was unclear, misposted like it was.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Tue May 12, 2015 2:06 pm    Post subject: Reply with quote

Another story that I plan to analyze some time in the future:

http://www.CroatiaFidelis.hr/foss/cap/cap-150512_T-com/

There you have two e-mail messages that I just couldn't send today, in all the numerous tries both of them just would not be sent.

This one:

http://www.CroatiaFidelis.hr/foss/cap/cap-150512_T-com/miro.rovis-dng-request.eml

is a simple subscription.

And this one:

http://www.CroatiaFidelis.hr/foss/cap/cap-150512_T-com/miroslav.rovis1-dng-message.eml

should have appeared hours ago, and I don't see it even now (2015-05-12 15:46+02:00).

Along the way there'll be a lot of learning for me and for hopefully some newbies.

If anybody from Devuan (both those are Devuan Mailing Lists, the first is my subscription with miro.rovis@croatiafidelis.hr address, and the second is my message from my miroslav.rovis1@zg.ht.hr address), [if anybody from Devuan] are reading this, if you care for another possible contributor, pls. give the address of this post to, best, the Devuan ML:

Grsecurity/Pax installation on Debian GNU/Linux
http://forums.debian.net/viewtopic.php?f=16&t=108616&start=60#p577538

where lines like these concern the issue of Devuan:

about Devuan/Debian wrote:

If Devuan takes off and learns to fly, and if they, this is important, and I'll point them over to these words of mine...

And if they offer a no-dbus Devuan, which I am not certain it is among their objectives; but if they do, then you may even not see much of me, because then I may get my little free time that I have, I can then start using that time for Devuan only...
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Thu May 14, 2015 3:53 pm    Post subject: Reply with quote

miroR wrote:
Another story that I plan to analyze some time in the future:

http://www.CroatiaFidelis.hr/foss/cap/cap-150512_T-com/

New stuff on that address above.

miroR wrote:
[...]
And this one:

http://www.CroatiaFidelis.hr/foss/cap/cap-150512_T-com/miroslav.rovis1-dng-message.eml

should have appeared hours ago, and I don't see it even now (2015-05-12 15:46+02:00).

Because that message in the meantime shows exactly as many times (four (4)), as I sent it.

Oh, so, I was wrong?! My joyous dear provider sent all the messages! Right?

Because if you look up:

Systemd discussions at LinuxQuestions.
https://lists.dyne.org/lurker/message/20150510.211708.6d1d46ab.en.html

you can see all the four replies of mine there. Why on Earth did I ever bother sending four times, when they duly did their work as they were supposed?

Well how about this, then, you freaking... (...aargh, I have to keep calm and polite), how about this then:

http://www.CroatiaFidelis.hr/foss/cap/cap-150512_T-com/Screen_150512_1445_g0n.mkv

and

http://www.CroatiaFidelis.hr/foss/cap/cap-150512_T-com/dump_150512_1445_g0n.pcap

How come I try and refresh that page (again, see in the screencast and in the capture dump):

https://lists.dyne.org/lurker/message/20150510.211708.6d1d46ab.en.html

and refresh the thread with that message, but no messages whatsoever appear? And I try exactly when I said two days ago, that I couldn't see my message appear there:

miroR wrote:
[...]should have appeared hours ago, and I don't see it even now (2015-05-12 15:46+02:00).


Easy, isn't it, you kind and loving T-com very clever playful admins, it was very easy wind up someone like me. Just keep the old cached page for my IP-address for more than four (4) hours, almost five (5) hours! How easy! That's what providers are about: for fooling their users, right!

I'll try and check with the brothers at Devuan, and see if they can find any errors with the lurker that they publish the messages with, just in case, but if I find time... No, that is so unlikely, and is another expenditure of time... Low priority.

This case is already useful for people looking how to deal unharmed with "clever" providers, I hope.
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon Sep 21, 2015 11:01 pm    Post subject: Reply with quote

miroR wrote:
PART 2
======
The Backup/Cloning Method in Poor User's Security

...

This is how I basically clone my systems.
...

Code:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           15000   6.3 MiB     EF02  BIOS boot partition
   2           16384         1100000   529.1 MiB   8300  Linux filesystem
   3         1101824       150000000   71.0 GiB    8300  Linux filesystem
   4       150001664      3750000639   1.7 TiB     8300  Linux filesystem
   5      3750000640      3907029134   74.9 GiB    0700  Microsoft basic data

...
The /boot is:
Code:

   2           16384         1100000   529.1 MiB   8300  Linux filesystem


and the / (root, the partition, not /root the home of the root user) is:
Code:

   3         1101824       150000000   71.0 GiB    8300  Linux filesystem


...

[ I have lots of files starting with dates, and to cut shorter their names, I
decided to use A-K instead of 10 10-19, so E is 14, in all the files in this
text named E09... and similar ]

[ The n4m3 is the hostname part of the name. ]

Code:

# dd if=/dev/sda2 of=E0904_sda2_n4m3.dd
...
# dd if=/dev/sda3 of=E0904_sda3_n4m3.dd
...
#


In my case I got:
Code:

# ls -l
-rw-r--r-- 1 root root   558709056 2014-09-05 00:15 E0904_n4m3_sda2.dd
-rw-r--r-- 1 root root 76767246848 2014-09-05 00:31 E0904_n4m3_sda3.dd
# ls -lh
-rw-r--r-- 1 root root 523M 2014-09-05 00:15 E0904_n4m3_sda2.dd
-rw-r--r-- 1 root root  75G 2014-09-05 00:31 E0904_n4m3_sda3.dd
#


The sizes are not exactly my numbers, but the method is.

Just for this article to contain complete info on cloning, these dumps (only
two) suffice for me to clone the system onto another same size/model HDD on
same model MBO computer. After, in case of an empty, for being zeroed out, or
for being new, HDD, having created the exact sam gpt partitions on it, as
previously shown, I just run:

Code:

# dd if=E0904_sda2_n4m3.dd of=/dev/sda2
# dd if=E0904_sda3_n4m3.dd of=/dev/sda3


...

On the other hand, what is necessary to do, if one wants to identify a
particular something of any kind of electronic document, and that huge 70G
file is one single electronic entity too... What is necessary to do, is
identify these partitions by calculating their checksum.

And I did so.

Code:

$ cat /mnt/sde1/dd_Add_3/dd_E0904_n4m3.sum
eb7a44755984b38c13e37dfb33cf3e647223ddb8cbbe3dc62e422297277a6028  E0904_n4m3_sda2.dd
fab838ed26e8f42fa995b5b1b7f92cef5e26fd811999f9c1f8c95ea092e720ba  E0904_n4m3_sda3.dd
$


Code:

$ cat /mnt/sdf1/dd_Add_3/dd_E0904_n4m3.sum
eb7a44755984b38c13e37dfb33cf3e647223ddb8cbbe3dc62e422297277a6028  E0904_n4m3_sda2.dd
fab838ed26e8f42fa995b5b1b7f92cef5e26fd811999f9c1f8c95ea092e720ba  E0904_n4m3_sda3.dd
$


That is those two partitions, very real ones, are the sole ones in extremely great likelihood in the whole of the universe to have those hashes. Any mathematician will tell you that. Well, the universe, Eistein is reported to have said, was not sure was infinite, but the chances are so unimaginably slim anything else in the, say world, has sensically those numbers in any case.
...

I have, after months and months of using this method, only recently figured out onw thing. It's so marvelous to me, how you can copy these huge abount of bits, adn that every single bit be in its proper place... but...

But I never thought you can check the SHA256 (or any other hashes for that matter), on the device itself.

So once you have done your equivalent of the above (repasting it):

Code:

# dd if=E0904_sda2_n4m3.dd of=/dev/sda2
# dd if=E0904_sda3_n4m3.dd of=/dev/sda3


what you can do and be near absolutely certain that you cloned/restored your system faultlessly, after you do:

Code:

sha256sum /dev/sda[23] > dd_E0904_n4m3_sda.sum

Surely, if these latter sums match the one taken when you dumped them.

And another note. I now use MD5SUMS, not SHA256SUMS, because Sleuthkit (see http://www.sleuthkit.org and the Sleuthkit Forums) uses those. It's faster, and even NSA would have it too expensive with their quantum PC's to forge even MD5 sums.

Regards!
Back to top
View user's profile Send private message
dalu
Guru
Guru


Joined: 20 Jan 2003
Posts: 529

PostPosted: Sat Sep 26, 2015 2:48 pm    Post subject: Reply with quote

You're cloning your actual partitions?
Why aren't you just using RAID1?
Backups are important, I know, but 70GB of cloned partitions?

And I don't get what you're rambling on about, what has 1 post got to do with the other?
Back to top
View user's profile Send private message
miroR
l33t
l33t


Joined: 05 Mar 2008
Posts: 826

PostPosted: Mon Mar 21, 2016 12:03 pm    Post subject: Reply with quote

I'm really sorry, but I don't have time to reply to someone claiming how raid is used for backup of a system (if that post is still the last before this one, and with that same content by the time you, gentle reader, visit here)... If anybody cares, just do "man raid" and read a little first. Including the poster.
--
Is that not a good thing for Gentoo, being this topic on top if one searches for
Code:

postfix censorship

(just those two words entered into the form) on: https://duckduckgo.com
and gets a web location on Gentoo Forums at the top of all the finds? Because those two words' search on "ddg.gg" gets you to this topic of mine of Gentoo Forums, first thing found.

(I couldn't care for the Schmoog --the Google-- they're a dirty intrusion into FOSS --in their real interior--, as they have cooperated, and likely do cooperate, far too much with the NSA. Don't ever google, always duck for the information!)

---

Update no. 1:
=================
This is the first update to do, regarding this post of the topic you are reading:

( about "Schmoog and Yooch in (What?) Action" )
https://forums.gentoo.org/viewtopic-t-999436.html#7685200

But I was checking on the addresses of links to give in my new post of today:

A Firewalled Internet Access to Internal Subnet
https://forums.gentoo.org/viewtopic-t-1041028.html

and saw that I needed to update this topic too.

With this information (not recent, but I only now remembered to update this topic about it):

SSL Decode & My Hard-Earned Advice for SPDY/HTTP2 in Firefox
https://forums.gentoo.org/viewtopic-t-1029408.html

So I have finally learned to decrypt SSL! And almost all that happens when I go online with my machine, with my Firefox, I can now decrypt!

---

Update no. 2:
=================
And there is another update to do, regarding this post of the topic you are reading:

( about the need to configure [iptables] with conntrack module )
https://forums.gentoo.org/viewtopic-t-999436.html#7642770

That I need to update:

the article on the iptables that I thought was obsolete, is not obsolete:

Configuring iptables firewall on Gentoo
http://gentoovps.net/configuring-iptables-firewall/

You can see my script, and maybe tell the holes you see in it, if any there are (no, I'm not daring you, there could be some, I'm still struggling to gain really good understanding in these matters...):

A Firewalled Internet Access to Internal Subnet
(the ADDENDUM post, second from start)
https://forums.gentoo.org/viewtopic-t-1041028.html#7895454

I thought and wrote that those rules were obsolete, but looking deeper into:
Code:

$ man iptables-extensions

, they are just fine, because "-m state --state [...]" I think translates into "-m conntrack --ctstate [...]". Somebody correct me if I'm wrong.

---

And I see a really useless post below. But I'll reply to it. Who knows when?!...

I work, and really hard, on the issues that I presented in the new topic linked in this post further above.

Will give you the link to the reply, in this topic when I do reply.

A link only here. Because it would be more of a disruption to reply here, on top of the disruption of that completely useless, and solely disrupting, post.


Last edited by miroR on Mon Mar 21, 2016 3:58 pm; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Mon Mar 21, 2016 1:24 pm    Post subject: Reply with quote

Quote:
Is that not a good thing for Gentoo, being this topic on top if one searches for postfix censorship

No one in their right mind would search for such a phrase on an American-owned clearnet search engine, and it's terrible that the paranoiacs who do so are now being directed to further disrupt this Linux tech support forum.

Or maybe this was part of your COINTELPRO-esque attack plan against this site all along?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum