Jöhet is az iptable cikk
Nagyon hasznos, max respect

Má' nem

Jó összefoglaló! Annyit tennék hozzá, hogy ssh-hoz érdemes lehet teljesen letiltani a jelszavas bejelentkezést, és csak certificate-eket engedélyezni.

jó kis cikk

amúgy az iptables-sel kapcsolatban van már egy cikk
sh4d0w írt már róla

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Az azert egy kicsit furcsa, hogy javaslod az ssh-s root login letiltasat meg a port elkoltozteteset, emellett viszont nem javaslod az ftp sftp-re csereleset, pedig az joval problemasabb: ugyanis az ftp eseten a komplett kommunikacio (beleertve a user/pass parost meg magukat a file-okat is) mindenfele titkositas nelkul vandorolnak a neten.

DRM is theft

"Megérne egy külön cikket, hogy pontosan hogyan is néz ki egy jól beállított tűzfal, mik is a nélkülözhetetlen szűrési feltételek."

Megérne ám! És nekem is lenne rá igényem

Teljesen jó kis leírás, és egy csomó minden volt benne, amit eddig nem tudtam, és valószínű, csak akkor esett volna le, amikor valaki már betámadott volna

Köszi!

@dabadab : Van valami olyasmi módszer is, hogy a root-ot tiltod le, mint usert, előtte pedig csinálsz egy bármilyen nevű felhasználót root jogokkal...

[ Szerkesztve ]

Mutogatni való hater díszpinty

Köszönöm, ez hasznos volt

Köszi. Hasznos kis olvasmány. (ismerkedőknek mindenféleképpen)

Jó kis betekintő írás.
Van kedved, időd folytathatod. Egyre gyakoribb a házi linux szerver projekt, érdemes arra koncentrálni.

Amire gondolok: tűzfal (iptables, mindenképpen legalább egy megnyugtató alap hozzá)
Fájlmegosztás minden mennyiségben: samba, nfs, ftp, esetleg sshfs.

Talán még letöltő progik is, elsősorban konzolos torrent. De abban én is be tudok segíteni. Egyszer talán, ha lesz időm.

Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!

Korrekt írás, köszönjük!!

Én is várom a következő írást és mellesleg szívesen olvasnék még akár olyat is, hogy egy komplett profi webszerver konfig. Esetleg redundáns webszerver, mailszerver konfig és egyéb hasonlók.

G

Grat a cikkhez! Szeretek ilyesmit olvasni.

"Légy olyan, mint bárki más, tégy olyat, mint senki más."

Megírnám de el-el száll a gépem, a tápom valamit nem szeret.
Kóstoló, nálam gyönyörűen működött, részben saját, részben Rusty írásai a netfilter.org-ról, az iptables szülőhazájából.

Angolul írtam a kommenteket is, mert én informatikában utálom a magyart.
Laptopról értelmessé is tehetem, amint odajutok hogy kommentelem is, mi ez itt..

Addig is enjoy, a teljesség igénye nélkül, tehát lehetne még mit bőven finomítani rajta.. egy régi script-em, de évekig húzta vele a debianom Van benne Apache, BIND, minden jóféle móka

#!/bin/bash
clear
# Define your interfaces here:
EXT="ppp0"
INT="eth0"

# Don't change these, these are not site specific:
LOOPBACK="127.0.0.0/8"
RESERVED_IP_172_SPACE="172.16.0.0/12"
RESERVED_IP_192_SPACE="192.168.0.0/16"
RESERVED_IP_10_SPACE="10.0.0.0/8"
RESERVED_IP_MULTICAST="224.0.0.0/4"
RESERVED_IP_FUTURE="240.0.0.0/5"

# Basic Opsys Protection
# Disable routing triangulation. Respont to queries out the same
# interface, not another. Helps to maintain state. Also protects
# against IP spoofing.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
# Enable logging of packets with malformed IP addresses
#echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
# Disable redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
# Disable source routed packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
# Disable acceptance of ICMP redirects
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
# Turn on protection from DoS attacks
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Disable responding to ping broadcasts
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Basic iptables Initialization
# Load modules for ftp connection tracking and NAT
modprobe ip_conntrack_ftp
modprobe iptable_nat
# Initialize all the chains by removing all the rules tied to them
iptables -F
iptables -t nat -F
iptables -t mangle -F
# Delete user defined chains
iptables -X valid-tcp-flags
iptables -X LOGDROP
iptables -X valid-source-address
iptables -X valid-destination-address
# Loopback interface ACCEPTs everything
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# BLOCK
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Advanced network security checking rules
# LOG-and-DROP rules:
iptables -N LOGDROP
iptables -A LOGDROP -j LOG --log-ip-options --log-tcp-options --log-level debug
iptables -A LOGDROP -j DROP
# Invalid tcp state flag checker rules
iptables -N valid-tcp-flags
iptables -A valid-tcp-flags -p tcp --tcp-flags ALL NONE -j LOGDROP
iptables -A valid-tcp-flags -p tcp --tcp-flags ACK,FIN, FIN -j LOGDROP
iptables -A valid-tcp-flags -p tcp --tcp-flags ACK,PSH PSH -j LOGDROP
iptables -A valid-tcp-flags -p tcp --tcp-flags ACK,URG URG -j LOGDROP
iptables -A valid-tcp-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGDROP
iptables -A valid-tcp-flags -p tcp --tcp-flags SYN,RST SYN,RST -j LOGDROP
iptables -A valid-tcp-flags -p tcp --tcp-flags FIN,RST FIN,RST -j LOGDROP
# Check TCP packets for invalid state flag combinations
iptables -A INPUT -p tcp -j valid-tcp-flags
iptables -A OUTPUT -p tcp -j valid-tcp-flags
iptables -A FORWARD -p tcp -j valid-tcp-flags
# Source and destination address checker rules
iptables -N valid-source-address
iptables -N valid-destination-address
iptables -A valid-source-address -s $RESERVED_IP_10_SPACE -j DROP
iptables -A valid-source-address -s $RESERVED_IP_172_SPACE -j DROP
iptables -A valid-source-address -s $RESERVED_IP_MULTICAST -j DROP
iptables -A valid-source-address -s $RESERVED_IP_FUTURE -j DROP
iptables -A valid-source-address -s $LOOPBACK -j DROP
iptables -A valid-source-address -s 0.0.0.0/8 -j DROP
iptables -A valid-source-address -d 255.255.255.255 -j DROP
iptables -A valid-source-address -s 169.254.0.0/16 -j DROP
iptables -A valid-source-address -s 192.0.2.0/24 -j DROP
iptables -A valid-destination-address -d $RESERVED_IP_MULTICAST -j DROP

# Verify valid source and destination addresses for all packets
iptables -A INPUT -i $EXT -p ! tcp -j valid-source-address
iptables -A INPUT -i $EXT -p tcp --syn -j valid-source-address
iptables -A FORWARD -i $EXT -p ! tcp -j valid-source-address
iptables -A FORWARD -i $EXT -p tcp --syn -j valid-source-address
iptables -A OUTPUT -o $EXT -j valid-destination-address
iptables -A FORWARD -o $EXT -j valid-destination-address

# Allowing outbound DNS queries from the FW and the replies to come in.
iptables -A OUTPUT -p udp -o $EXT --dport 53 --sport 1024:65535 -j ACCEPT
iptables -A INPUT -p udp -i $EXT --sport 53 --dport 1024:65535 -j ACCEPT
# Allow inbound DNS queries TO the firewall (to the BIND9 nameserver):
iptables -A INPUT -p udp -i $INT --dport 53 --sport 1024:65535 -j ACCEPT
# Allow ping out and reply in:
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
# Allow previously established connections, direction outbound.
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allow port 80 (www) and 22 (ssh) connection to the firewall, 80 for the
# internal net, ssh for internal net + from outside some hosts.
iptables -A INPUT -p tcp -i $INT --dport 22 --sport 1024:65535 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp -i $EXT --dport 22 -s 81.182.0.0/16 --sport 1024:65535 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp -i $INT --dport 80 --sport 1024:65535 -m state --state NEW -j ACCEPT
# Allowing the FW to access the internet (http:80, https:443)
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
# Allow ssh out from the FW
iptables -A OUTPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
# Allow irc port 6667 out and reply in
iptables -A OUTPUT -p tcp --dport 6667 -j ACCEPT
# Allow FTP out
iptables -A OUTPUT -p tcp --dport 21 -j ACCEPT
# Allow localhost's mail out of the FW (SMTP sends to port25 of the MTA like
# mx.axelero.hu)
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT

# Allow proxy access for the internal network
iptables -A INPUT -p tcp --dport 3128 -i eth0 -j ACCEPT

# Allow previously established connection's reply into the FW:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# *********************************************************************
# * NAT SETUP + filtering + portforward (if needed) *
# *********************************************************************
modprobe iptable_nat
modprobe ip_conntrack
modprobe ip_conntrack_irc
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
echo 1 >/proc/sys/net/ipv4/ip_forward
# Allow masquerading
iptables -t nat -A POSTROUTING -o $EXT -s 192.168.1.0/24 -d 0/0 -j MASQUERADE
# Prior to masquerading, the packets are routed via the filter table's
# FORWARD chain.
# Allowed outbound: NEW, ESTABLISHED, RELATED
# Allowed inbound: ESTABLISHED, RELATED
iptables -P FORWARD DROP
# "LAN -> Internet" rules come here:
# Allow all outgoing communication to the Internet:
# iptables -A FORWARD -t filter -i $INT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Some custom rules for LAN->Inet:
# http & https engedve:
iptables -A FORWARD -t filter -i $INT -p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -t filter -i $INT -p tcp --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# irc engedve:
iptables -A FORWARD -t filter -i $INT -p tcp --dport 6667:6668 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# sima ping engedve (flood vedelemmel):
iptables -A FORWARD -t filter -i $INT -p icmp --icmp-type echo-request -m state --state NEW -m limit --limit 3/s -j ACCEPT
# pop3 mail lekerdezeshez port
iptables -A FORWARD -t filter -i $INT -p tcp --dport 110 -j ACCEPT
# smtp, mail kuldeshez port
iptables -A FORWARD -t filter -i $INT -p tcp --dport 25 -j ACCEPT
# Messenger kilat netre
iptables -A FORWARD -t filter -i $INT -p tcp --dport 1863 -j ACCEPT
# SSH-zni lehessen a helyi LAN-rol ki a netre:
iptables -A FORWARD -t filter -i $INT -p tcp --dport 22 -j ACCEPT
# Telnet szinten menjen, ki tudja mi hasznalja
iptables -A FORWARD -t filter -i $INT -p tcp --dport 23 -j ACCEPT
# FTP Out:
#iptables -A FORWARD -t filter -i $INT -p tcp --dport 20 -j ACCEPT
#iptables -A FORWARD -t filter -i $INT -p udp --dport 20 -j ACCEPT
#iptables -A FORWARD -t filter -i $INT -p tcp --dport 21 -j ACCEPT
#iptables -A FORWARD -t filter -i $INT -p udp --dport 21 -j ACCEPT

# "Internet -> LAN" rules come here:
# Allow all incoming REPLY (!) communication to the LAN from the NET:
# (Ez minden fentebbi kimeno keres visszatero labat beengedi, igy a
# kommunikacio fennmarad es mukodik):
iptables -A FORWARD -t filter -i $EXT -m state --state RELATED,ESTABLISHED -j ACCEPT

Apropó hogy én hogy utálom ezt az új görgetősávos PH design-t.. Most Ti ezt hogy fogjátok ki copy-zni ?

És ahogy látom, itt-ott kimenő forgalmat is szűrtem. Ne feledjétek: az igazi biztonság a paranoia égisze alatt jön létre. És ez így helyes.

Szerk.: tán egy transzparens squid is elférne, stb.. (destination 80-at tiltani kifele és előtte átirányítani a router squid-jére)...

[ Szerkesztve ]

Jó cikk, köszönöm!

Igen, szeretnénk egy szájbarágós iptables cikket is!

Ja és minden szerverüzemeltetési cikk is jöhet ami a csövön kifér

[ Szerkesztve ]

Romani ite domum.

A fail2ban-hoz szeretném hozzáfűzni, hogy nemrégiben meggyűlt a bajom az etch-ben található verzióval.

A logrotate config fájl egy olyan parancsot használt, amitől a fail2ban process beragadt és egy újat indított helyette, minden egyes alkalommal. Ettől persze a logrotate és a cron is megakadt, öröm (?) volt nézni a sok cron jobot, miután kilőttem a fail2ban processeket

Neten találtam rá workaroundot, a következőre kellett lecserélni a logrotate configban a postrotate szekcióban lévő parancsot: fail2ban-client set logtarget /var/log/fail2ban.log

debian etch-en ilyet javasolni, hogy finoman fogalmazzak: tájékozatlanságra vall.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Tanits minket, mester!

Nagyszeru cikk, nem tudtam belekotni

Maximum annyi, hogy azert jobb az 5os debian.

DOMy

"̶d̶e̶ ̶a̶ ̶t̶u̶d̶o̶m̶á̶n̶y̶ ̶m̶a̶i̶ ̶á̶l̶l̶á̶s̶a̶ ̶s̶z̶e̶r̶i̶n̶t̶ ̶a̶z̶ ̶i̶p̶a̶r̶i̶ ̶m̶é̶r̶e̶t̶e̶k̶b̶e̶n̶ ̶i̶s̶ ̶h̶a̶s̶z̶n̶á̶l̶h̶a̶t̶ó̶ ̶S̶H̶A̶1̶ ̶c̶o̶l̶l̶i̶s̶i̶o̶n̶t̶ ̶g̶e̶n̶e̶r̶á̶l̶ó̶ ̶e̶s̶z̶k̶ö̶z̶..." - 2017. február 23. óta már létezik

A cikkben van pár gondolat arról, hogy etch-en csinálta, amiről szól. az alapértelmezett debian etch sshd-jében akkora bug van, mint a jupiter, ami azt okozza, hogy nagyon gyorsan és triviálisan törhető a jelszó nélküli ssh bejelentkezés.

ha már ez a javaslat, helyesebb lett volna pontosítani, hogy csak lennyn vagy minimum felupdate-lt etch-en érdemes kipróbálni.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Egy kicsit hátrébb az agyarakkal!
Az adott problémát másfél éve jelentették be, ami többek között ezt is tartalmazza: For the stable distribution (etch), these problems have been fixed in version 0.9.8c-4etch3., ami nekem azt jelenti, hogy a bejelentéssel együtt kiadták a javítást, tehát az szintén másfél éve elérhető. Azért azt tételezzük már fel (legalább egy biztonsággal foglalkozó cikkben), hogy a gép rendszeresen van frissítve! Azaz, ha valaki a hozzászólásom hatására generál magának kulcsot, akkor az nem lesz sérülékeny!
Ha arra hívtad volna fel a figyelmet, hogy a 2006-09-17 és 2008-05-13 (meg egy kicsi a biztonság kedvéért) között generált kulcsokat célszerű lehet lecserélni (de legalább ellenőrizni), annak még értelme is lett volna.

Hasznos kis cikk. Bár ssh-hoz és a PortKnocking módszert javasolnám. Alapesetben 22es port zárva, másik két szabadon választott port nyitva. Az egyik portra mondjuk telnettel "kopogtatva" meg tudjuk nyitni a 22-es portot az általunk választott ideig. A másik nyitott porttal pedig le tudjuk zárni a 22-es portot ha akarjuk. 3 éve megy evvel a módszer az egyik gépem amin Deb van.

Végre egy kis linuxos cucc .
Egy két apróság: a debian sajnos egyike a legkevésbé biztonságos disztróknak, mivel csigalassan fejlesztik, mire kijön egy új verzió, addigra már igazából elavult a többi disztróhoz képest. Egyébként egy basic user szinten konfigolt disztro is nagyságrendekkel biztonságosabb, mint bármelyik windóz, ha ésszel van használva.
A leírtak minden disztrónál alkalmazhatóak, nincs bennük semmi deb specifikus.
Én személy szerint jobban szeretem a redhat alapú disztrokat, és a KDE-t mint GUI-t
illetve a régi novelles emlékek miatt valamiért ragaszkodom a SUSE-hoz, de szerencsére
mindenki megtalálhatja a neki legmegfelelőbb verziót (itt nézz körül, ha nem tudod még milyen distro való neked).

A memóriám már nem a régi. És ráadásul még a memóriám sem a régi.

Ha már biztonság, akkor fedora...
A debian egyébként a kissebb distrokat kivéve a leghosszabb kiadási időközökkel rendelkezik, folyamatosan lemaradásban van a többihez képest, illetve a levlistája is követhetetlen (kb 1éve iratkoztam le róla).
A debiannak két előnye van, nincs stabilabb distro, mivel tényleg a végletekig csiszolgatják a kiadást és az APT szerintem a legjobb csomagkezelő.

A memóriám már nem a régi. És ráadásul még a memóriám sem a régi.

Te csak azt állíthatod, hogy a cikk, a cikk írója meg a te debianod naprakész.. Azt nem, hogy az olvasó vagy a tanácsod megfogadójának a debianja is naprakész. És mivel óriási biztonsági rést nyithat a jótanácsod, nem ártott volna ezt hangoztatni.

"A bejelentéssel együtt kiadták a javítást": ez ugye azt jelenti, hogy kiadták, elérhető, nem pedig azt, hogy fel is telepítette mindenki.

Továbbra is fenntartom: nem ártott volna erről figyelmeztetni az olvasót.

Az meg külön vitatéma lehetne, hogy érdemes-e jelszó nélküli bejelentkezést engedélyezni. Szerintem nem, mert ebben az esetben a bejelentkező gépe is célponttá válik és annak a biztonsága fogja meghatározni a másik biztonságát.

"Ha arra hívtad volna fel a figyelmet, hogy a 2006-09-17 és 2008-05-13 (meg egy kicsi a biztonság kedvéért) között generált kulcsokat célszerű lehet lecserélni (de legalább ellenőrizni), annak még értelme is lett volna.": ezzel két baj van:
1. NEKED KELLETT VOLNA erre felhívni a figyelmet
2. nem az számít, mikor generálta a kulcsot, hanem az, hogy melyik ssh-keygen (ssl, stb.) verzióval. Azokon a gépeken, amiket nem frissítettek, most is lehet rossz kulcsot generálni.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Ekkora baromságot régen olvastam... Attól, hogy nem a legfrissebb programverziók vannak a debianban, még nem lesz sérülékeny, mert mindig van security update.

A másik kérdés: két release között átlagosan sokkal kevesebb idő telik el, mint fél év, a 4.5 hónap jobb közelítés. Ennél még a fedora is lassabb a majdnem pont hat hónapos ciklusaival.

A legbugosabb linux disztró most nálam a buguntu, miután kiderült a csomagszámozási átverős hülyeségük...

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Ami régi, nem feltétlenül kevésbé biztonságos. Van hozzá security update, másrészt van backport is.
Redhat aktuális verziója 2.6.18-as kernelt használ. Pedig az már elég régi. Mégsem mennek rajta a rút exploitok amik azóta készültek.

(#25) bambano:

nem kell ekkora feneket keríteni az ügynek. A szerzőt megkérjük szépen, hogy tegye be az emlékeztetőt az írásba, hogy mindenki tartsa naprakészen rendszerét és kész.
Amúgy mi az az ubuntu verziószámozás izé?

[ Szerkesztve ]

Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!

Nekem nem a Debil az első disztróm, de bátran kijelenthetem, hogy azért kicsit merészség a leszólása, mondjuk én nem stable-t használok hanem testing-et.

Aki ért a rendszerhez, az tudja, hol kell foltozni. Mert mindegyik disztrót lehet, ez eleve meddő vita, hogy ez így jó, az úgy jó, az amúgy jó..

Elnézést a megkésett reakcióért, de hétvégén nem voltam netközelben.

Először is köszönöm mindenkinek a javaslatokat, hozzászólásokat, Racecam-nak pedig a kiemelést.

A komplexitása miatt nem volt egyszerű úgy megírni ezt a kis cikket, hogy semmi fontosat ne hagyjak ki belőle, de ne is merüljek bele túlzottan. Amint az látható még rengeteg módszer lenne, amit megemlíthetnénk, több ilyen is érkezett a hozzászólásokban. (Ezeket nagyon köszönöm, a Port Knocking nekem is új volt.) A jövőben lehet, hogy készítek majd egy folytatást, addig pedig gyűjtöm a gondolatokat és a kimaradt, de mégis fontosnak tartott módszereket.

Ahogy láttam a certificate-es SSH bejelentkezés kisebb vitát robbantott ki. Én sem jegyeztem meg külön, mert nálam magától értetődik, hogy mindig frissítsük a rendszerünket, de ez előfordulhat, hogy nem mindenkinek ennyire nyilvánvaló. Tehát kicsit kiegészítettem az ide vonatkozó részt, megemlítettem ezt a lehetőséget is, de csak abban az esetben, ha updatelt etch-n vagy lenny-n kerül kipróbálásra.

Sftp... na igen, ezt egy az egyben kifelejtettem, de a felvetés teljesen jogos. Ha fontosak az adatok és nem csak a családi fotók vagy a linux disztribúciók kerülnek megosztásra, akkor erősen ajánlott az sftp beizzítása.

Ha az időm engedi a következő cikkem az iptables beállításokat, parancsokat és szabályokat fogja majd taglalni, az alapoktól szeretném kezdeni és szép lassan építeni fel, hogy a végén egy komoly, mindenre kiterjedő script jöhessen létre (a fentebb bemásolt is egész szép darab )

https://wpszaki.hu - Minden, ami WordPress, cikkek kezdőknek és haladóknak.

Amennyiben azt akarjuk, hogy egy megadott mappához csak FTP-n keresztül férhessen hozzá, akkor ne engedjük máshova bejelentkezni, állítsuk a shell-jét /bin/false-ra.

Azért ezzel a mondattal is lehetne kötekedni, mert ez se teljesen így van... Sőt...

Kötekedj nyugodtan Örömmel tanulok új dolgokat és azt is próbáltam kiemelni, hogy én sem tartom profinak magam a témában, sőt... de szeretek kísérletezni, szeretem képezni magam és ebbe beletartozik az is, hogy kijavítanak, ha nem teljesen helytálló, amit írok.

https://wpszaki.hu - Minden, ami WordPress, cikkek kezdőknek és haladóknak.

Kár a kiadási időközökön lovagolni szerintem... volatile? backports? És volt már így frisebb csomagom, mint Ubi server alá...

Hát... Azért elég nyűgös tud lenni az apt, részemről akkor már inkább urpmi

Nem mindenkinek van FIX IP címe... Sőt... Még csak "közvetlen" publikus IP-je sem... Ilyen alapon portscanneléssel is be tudnak kopogtatni hozzád - ha nem csak FIX IP-ről engeded. Én egyszer teszt jelleggel használtam ilyet. Aztán beakadt egy process, fullra belassítva mindent. Mobil netről világ végéről mire bekopogtam és a jó port aktiválódott illetve be is tudtam lépni... Mindegy lett volna ha telefonálok a szerver hotelbe, hogy srácok: restart...

Félre értés ne essék, nem kötekedni akarok én, és nagyon is örülök végre egy faxa Linuxos ismertetőnek. Az SFTP hiányát én is észrevettem, de közben olvastam, hogy mások is írták. /bin/false teljesen biztonságos tud lenni, mert be nem lép vele senki (requiredvalidshell)
De ha már... MySQL-ből hitelesítéshez nem kellenek "valódi" userek

evasive lennytől csomagból telepíthető. Beállítással vigyázni kell: fordult már elő, hogy letiltott, mikor nem kellett volna. Pl Ajax -os bevitel ellenőrző cuccok, mint pl a google ajánlatok.

psad viszont új nekem is, majd kipróbálom

Várjuk az iptables leírást, remélhetőleg az is ennyire jó lesz és érhető. Akik mágsem akarnak/mernek foglalkozni majd vele, azok "játszhatnak" firewall-jay -jel, de azzal is csak óvatosan - azért azzal is kizárhatja magát az ember a saját rendszeréből

De ha már iptables... Valaki segíthetne amúgy abban, hogy: adott két internet kapcsolat. Egyik legyen 10/10 mbit, a másik meg 50/1. Hogyan lehet azt megoldani, hogy 10 mbites uploaddal menjenek felfelé a cuccok és 50-el jöjjön lefelé? Köszi előre is

Ha nem egy szolgáltatótól vannak a címek, akkor elég zűrösen...
a két drót megosztását ebben az esetben csak úgy tudod megoldani, ha egyik protokoll(halmaz) mindig az egyik dróton megy ki, a másik meg a másikon.

az tehát működik, hogy a nagy uploadon torrentezel, közben a másikon webezel, az, hogy a torrenforgalom kimenő iránya a nagy uploadon menjen ki, a bejövő iránya meg a nagyobbik dróton jöjjön be, az nem fog menni, ha nem egy szolgáltatótól van a két drót.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Torrent rész úgy nem, hogyha 2 kliens futtat, mindkettő másik trackerhez kapcsolódik?

(#38) djsilas:
Ja hogy az 1 gép? Így már még értelme is van.

(#31) The DJ:

Epekedve várjuk.

[ Szerkesztve ]

Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!

Az alapszabály, hogy minden csomagnak azon a dróton kell kimennie, amelyikhez tartozik az ip cím, ami feladóként szerepel benne.

Ha képes vagy értelmesen szétválogatni a csomagokat, akkor mindent meg lehet csinálni. De nem ismerem ennyire a torrent protokollokat, hogy hogy lehet megmondani a kliesnek, melyik ip-re bindeljen és az összes forgalmát milyen portokkal bonyolítsa. Ha ezt nem túl nagy erőfeszítéssel meg tudod oldani, akkor menni fog, ha nem, akkor a szolgáltató minden idegen csomagot el fog hajigálni.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Ez simán megy. 2 kliens, egyik X másik Y porton. Egyik port kommunikációját egyik vonalon küldöd, másikét másikon. Semmi extra.

mod_evasive

Telepítése már a cikkben linkelt URL-ről nem elérhető. A telepítés menete:

apt-get install libapache2-mod-evasive

Majd kell egy log könyvtár:

mkdir -p /var/log/apache2/evasive

és ezt tegyük írhatóvá:

chown -R www-data:root /var/log/apache2/evasive

Innentől ugyanaz, mint a cikkben

[ Szerkesztve ]

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak