Portál AbcLinuxu, 30. dubna 2025 12:53
Prej nejpozděj od září 2011?
Půlka z nich není schopná použít iterátor.Přesně! Když jsem šel učebnou, tak jsem zíral, kolik lidí nedokáže připsat jednoduchou metodu do třídy nebo najít bug v krátkém kódu. Těm paradoxně předchozí vedení předmětu vyhovovalo, protože šlo především o nabiflování a vyblití na papír.
Pak se ke mě doneslo cosi prapodivnostech jako je vstupní test do předmětu a později něco o tom, že to snad učí Píše (magor v dobrym slova smyslu, měl jsem ho na cvika na nějaký C++, ale dokážu si představit, že jako přednášející hodně lidem nesed) a že je to hrůza.No magor to je, kdo na FELu taky není
pak se zeptá kdo tomu nerozumí a nepřihlásí se nikdo a potom si stěžují. Přitom když se někdo přihlásil, že tomu nerozumí tak mu to zopakoval.Tohle je ovšem příklad dost špatné pedagogické praxe. Moc bych to nevyzdvihoval.
S tím biflováním máš naprostou pravdu, spolužáci na mě kolikrát koukali jak na cvoka, když jsem chtěl vědět proč a jak něco funguje. Zkouška se dá udělat i bez toho, tak proč to řešit.Tohle je problém celého školství, ne jen VŠ. Jako jeden z mála se na gymnáziu neučím definice a většinu vzorečků, když to skoro všechno jde odvodit.
[c] = J/(kg×K)
Y36DSA, A7B36DSA – podněty studentů na zlepšení předmětu Obsah předmětu: - stále chybí souhrn (podpůrné materiály) látky v českém jazyce (slides z přednášek nejsou dostatečné) k dispozici je pouze kniha Algorithms and Data Structures. Někteří studenti nemají znalosti z odborné angličtiny na dostatečné úrovni, nemohou se tedy z knihy optimálně připravovat. - transkripty z přednášek nebyly dodány včas (objevily se až po Midterm testu) a stále nejsou kompletní. Navrhujeme přidat k transkriptům příklady, které se na přednášce probíraly - z předmětu nemáme pocit, že je dostatečně připravený. Obsah cvičení: - obsah domácích úkolů by měl upevnit znalosti probrané v daném cvičení, nezadávat řešení speciálních chování (případů) algoritmů apod. Navrhujeme zadat více jednodušších příkladů, které studentovi pomohou v přípravě na zápočtový test a ke zkoušce. - prosíme o přidání sady řešených příkladů a sady příkladů na procvičení každému cvičení (které zároveň budou sloužit pro konzultaci). - příklady v knize Algorithms and Data Structures nejsou vzhledem k požadavkům dostatečné. Zkouška, Midterm test: - žádáme o změnu hodnocení testů (True/False vzhledem k variantám testu není vhodné). - cvičící se nepodílejí na přípravě zkouškových ani zápočtových testů, obsahem zkoušky ani midtermu by tedy neměla být látka ze cvičení. - obtížnost zápočtového testu č. 1 a zápočtového testu č. 3 je velmi odlišná (JanaP.: obtížnost se zvyšovala). (úspěšnosti [prošlo/neprošlo] - 1. test: 100/208 (= 32% prošlo), 2. test: 101/67 (= 69% prošlo), 3. test: 3/42 (= 7% prošlo)zdroj). - průběh písemné zkoušky (240 minut minut písemné zkoušky, jen aby student dosáhl nejlépe na Czdroj) jen těžko odpovídá rozumným požadavkům na psychohygienu. I to mohlo být příčinou, proč druhou část zkoušky absolvovalo naprosté minimum studentů. Y36DSA: - osnova a vyučovaná látka by se neměla výrazně lišit jako při prvním zápisu předmětu. (JanaP.: ...od látky probírané při prvním zápisu předmětu)? Svým podpisem souhlasím s výše uvedeným:Přímo odkaz na ní dát nemůžu protože je to na google docs a může to upravovat každý.
Ta angličtina je trochu širší problém. Řešila se už před pěti lety, když jsem byl v prváku já. Otázka je, zda-li škola může mít nějaká očekávání ohledně jazykových znalostí studentů. Jedna strana tvrdí, že by studenti měli být na konci prváku schopni číst odborné texty. Druhá strana pak, že škola nemůže vyžadovat něco, co neučí. Tedy ne že by škola neučila Aj, ale že je třeba počítat se studenty, kteří mají Aj na VŠ poprvé v životě. K tomu tehdy byla poznámka, že jestli si FEL hraje na kvalitní školu, tak by si taková očekávání dovolit měl.
Midterm test je lehký. Vždyť jím prošlo 170 studentů z 208. ;) FEL bere skoro každého, tak je občas třeba někoho vyhodit. (No dobře je to trochu kruté, ale za nás se létalo na M1,M2,Lingebra,Fy1,EO1,EO2 tak nové obory by měly mít nějaké zabijácké předměty. A můžou být rádi, že z oboru.)
IMHO má smysl pouze ta připomínka k materiálům. Tam bych řek, že vám píše nějaké navíc dodá.
EO1EO1 není žádný zabijácký předmět, to je předmět, kde se sčítaly odpory. Totéž M1 - v praxi téměř nic jiného, než opakování látky ze střední. Kdo tohle nezvládl, neměl na FELu co dělat.
Někteří studenti nemají znalosti z odborné angličtiny na dostatečné úrovniTo si dělají prdel... studenti softwarových technologií, co neumí anglicky? A to ani nemluvím o tom, že když už píšu nějakou petici, tak by to mělo vypadat, jako kdyby to psal člověk. Tohle zní jako přímý přepis toho, co někdo smolil v hospodě u piva.
Až potom je možné uvažovat o tom, že notebook bude fungovat obchodníkovi na služební cestě stejně jako ve firmě.S IPv4 to tak samozřejmě může fungovat taky - VPN. Dokonce se to tak velmi často dělá včetně toho, že se ten notebook přes VPN připojuje i k internetu
Já měl původně dojem, že se mluví o CiscoVPN, které zařezává LAN provoz ... tedy že je to věc síťové politiky?
FORWARD
povolit nemuselo?
Slušně? Obvykle REJECTem?
-A INPUT -i eth0.0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j syn_flood
-A INPUT -i eth0.0 -p icmp -m icmp --icmp-type 0 -m limit --limit 4/sec --limit-burst 20 -j ACCEPT
-A INPUT -i eth0.0 -p icmp -m icmp --icmp-type 3 -m limit --limit 4/sec --limit-burst 20 -j ACCEPT
-A INPUT -i eth0.0 -p icmp -m icmp --icmp-type 8 -m limit --limit 4/sec --limit-burst 20 -j ACCEPT
-A INPUT -i eth0.0 -p icmp -m icmp --icmp-type 11 -m limit --limit 4/sec --limit-burst 20 -j ACCEPT
-A INPUT -i eth0.0 -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable
nat.PREROUTING
a 1 ve filter.FORWARD
) budete mít totiž jen jedno. Pokud byste povoloval přístup jen na vybrané stroje, pak byste měl místo původních 2n pravidel jen n.
Ja chci povolit 22 zvenku na 5 stroju, takze to mam 5 PREROUTING a 1 FORWARD.
To je ale špatně. Pokud chcete opravdu povolit přístup na port 22 jen na těch pět strojů a na zbytek ne, pak to jedním pravidlem ve filter.FORWARD
neuděláte.
-A PREROUTING -i eth0.0 -p tcp -m tcp --dport 3001 -j DNAT --to-destination 10.0.2.123:22
-A PREROUTING -i eth0.0 -p tcp -m tcp --dport 3002 -j DNAT --to-destination 10.0.2.124:22
-A PREROUTING -i eth0.0 -p tcp -m tcp --dport 3003 -j DNAT --to-destination 10.0.2.125:22
-A PREROUTING -i eth0.0 -p tcp -m tcp --dport 3004 -j DNAT --to-destination 10.0.2.126:22
-A PREROUTING -i eth0.0 -p tcp -m tcp --dport 3005 -j DNAT --to-destination 10.0.2.127:22
-A POSTROUTING -o eth0.0 -j MASQUERADE
-A FORWARD -d 10.0.2.100/24 -i eth0.0 -p tcp -m tcp --dport 22 -j ACCEPT
Co je na tom spatne? IMHO se na ty stroje 10.0.2.* z eth0.0 neda dostat jinak, nez ze to PREROUTINGuju a tim padem ten FORWARD povoli co ma a na zadny jiny stroj ve vnitrni siti se neda provolat. Nebo se mylim?
IMHO se na ty stroje 10.0.2.* z eth0.0 neda dostat jinak, nez ze to PREROUTINGuju
YHO is wrong.
10.0.2.100/24
Tohle vám projde? Za starých dobrých časů proti takovým věcem příkaz iptables
protestoval.
Tohle vám projde? Za starých dobrých časů proti takovým věcem příkaz iptables protestoval.Co je špatného na pravidle pro IP zapadající do rozsahu?
iptables
odmítal zápis rozsahu, kde adresa před lomítkem neměla příslušný počet (v tomto případě osm) nejnižších bitů nulových.
Udělal jsem s iptables 1.4.10 test ...
# iptables -I OUTPUT -d 10.2.3.4/27 -j ACCEPT # iptables -I OUTPUT -d 10.2.3.4/25 -j ACCEPT # iptables-save | grep 10.2.3 -A OUTPUT -d 10.2.3.0/25 -j ACCEPT -A OUTPUT -d 10.2.3.0/27 -j ACCEPTtakže ... jen u nastavení routy linux protestuje ...
# ip route add 10.2.3.10/27 via 192.168.1.22 RTNETLINK answers: Invalid argument(chce přesnou síť)
Jde o to, že pokud k vám přijde paket se správnou cílovou adresou některého z počítačů ve vnitřní síti, tak bez ohledu na NAT projde. Technický problém je jen jak k vám ten paket dostat, ale pokud je např. útočník váš bezprostřední soused (což obecně nemůžete vyloučit), je to zcela triviální.
Je dobré si zvyknout, že k rozhodování o tom, zda je paket "hodný" nebo "zlý", a tedy zda ho pustíme nebo zahodíme, slouží tabulka filter
. Snažit se její roli suplovat v tabulkách nat
nebo mangle
sice do určité míry lze, ale je lepší se do toho nepouštět, protože nebyly pro tento účel navrženy a moc se pro něj nehodí. Třeba na pakety se stavem ESTABLISHED
, kterých je typicky výrazná většina, se pravidla tabulky nat
neaplikují vůbec.
Je dobré si zvyknout, že k rozhodování o tom, zda je paket "hodný" nebo "zlý", a tedy zda ho pustíme nebo zahodíme, slouží tabulka filter. Snažit se její roli suplovat v tabulkách nat nebo mangle sice do určité míry lze, ale je lepší se do toho nepouštět, protože nebyly pro tento účel navrženy a moc se pro něj nehodí.Pod to bych se taky podepsal.
Mluvíte o routeru nebo firewallu?
filter
, ne nat
nebo mangle
.
Jj, já jen, že jsem se dost dlouho nesetkal se strojem, kterej by neměl filter zapnutej.
-A PREROUTING -i eth0.0 -p tcp -m tcp --dport 3001 -j DNAT --to-destination 10.0.2.123:22
....
-A POSTROUTING -o eth0.0 -j MASQUERADE
FORWARD krome obvykleho zahazovani nesmyslnych packetu (jako treba spatne source IP, windowsi protokoly a tak podobne) a povoleni v pokracovani navazanych spojeni povoluje 22 do jedne podsite zvenku
-A FORWARD -d 10.0.2.100/24 -i eth0.0 -p tcp -m tcp --dport 22 -j ACCEPT
a pak povoluje potrebne vnitrni zalezitosti podle potreby:
-A FORWARD -i br-lan2 -o br-lan1 -p tcp -m tcp --dport 22 -j ACCEPT
-A FORWARD -i br-lan1 -o br-lan3 -p tcp -m tcp --dport 2002 -j ACCEPT
.....
default pro INPUT,OUTPUT,FORWARD je pochopitelne DROP
default pro INPUT,OUTPUT,FORWARD je pochopitelneTo mi moc pochopitelné nepřijde
NAT je zvěrstvo.A to nekteri NAT pouzivaji jako firewall nebo anonymizacni system a chteji NAT i do IPv6!!! NAT v IPv4 pouzivam a nedela mi problem. Ale v IPv6 bych ho radsi taky nepouzival. Cetl jsemv Ipv6 prirucce od NIC.CZ, ze IPv6 ma nejakej vlastni system na vygenerovani anonymnich IPv6 adres - takhle az nekdo bude kecat, ze potrebuje NAT v IPv6, tak ho timhle argumentem muzete uzemnit.
No vidite, a co se teprve bude dit az budu domacim klientum vysvetlovat ze budou jejich pocitace viditelne z celeho internetu a zabezpeceni je jejich vec. To me asi zabijou.Zakázat na firewallu FORWARD směrem dovnitř a povolovat ho na požádání, no to je opravdu velký problém.
V uteri mi jeden "odbornik" rikal ze se mu to moc nelibi, ze by jeho firemni kompy meli byt takhle videt a ze zna nekolik lidi co k nam do site nechtej prave kvuli tomu, ze jsme strasne transparentniNo jestli do firmy přidělíte hromadu adres a všechny počítače jsou přímo viditelné v celé vaší síti, tak to se mu nelíbí naprosto oprávněně a mě by se to nelíbilo taky. Jo, jestli přidělujete subnet a ve firmě si naroutujte, jak chcete, to už je něco jiného... (ASCII zobrazení těch dvou variant: 1. - fuj
X-X-X-X-F-F-F-F-X-X-X-X2. - ok
X-X-X-X-FR-X-X-X-X | F-F-F-F-FX jsou ostatní, F je firemní počítač, FR firemní router)
Jestli by pak v takovejchhle sítích s natem a IPv4 nebylo lepší v případě IPv6 mít např. privátní AS?
No vidite, a co se teprve bude dit az budu domacim klientum vysvetlovat ze budou jejich pocitace viditelne z celeho internetu a zabezpeceni je jejich vec. To me asi zabijou.K tomuhle se odjakživa používá firewall, ne NAT. Zařízni jim pro Windows rizikové porty (135-139 a možná nějaké další) nebo dej do smlouvy škrtátko
[ ] blokovat příchozí spojení
. Problem fixed.
V uteri mi jeden "odbornik" rikal ze se mu to moc nelibi, ze by jeho firemni kompy meli byt takhle videt a ze zna nekolik lidi co k nam do site nechtej prave kvuli tomu, ze jsme strasne transparentni a IP rozhodne nepovazujeme za citlivy udaj.Si to může (nechat) uříznout v netfilteru na nejbližším linuxovém routeru, když se mu to nelíbí…
Bez NATu je bezpecnost zalezitosti kazdyho kompu.Nebo nejbližšího routeru, jehož admin to chce/může nastavit.
Vysvetlujte firemnimu sefovi, ze opravdu neni dobry napad nasdilet si celej disk i pro zapis vsem uzivatelum.Ale pokud by tam měl jenom NAT, pak by mu tam lidi minimálně z okolí stejně lézt mohli.
Nemohlo by to ohrozit primo stabilitu/funkci celeho systemu ?Jejich systému určitě ano
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.