View previous topic :: View next topic |
Author |
Message |
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Fri Sep 05, 2014 7:22 pm Post subject: Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion |
|
|
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.
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Fri Sep 05, 2014 7:30 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Fri Sep 05, 2014 7:44 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Fri Sep 05, 2014 7:51 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Sep 07, 2014 10:21 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Sep 07, 2014 10:40 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Fri Oct 31, 2014 6:01 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Tue Jan 13, 2015 9:51 pm Post subject: |
|
|
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).
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Jan 18, 2015 1:37 am Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sat Jan 31, 2015 8:00 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sat Jan 31, 2015 11:15 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Mon Feb 02, 2015 9:40 pm Post subject: |
|
|
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.
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Thu Feb 05, 2015 1:00 am Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Sun Feb 08, 2015 1:19 am Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Thu Feb 19, 2015 5:15 am Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Mon Mar 30, 2015 3:59 am Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Fri Apr 17, 2015 1:16 am Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Tue May 12, 2015 2:06 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Thu May 14, 2015 3:53 pm Post subject: |
|
|
New stuff on that address above.
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Mon Sep 21, 2015 11:01 pm Post subject: |
|
|
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 |
|
|
dalu Guru
Joined: 20 Jan 2003 Posts: 530
|
Posted: Sat Sep 26, 2015 2:48 pm Post subject: |
|
|
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 |
|
|
miroR l33t
Joined: 05 Mar 2008 Posts: 826
|
Posted: Mon Mar 21, 2016 12:03 pm Post subject: |
|
|
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
(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 |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Mon Mar 21, 2016 1:24 pm Post subject: |
|
|
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 |
|
|
|
|
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
|
|