Na przyszłość -- jeśli instalujesz moduły kernela, to je załaduj pierw i sprawdź czy działa, zwykle się ładują przy starcie same. big_smile

Coś mi nie idzie z tym szyfrowaniem za bardzo. big_smile

Na debianie zrobiłem wszystko jak trzeba, doinstalowałem pakiet rsyslog-gnutls i dodałem poniższe linijki do tych co były w pliku /etc/rsyslog.conf :

#################
#### MODULES ####
#################

# make gtls driver the default
$DefaultNetstreamDriver gtls

# certificate files
$DefaultNetstreamDriverCAFile /etc/CA/keys/ca.crt
$DefaultNetstreamDriverCertFile /etc/CA/keys/192.168.1.150.crt
$DefaultNetstreamDriverKeyFile /etc/CA/keys/192.168.1.150.key

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerStreamDriverMode 0             # run driver in TLS-only mode
$InputTCPServerStreamDriverAuthMode anon    # client is NOT authenticated
$InputTCPServerRun 514                        # start up listener at port 514

Na routerze pierw zainstalowałem rsyslog-ng3 i jego konfiguracja w pliku /etc/syslog-ng.conf wygląda jak poniżej:

@version:3.0

options {
    chain_hostnames(off);
    flush_lines(0);
    keep_hostname(yes);
    log_fifo_size(256);
    log_msg_size(1024);
    stats_freq(0);
    use_fqdn(no);

    time_reopen (300);
    long_hostnames(on);
#    use_dns (no);
#    create_dirs (no);
#    perm(0640);
#    group("log");
#    ts_format(iso);      #make ISO-8601 timestamps
};


source s_src {
    internal();
    unix-stream("/dev/log");
};

source s_localhost {
    tcp(ip(127.0.0.1) port(514));
    udp(ip(127.0.0.1) port(514));
};

source s_kernel {
    file("/proc/kmsg" program_override("kernel"));
};

destination d_messages {
    file("/var/log/messages");
};


destination d_network {
#    tcp( "192.168.1.150" port(514) );
    tcp( "192.168.1.150" port(514)
    tls( ca_dir("/etc/syslog-ng.cert")) );
};


log {
    source(s_src);
    source(s_localhost);
    source(s_kernel);
    destination(d_messages);
    destination(d_network);
};

W sumie nie wszystkie opcje jeszcze obadałem ale jeśli  w "destination d_network" zahaszuję te dwie linijki i odhaszuję tę co jest zakomentowana,  wtedy przesyłanie logów działa. Natomiast jeśli odpalę sysloga na takich ustawieniach jak powyżej, to co prawda komunikacja działa, logi są przesyłane ale wygląda to tak:

Oct  9 10:03:18 red_viper.mhouse.lh #026#003#001#001!#001#000#001#035#003#003»Ikløe`(õ#004©EMW$§¨013þL#023Ļ#000#000À0À,À(À$À#024À 
Oct  9 10:03:18 red_viper.mhouse.lh #000£#000#000k#000j#0009#0008À2À.À*À&À#017À#005#000#000=#0005À/À+À'À#À#023À#011#000¢#000#000g#000@#0003#0002#000#000À1À-À)À%À#016À#004#000#000<#000/#000À#021À#007À#014À#002#000#005#000#004À#022À#010#000#026#000#023À#015À#003 
Oct  9 10:03:18 red_viper.mhouse.lh #000#025#000#022#000#011#000#024#000#021#000#010#000#006#000#003#000ÿ#002#001#000#000m#000#013#000#004#003#000#001#002 
Oct  9 10:03:18 red_viper.mhouse.lh #0004#0002#000#016#000#015#000#031#000#013#000#014#000#030#000#011 

Certyfikaty były generowane przy pomocy easy-rsa na debianie -- wszystkie są bez haseł. Z tego co wyczytałem to jeśli chodzi o konfigurację syslog-ng to trzeba przesłać na klienta (w tym wypadku router) certyfikat CA i podlinkować go do nazwy jego hasha. Tak zrobiłem:

# ls -al /etc/syslog-ng.cert/
drwxr-xr-x    2 root     root          4096 Oct  9 03:53 .
drwxr-xr-x    1 root     root          4096 Oct  9 03:53 ..
-rw-r--r--    1 root     root          2447 Oct  9 03:52 ca.crt
lrwxrwxrwx    1 root     root             8 Oct  9 03:53 ef2fca17.0 -> ./ca.crt

Sam hash został wygenerowany zgodnie z instrukcjami na http://www.balabit.com/sites/default/fi … lient.html

I w sumie nie wiem czy to szyfrowania działa czy nie, czy tylko debianowy rsyslog nie potrafi tego odszyfrować. big_smile

Próbowałem też wywalić syslog-ng3 i zainstalować na jego miejsce syslog-ng ale ten chyba nie obsługuje szyfrowania, bo nie chciał przyjąć w configu wpisu od:

tls( ca_dir("/etc/syslog-ng.cert")) );

Jakiś pomysł?

A te wersje co są w repo, konkretnie syslog-ng3 i syslog-ng , to one się czymś szczególnym różnią między sobą?

Ostatnio przeczytałem coś o przesyłaniu logów z routera do pc via syslog, a że mam u siebie terminal osadzony na pulpicie co mi wyświetla logi systemowe, to pomyślałem, nie będąc przy tym pewien czy to możliwe, by może również logi z routera tam umieścić. Jak nie patrzeć skoro mam logi na pulpicie, to miałbym podgląd zdarzeń, zarówno systemowych jak i tego co się dzieje na routerze.

Na wiki openwrt piszą, że poniższe wpisy trzeba dodać do pliku /etc/config/system :

config system
      ...
        option log_type 'file'
        option log_file '/var/log/messages'
        option log_size '64'
        option log_ip   '192.168.1.150'
        option log_port '514'
#       option log_prefix 'router '
...

U siebie na debianie, w konfiguracji sysloga ustawiłem póki co:

...
# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514
...

Po resecie rsysloga i routera, logi z obu systemów lecą na terminal zgodnie z oczekiwaniem:

http://i.imgur.com/De159fX.png

Problem w tym, że przesył tych logów przez sieć nie jest w żaden sposób zabezpieczony:

http://i.imgur.com/xCxBjpu.png

Z tego co znalazłem na sieci, możliwe jest utworzenie kanału TLS i zaszyfrowanie logów, pytanie zatem, czy ten wbudowany syslog w openwrt to zadanie potrafi zrealizować?

Tam na wiki jest podane, że można sprecyzować tylko port, który w tym przypadku jest domyślny -- 514. Wszelkie zapytania lecą po udp i nie mam pojęcia zbytnio jak przy pomocy tego configu zmienić protokół na tcp -- to w ogóle wykonalne jest?

330

(5 odpowiedzi, napisanych Oprogramowanie / Software)

Rzuć okiem na ten artykuł: http://linux-ip.net/html/adv-multi-internet.html

331

(7 odpowiedzi, napisanych Oprogramowanie / Software)

A te opcje w dnsmasq nie załatwia sprawy?

config dnsmasq
...                      
        option local '/mhouse.lh/'
        option domain 'mhouse.lh'
...

Na hoście co pobrał lease dhcp:

# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.1
search mhouse.lh

To o ten seach chodzi?

Nie mam pojęcia, tak czy siak jest ograniczenie transferu więc co operatorowi za różnica na jakim urządzeniu zostanie to wykorzystane?

No z objaw wynika, że nie chcą byś udostępniał net i pewnie zarabiał na tym, w końcu jak sam powiedziałeś tam nie wszędzie mają, a jak podepniesz router co umożliwia jednoczesne podpięcie szeregu urządzeń, wtedy mógłbyś dorabiać na boku. big_smile

Swoją drogą to dziwnie tam na zachodzie myślą, przecie ta blokada którą zastosowali jest nieskuteczna od xx lat, oni nie wiedzą o tym? big_smile

Trochę się pogubiłem. To jak ten internet tam działa skoro sygnał nie dochodzi do kompa za modemem? big_smile Ale w sumie mniejsza z tym. Jeśli blokują standardowe ttl dla systemów, ten 64 dla linuxa i 128 dla wina, to przestawiasz lekko w górę albo w dół, bo na dobrą sprawę to przy traceroute nie masz więcej hopów niż 30, a i tak rzadko się notuje coś więcej niż 15, dlatego coś koło 60 w zupełności wystarczy. I tyle. Na winie/linuxie już nic nie musisz przestawiać, bo pakiety z routera będą mieć ustawiony ttl 60 i po przejściu przez niego, na kompach będą miały 59.

flankerr -- u mnie to działa (i zawsze działało) bez problemu. Porównaj sobie wyniki:

root@red_viper:~# opkg files iptables-mod-ipopt
Package iptables-mod-ipopt (1.4.21-1) is installed on root and has the following files:
/usr/lib/iptables/libxt_dscp.so
/usr/lib/iptables/libxt_length.so
/usr/lib/iptables/libipt_TTL.so
/usr/lib/iptables/libxt_statistic.so
/usr/lib/iptables/libipt_ttl.so
/usr/lib/iptables/libxt_CLASSIFY.so
/usr/lib/iptables/libxt_ecn.so
/usr/lib/iptables/libxt_TOS.so
/usr/lib/iptables/libip6t_HL.so
/usr/lib/iptables/libxt_tos.so
/usr/lib/iptables/libxt_DSCP.so
/usr/lib/iptables/libip6t_hl.so
/usr/lib/iptables/libipt_ECN.so
/usr/lib/iptables/libxt_tcpmss.so
root@red_viper:~# opkg files kmod-ipt-ipopt
Package kmod-ipt-ipopt (3.10.49-1) is installed on root and has the following files:
/lib/modules/3.10.49/xt_CLASSIFY.ko
/lib/modules/3.10.49/xt_HL.ko
/lib/modules/3.10.49/xt_hl.ko
/lib/modules/3.10.49/xt_DSCP.ko
/lib/modules/3.10.49/ipt_ECN.ko
/lib/modules/3.10.49/xt_ecn.ko
/lib/modules/3.10.49/xt_statistic.ko
/lib/modules/3.10.49/xt_dscp.ko
/lib/modules/3.10.49/xt_tcpmss.ko
/etc/modules.d/ipt-ipopt
/lib/modules/3.10.49/xt_length.ko

Hm, ustawienie 64 nic nie zmieni bo tak jest domyślnie i nie działa internet. Ustawienie 65 rozwiązuje sprawę, dlaczego?

A jak ustawisz 63, albo 50? A masz tam może płytkę z ubuntu-live ? Sprawdziłbyś w ten sposób czy po zabootowaniu systemu z tej płytki i podłączeniu maszyny bezpośrednio będzie na niej internet. Może ten isp blokuje TTL 64?

Podbiłem wchodzące, wychodzące i przechodzące na 250

A jakbyś to ustawił na 64 zamiast 250? Poza tym, przestawianie wychodzących i forwardujących pakietów nie ma sensu, bo to zależne jest od systemu operacyjnego, np. linuxy ustawiają domyślnie 64 i przestawienie tego w iptables tylko obciąża router bez większego sensu. A te przychodzące pakiety zanim zostaną zforwardowane, pierw trafiają do routera z określonym ttl. Tu masz obrazek jak pakiety przechodzą w iptables:

http://i.imgur.com/hgzULrm.png

I jak widać, pakiety pierw lecą przez łańcuch PREROUTING tablicy mangle, a dopiero potem są forwardowane.

Przy okazji żeby nie zakładać nowego tematu takie pytanie bo jeszcze się nie orientowałem w temacie, czy da sie na Gargoylu ustawić dostęp tylko do stron internetowych ? Tz. tylko protokój http (i https) albo tylko port 80. Albo inny patent żeby odciąć laptopowi wszelkie aktualizacje systemu, antywirusa, adobe reader itp. co praktycznie dzieje się bez mojej wiedzy a pożera jakże drogi internet.

Tam na windowsie to chyba masz opcje by powyłączać aktualizacje tych programów.

Ten ttl=1 to jeśli jest u ISP, to na routerze będzie wtedy ttl=0?

W każdym razie, prosty test ttl na routerze -- wbijamy na router po ssh i sprawdzamy ping:

root@red_viper:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=44 time=75.452 ms
64 bytes from 8.8.8.8: seq=1 ttl=44 time=75.559 ms
64 bytes from 8.8.8.8: seq=2 ttl=44 time=74.170 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 74.170/75.060/75.559 ms

TTL wynosi 44 dla powracających pakietów.

Dodajmy poniższą linijkę do filtra:

root@red_viper:~# iptables -t mangle -I PREROUTING 1 -i eth0 -j TTL --ttl-inc 1

I jeszcze raz ping:

root@red_viper:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=45 time=115.775 ms
64 bytes from 8.8.8.8: seq=1 ttl=45 time=110.958 ms
64 bytes from 8.8.8.8: seq=2 ttl=45 time=69.258 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 69.258/98.663/115.775 ms

TTL zmienił się z 44 na 45. Czyli się podbił o 1 i może przejść o jedną maszynę dalej.

Art zaktualizowany. Przy czym taka jeszcze jedna uwaga -- dnscrypt dość ostro sypie logami i przydałoby się to zachowanie nieco ograniczyć. Istnieje parametr --loglevel=5 , który można dodać do skryptu startowego i to syfienie w dmesg czy logread zostanie wyeliminowane.

Czyli na roocie to zawsze będzie z /etc/dropbear/authorized_keys ?

U mnie jako tako sam extroot nie rozwalił się nigdy ale jedna partycja już poleciała dwa razy przy wyłączaniu via przycisk. A na tej partycji to mam tam tylko collectd. Także ewidentnie za jego sprawą można sobie popsuć system plików. Jak go trochę bardziej ogarnę to sobie go zwyczajnie wrzucę do RAM i w cronie ustawie regułki by bazę kopiował na pena co godzinę i to powinno załatwić sprawę, przynajmniej jeśli chodzi o ten cały collectd.

# co do pasywnego huba... to po prostu taki miałem i chciałem sprawdzić czy działa i czy uciągnie 2 pendrive... o dziwo uciągnął

A czemu ma nie uciągnąć? Z tego co pamiętam, to usb2 dostarcza 2,5W, a sam pendrive ciągnie koło 0,5W, także nawet i 4 powinno uciągnąć. Ja mam u siebie na jednym hubie wpiętą kartę wifi, pena, klawiaturę i myszę, i działa bez problemu, nawet nie muszę mu dołączać zasilacza.

Cezary napisał/a:

- autoryzacja kluczami w dropbear

Z okazji aktualizacji pakietu dropbear w BB zmieniło się miejsce przechowywania pliku authorized_keys. Obecnie jest to zgodne z openssh czyli odciski trzymamy w pliku

/root/.ssh/authorized_keys

U mnie coś to nie działa. Mam wersję:

Dropbear server v2014.63 https://matt.ucc.asn.au/dropbear/dropbear.html

A tutaj test:

morfik:~$ ssh-copy-id -i .ssh/id_rsa.pub 192.168.1.1
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.1.1's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '192.168.1.1'"
and check to make sure that only the key(s) you wanted were added.

Niby dodał klucz ale przy logowaniu dalej chce hasło:

morfik:~$ ssh root@192.168.1.1
root@192.168.1.1's password:

Wszystko jest utworzone jak trzeba:

root@red_viper:~# ls -al
drwxr-xr-x    1 root     root          4096 Oct  2 20:54 .
drwxr-xr-x    1 root     root          4096 Sep 27 12:10 ..
drwx------    2 root     root          4096 Oct  2 20:54 .ssh

root@red_viper:~# ls -al .ssh/
drwx------    2 root     root          4096 Oct  2 20:54 .
drwxr-xr-x    1 root     root          4096 Oct  2 20:54 ..
-rw-------    1 root     root           744 Oct  2 20:54 authorized_keys

root@red_viper:~# cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDKeoWq5utSJHCdoX+4Snsd7nm2n+Q8TzqRrB1PkgbKUMhW34T48UH20mTmYf4GsLv3Pjd/emL8Ba19DQbB9zlWbDJaobMRJTH8FxrYgxI5YQT1ZnRrqp+uHrkOhmBVHRmOiCdSg0f4IqyjUs9Cfqph1nLU0yCPNPk5lizQKfK8glBQNCRkHPswVfu3ZMrj+Fxcjee9mbdjBsMw1Z9kyGFYfHWQ0L4aL+sMcWt0k/0IE0H4G7BZF824D70BxjB9AirmXGIAz+w+OZiaXCjjhxWIqFIma8vAJxfz97aIbxTMzXwp6JVU2WZkha6WGD20QYGCnp3CqPTepOLbj9hV4pbwnoOEQQHxL7zj108Qu45vzYwzDplZ1alUZlFBkfJTquyMEgVXdru7ovY2WqqHU1LmBv+SkK+vyCO7Xp5jE/U3ayg2hdOYsK5b72qyioLvW3e7ZO4Qo2xQF0TGa3sk0MU2XkkW+f3vOLkNW5ENRDvqO3uUIlwAkj+5sQWP5BcLJhsv8Vr0eEksOXOuGefQ+Nu9qWdgwkEDYzN3pTlFQgu8+qxghXXho332RJ8rDMQtejhBA/Ox4D05lQW9iOWLcqmwy557CCddQiSU5oPLAMyz0pidppWbB43uySivQZrAYTGvEgVdWAyNVT2l6u9oN35uLQRrM2Hd1aFj6aF8X/Czmw== morfik@morfikownia

Jeśli przekopiuję ten plik do katalogu /etc/dropbear/ , to wtedy działa:

root@red_viper:~# cp .ssh/authorized_keys /etc/dropbear/
root@red_viper:~# exit
Connection to 192.168.1.1 closed.
morfik:~$ ssh root@192.168.1.1

BusyBox v1.22.1 (2014-09-01 19:00:03 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
...

Jakieś dodatkowe czynności są potrzebne by to działało w oparciu o ~/.ssh/authorized_keys ?

Your SamKnows device is on its way!

Your SamKnows device has now been dispatched from our warehouse today and
should be with you soon. With deliveries outside the United Kingdom this
can take a couple of weeks to be received.

U mnie trochę szybciej wysłali. Mam nadzieję, że nie będzie to szło paru tygodni. big_smile

Unikać wyłączania routera, albo jak już, to robić to przez zalogowanie się na router i wydanie polecenia "poweroff". Wtedy system się położy, po chwili pendrive przestanie migać lampkami i można router wtedy wyłączyć przyciskiem bez żadnego uszkadzania plików na pendraku.

A ten topic to nie był wołaniem o pomoc? big_smile

Nawet jest w pierwszym akapicie pierwszego postu:

Standardowo w repo openwrt jak i dl.eko.one.pl nie ma pakietu dnscrypt-proxy ale można go zdobyć z http://exopenwrt.and.in.net/ar71xx .

Tyle, że jakbym znowu miauczał o pakiet -- to bym pewnie usłyszał odpowiedź, sam se skompiluj. big_smile

W sumie fakt, zmieniło repo, zaraz to poprawie, a jak wrzucą do repo dl.eko.one.pl  , to poniżej też zmienię.

345

(7 odpowiedzi, napisanych Oprogramowanie / Software)

Te bardziej użyteczniejsze funkcje sobie implementuje. W tym przypadku, klucze oparte o krzywe eliptyczne są chyba jak najbardziej pożądaną rzeczą jeśli chodzi o ssh i bezpieczeństwo z tą usługą związane, przecie to jest następny poziom w kryptografii. Dlatego trochę dziwi mnie fakt, że tych metod się nie implementuje i zapytuję o przyczynę. Przecie jak widać na przykładzie tabelki -- używając krótszych kluczy, mamy zapewnione lepszą siłę samego klucza. I klucz 521bitów oparty o te krzywe eliptyczne, rozkłada klucz rsa który ma prawie 16k bitów, a na dobrą sprawę, u mnie na debianie mogę wygenerować standardowo najwyżej 8192 bitowy rsa, a i tak z jego obsługą są problemy. Podczas gdy 521bitowy klucz ecc działa bez większego problemu.

346

(7 odpowiedzi, napisanych Oprogramowanie / Software)

Chyba z mnóstwa innych rzeczy też nie korzystasz, a opcje są. big_smile

347

(7 odpowiedzi, napisanych Oprogramowanie / Software)

A czemu nie? Taki klucz ECC 521 bitów ma siłę klucza RSA 15360 big_smile

Symmetric  |  ECC2N  |  ECP  |  DH/DSA/RSA
       80  |   163   |  192  |     1024
      128  |   283   |  256  |     3072
      192  |   409   |  384  |     7680
      256  |   571   |  521  |    15360

348

(7 odpowiedzi, napisanych Oprogramowanie / Software)

Czy ten dropbear potrafi obsługiwać typ kluczy ecdsa lub też ewentualnie Ed25519 ? Przetestowałem póki co trzy typy -- te dwa powyższe oraz rsa i po dodaniu ich do /etc/dropbear/authorized_keys , idzie się zalogować tylko przy pomocy klucza rsa (testowane były każdy z osobna).

Jeśli chciałbym te klucze ecc, to nie ma innego wyjścia jak zainstalować na routerze openssh?

A tu do poczytania, jakby ktoś chciał sobie operować na iptables:

http://www.iptables.info/en/iptables-ma … ECENTMATCH
http://www.iptables.info/en/iptables-ma … LIMITMATCH
http://www.iptables.info/en/iptables-ma … LIMITMATCH

+ info na http://ipset.netfilter.org/iptables-extensions.man.html odnośnie connbytes, connlimit i hashlimit

Jeśli to jest na tej samej zasadzie co advanced format w dyskach hdd, to startowy sektor musi być podzielny przez te 128 + wielkość (w sektorach) każdej partycji musi być podzielna przez 128. Kolejne partycje są tworzone zaraz za końcem poprzedniej i nie trzeba tam nic już zmieniać -- liczy się tylko ułożenie tej pierwszej. Z tym, że jeśli masz więcej partycji na penie, np. 5 i masz tam tablicę partycji ms-dos, to trzeba tworzyć partycję rozszerzoną i ją też trzeba wyrównać + równanie każdej partycji logicznej. Przynajmniej takie są zasady w advanced format o ile dobrze pamiętam.

U mnie gparted pod linuxem automatycznie równa do 1MiB (advanced format) i to jest 2048 sektorów -- to się dzieli przez 128. Więc wyrównanie jest w porządku. Choć ja tam nie rozumiem tej magii z "The best way to do this is to use 224 (32*7) heads and 56 (8*7) sectors/track. This produces 12544 (256*49) sectors/cylinder, so every cylinder is 49*128k." ale z tego co się orientuję, to już nikt nie operuje na CHS (cylinder head sector) tylko na LBA . Zresztą jeśli zobaczyć na datę tamtego wpisu, to tam jest 2009, a w informatyce 5 lat to wieczność. big_smile

Poza tym, tam jest jeszcze tworzenie systemu plików z opcją

                   stripe_width=stripe-width
                          Configure  the  filesystem  for  a  RAID  array with
                          stripe-width filesystem blocks per stripe.  This  is
                          typically  stride-size * N, where N is the number of
                          data-bearing disks in the  RAID  (e.g.  for  RAID  5
                          there is one parity disk, so N will be the number of
                          disks in the array minus 1).  This allows the  block
                          allocator to prevent read-modify-write of the parity
                          in a RAID stripe if possible when the data is  writ-
                          ten. 

Co ma wspólnego raid z pendrivem to zbytnio nie mam pojęcia. xD

Odrzucając to czego nie wiem i biorąc pod uwagę fakt, że mój pendrive nie wykazał żadnej poprawy, skłaniałbym się raczej do zdania, że narzędzia linuxowe mi poprawnie wyrównały partycje, a u was na windowsach peny są formatowane jakoś inaczej.