Hirdetés

2018. november 19., hétfő

Gyorskeresés

Hozzászólások

(#1) Coyot


Coyot
(őstag)

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

HP gen8 microservert vennék

(#2) Szőröstalpú


Szőröstalpú
(tag)

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

(#3) Speeedfire válasza Coyot (#1) üzenetére


Speeedfire
(PH! nagyúr)

jó kis cikk

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

Fotóim https://www.flickr.com/photos/speeedfire85/ || Weblapom http://tothszabi.info || Linkkatalógusom http://weblapkeszites.ro

(#4) dabadab


dabadab
(Jómunkásember)

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

(#5) hcl


hcl
(PH! félisten)
LOGOUT blog

"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! :R

@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 ]

Veszek _hibás_ LCD monitort,fényképezőgépet, objektívet, routert ---- Mutogatni való hater díszpinty

(#6) zsokomo


zsokomo
(újonc)

Köszönöm, ez hasznos volt :)

(#7) exx


exx
(kvázi-tag)

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

(#8) Vladi


Vladi
(PH! nagyúr)

Jó kis betekintő írás. :K
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.

Jani másszál fel! Maradj a kompon!

(#9) montlig


montlig
(újonc)

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

(#10) Honkydoo


Honkydoo
(őstag)

Grat a cikkhez! Szeretek ilyesmit olvasni. :)

"Fordítsd az arcodat a nap felé, és minden árnyék mögéd kerül."

(#11) #40935168 válasza hcl (#5) üzenetére


#40935168
(törölt tag)

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

(#12) #40935168 válasza #40935168 (#11) üzenetére


#40935168
(törölt tag)

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 ? :D

É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 ]

(#13) ZCoyote


ZCoyote
(PH! addikt)

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 :D

[ Szerkesztve ]

Romani ite domum.

(#14) seby


seby
(újonc)

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

(#15) bambano válasza Szőröstalpú (#2) üzenetére


bambano
(Jómunkásember)

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

lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

(#16) lenox válasza bambano (#15) üzenetére


lenox
(PH! addikt)

Tanits minket, mester! :)

(#17) domi007


domi007
(őstag)

Nagyszeru cikk, nem tudtam belekotni :DD :DD

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

(#18) bambano válasza lenox (#16) üzenetére


bambano
(Jómunkásember)

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.

lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

(#19) Szőröstalpú válasza bambano (#18) üzenetére


Szőröstalpú
(tag)

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.

(#20) hcl válasza #40935168 (#12) üzenetére


hcl
(PH! félisten)
LOGOUT blog

Huhh, ez jó lett :) Mire átrágom magam rajta :)

Amúgy a kimenő forgalom szűrése nem hülyeség. Paranoiából pl. :)

Veszek _hibás_ LCD monitort,fényképezőgépet, objektívet, routert ---- Mutogatni való hater díszpinty

(#21) pbalintka


pbalintka
(újonc)

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.

(#22) atkamano


atkamano
(lelkes újonc)

Végre egy kis linuxos cucc :R .
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.

(#23) dabadab válasza atkamano (#22) üzenetére


dabadab
(Jómunkásember)

"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"

ROTFL. A Debian talán az egyik legbiztonságosabb, bár tény, hogy az egyik legrondább eset (a már emlegetett ssh bug) is ott esett meg.

DRM is theft

(#24) atkamano válasza dabadab (#23) üzenetére


atkamano
(lelkes újonc)

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.

(#25) bambano válasza Szőröstalpú (#19) üzenetére


bambano
(Jómunkásember)

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.

lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

(#26) bambano válasza atkamano (#22) üzenetére


bambano
(Jómunkásember)

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...

lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

(#27) Vladi válasza atkamano (#22) üzenetére


Vladi
(PH! nagyúr)

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é? :F

[ Szerkesztve ]

Jani másszál fel! Maradj a kompon!

(#28) #40935168


#40935168
(törölt tag)

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ó..

(#29) #40935168 válasza hcl (#20) üzenetére


#40935168
(törölt tag)

Ha nem szűröd, és bejön egy olyan kérés, ami kifele olyan kapcsolatot kezdeményez, aminek ismét lesz már visszatérő lába, az onnantól kezdve a stateful viselkedés miatt ismét bejön. És már kész is a biztonsági rés.

Mindig szűrök kifele is, de azóta sokkal többminden van még a script-ben.

(#30) bambano válasza Vladi (#27) üzenetére


bambano
(Jómunkásember)

itt nekiálltak fikázni az ubuntut, hogy újabb verziószámú csomagokban régebbi verziószámú szoftver van.
Aminek lehet egy olyan következménye, hogy upgradelni kellene biztonsági okokból, de a verziószám kamuzás miatt nem teszed.

lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

(#31) The DJ


The DJ
(PH! addikt)

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. || http://kepfeltolt.es - A kedvenc képfeltöltő oldalad a weben!

(#32) djsilas


djsilas
(tag)

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...

(#33) djsilas válasza atkamano (#22) üzenetére


djsilas
(tag)

Jézusom... Nem attól lesz vmi biztonságos, hogy mikor adták ki! A Debian inkább a legbiztonságosabb, mint legkevésbé...
KDE-vel annyi a gond, hogy lassú, a RedHat alapú disztókkal meg hosszas szenvedések után sem tudtam megcsinálni azt, amit Debianon pár perc....

(#34) The DJ válasza djsilas (#32) üzenetére


The DJ
(PH! addikt)

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. || http://kepfeltolt.es - A kedvenc képfeltöltő oldalad a weben!

(#35) djsilas válasza atkamano (#24) üzenetére


djsilas
(tag)

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 :)

(#36) djsilas válasza pbalintka (#21) üzenetére


djsilas
(tag)

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...

(#37) djsilas válasza The DJ (#34) üzenetére


djsilas
(tag)

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) :P
De ha már... MySQL-ből hitelesítéshez nem kellenek "valódi" userek ;)

(#38) djsilas


djsilas
(tag)

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 :P

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 :)

(#39) bambano válasza djsilas (#38) üzenetére


bambano
(Jómunkásember)

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.

lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

(#40) Vladi válasza bambano (#39) üzenetére


Vladi
(PH! nagyúr)

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. :DDD

(#31) The DJ:

Epekedve várjuk. :R

[ Szerkesztve ]

Jani másszál fel! Maradj a kompon!

(#41) bambano válasza Vladi (#40) üzenetére


bambano
(Jómunkásember)

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.

lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

(#42) #40935168 válasza bambano (#41) üzenetére


#40935168
(törölt tag)

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.

(#43) Fecogame


Fecogame
(PH! addikt)

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 ]

16dBi / 38cm WiFi antennák raktárról ---> https://goo.gl/D29Wz

Copyright © 2000-2018 PROHARDVER Informatikai Kft.