Sziasztok!
Az alábbi iptables beállításokkal eléggé furcsállom, hogy sok kapcsolatot látok iftopban. Egyedül az első sort értem, mert az az én ssh sessionöm, amivel nézelődöm. Tudnátok segíteni, hogy miért lehet ez? Mit nézek be?
Az 54321 az ssh port.
A sajathost pedig én vagyok.
iptables:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:54321 state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:http state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:https state ESTABLISHED
ACCEPT udp -- anywhere anywhere udp spt:domain
ACCEPT icmp -- anywhere anywhere icmp echo-reply
LOGGING all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp spt:54321 state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:https state NEW,ESTABLISHED
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT icmp -- anywhere anywhere icmp echo-request
Chain LOGGING (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 2/min burst 5 LOG level debug prefix "IPTables Packet Dropped: "
DROP all -- anywhere anywhere
iftop:
12.5Kb 25.0Kb 37.5Kb 50.0Kb 62.5Kb
mqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqqqqqqq
sajathost:54321 => 51B6541F.dsl.pool.telekom.hu:49453 2.66Kb 4.52Kb 5.70Kb
<= 160b 160b 224b
255.255.255.255:bootps => 0.0.0.0:bootpc 0b 0b 0b
<= 3.84Kb 3.08Kb 2.37Kb
bp1.mylora.hu:41993 => all-systems.mcast.net:3000 2.48Kb 1.36Kb 1.39Kb
<= 0b 0b 0b
239.255.255.250:1900 => 185.80.51.215:57673 0b 0b 0b
<= 0b 643b 161b
vrrp.mcast.net => 185.80.50.9 0b 0b 0b
<= 640b 640b 640b
185.80.49.221 => vrrp.mcast.net 512b 512b 512b
<= 0b 0b 0b
vrrp.mcast.net => 185.43.206.15 0b 0b 0b
<= 512b 512b 512b
185.80.49.111 => vrrp.mcast.net 448b 448b 448b
<= 0b 0b 0b
185.80.49.142 => vrrp.mcast.net 384b 384b 384b
<= 0b 0b 0b
185.80.49.234 => vrrp.mcast.net 320b 320b 320b
<= 0b 0b 0b
185.43.206.158 => vrrp.mcast.net 320b 320b 320b
<= 0b 0b 0b
185.43.204.188:1985 => 224.0.0.102:1985 320b 256b 247b
<= 0b 0b 0b
TE-V200.CR1.BUD.rackforest.net:1985 => 224.0.0.102:1985 320b 256b 247b
<= 0b 0b 0b
185.43.204.189:1985 => 224.0.0.102:1985 320b 256b 240b
<= 0b 0b 0b
TE-V200.CR0.BUD.rackforest.net:1985 => 224.0.0.102:1985 320b 256b 240b
<= 0b 0b 0b
sajathost:52575 => rns1.rackforest.hu:domain 0b 58b 14b
<= 0b 198b 49b
sajathost:50892 => rns1.rackforest.hu:domain 0b 58b 15b
<= 0b 197b 49b
224.0.0.252:hostmon => 185.80.50.245:61192 0b 0b 0b
<= 0b 189b 47b
224.0.0.252:hostmon => 185.80.50.245:53330 0b 0b 0b
<= 0b 189b 47b
224.0.0.252:hostmon => 185.80.50.245:56181 0b 0b 0b
<= 944b 189b 47b
224.0.0.252:hostmon => 185.80.50.245:58011 0b 0b 0b
<= 0b 189b 47b
224.0.0.252:hostmon => 185.80.50.245:64169 0b 0b 0b
<= 0b 189b 47b
185.43.205.255:netbios-ns => 185.43.205.166:netbios-ns 0b 0b 0b
<= 0b 187b 47b
185.43.206.255:netbios-ns => 185.43.206.235:netbios-ns 0b 0b 0b
<= 0b 187b 47b
185.80.50.255:netbios-ns => 185.80.50.234:netbios-ns 0b 0b 0b
<= 0b 187b 47b
sajathost:39480 => rns1.rackforest.hu:domain 0b 58b 15b
<= 0b 110b 27b
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
TX: cum: 43.9KB peak: 13.9Kb rates: 2.66Kb 4.91Kb 6.61Kb
RX: 89.1KB 26.1Kb 12.3Kb 13.8Kb 14.5Kb
TOTAL: 133KB 40.0Kb 14.9Kb 18.8Kb 21.1Kb
Köszönöm előre is a segítséget!
Soma
Hozzászólások
Nézd meg az értékeket, és gondold újra, mit értesz komoly forgalom alatt!
Szia!
Igazad van, a postban ezért írtam kapcsolatot, csak a címben írtam rosszul. Most megváltoztattam a címet ennek megfelelően. Szóval a forgalom valóban elhanyagolható lenne, azonban nem értem miért van ennyi nyitott kapcsolat, miközben ezeknek az én tudomásom szerint nem is szabadna létezniük.
Nincsenek nagyszámú nyitott kapcsolataid.
Az iftop kimenetében látunk hozzád is elérő broadcast (DHCP/bootps) és multicast (VRRP, HSRP, LLMNR, UPnP) forgalmakat. De ezekre a te géped nem válaszol, láthatod, hogy a kimenő irányok nullás sorok.
Az iftop (tcpdump, wireshark, pcap, stb.) nem csak azt látja, ami a netfilter szabályokban (iptables) be van engedve, ugyanis még a netfilter előtt kapja el a forgalmat.
A tűzfalat kellene még csiszolgatni, például a DNS nem csak UDP-t használ, hanem TCP-t is tud. Nem kellene kitiltani az ICMP protokoll fontosabb típusait.
Nem tudtam, hogy az iftop még az iptables előtt kapja el a forgalmat. Így már világos, megnyugodtam. Köszönöm!
Viszont, ez felvet nekem egy kérdést. Hogyan tudom monitorozni azt a forgalmat, amit ténylegesen be/ki is enged a netfilter?
Áttérve pedig az észrevételedre:
Kiegészítem, hogy tcp is legyen dns esetén, ez rendben van:
iptables -A OUTPUT -p tcp -o eth0 --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --sport 53 -j ACCEPT
Azonban az icmpvel sajnos nem vagyok tisztában. Nézegettem, milyen típusai vannak, de nem tudom mit érdemes ki- és beengedni. Ebben tudnál segíteni? Amennyire tudom a pinget befelé érdemes tiltani.
"Viszont, ez felvet nekem egy kérdést. Hogyan tudom monitorozni azt a forgalmat, amit ténylegesen be/ki is enged a netfilter?"
Pontosan mit (és miért) szeretnél?
"Amennyire tudom a pinget befelé érdemes tiltani."
Miért?
Hát, az ilyen és ehhez hasonló cikkekből gondoltam.
Butaság?
Butaság... :)
Ajánlom, hogy használd a conntrack lehetőségeit is!
--
Debian Linux rulez... :D
RIP Ian Murdock
Köszönöm a conntrack ötletet. Nagyon jó kis cuccnak tűnik!
Csak visszaidéznék az idézetedből egyetlen egy részt:
That doesn't mean your machine is more secure, the machine is just not that easy to be seen from the internet. Nothing more.
ICMP mely típusait érdemes engedélyezni?
Amire gondolok, kiegészítve a echo reply-al, amire mondták itt korábban, hogy butaság letiltani:
0 echo reply
3 destination unreachable
8 echo request
11 time exceeded
15 information request
16 information reply
17 address mask request
18 address mask reply
30 traceroute
31 datagram conversion error
4 fragmentation needed
Ezt ne csak befelé, hanem kifelé is engedd.
Ennek a kiszűrése meggátolja az MTU discovery-t és igen sok hajadat tudod kitépni, amíg rájössz, hogy a kis teszt e-mailek miért mennek át (jönnek meg), de a normál forgalom miért nem.
Ne vigyük félre a kérdezőt. Ő ICMP Type-okat sorolt fel, te meg a Type 3 alá tartozó Code-ról beszélsz (Type 3 Code 4).
(Régebben a Type 4-et is illett átengedni, azonban a Source Quench egy ideje már deprecated.)
Általánosságban talán a legfontosabb, hogy a Type 3 menjen. Ha traceroute-olni akarsz, akkor a Type 11 bejöjjön. Ha a hostot kintről traceroute-olod, akkor ki tudjon menni. A Type 3 alatti Code-okra is tudsz szűrni.
ICMP esetén én naívan megfordítanám a kérdést:
Melyiknek látod értelmét kitiltani, és miért?
Hát kicsit zavarban vagyok, így hogy kérdezed, lassan kezdem azt hinni, hogy alig van értelme kitiltani bármelyiket is.
Akkor jófelé változik a meglátásod.
Max. érdemes megnézni mekkora jelenleg a hálózatod icmp forgalma.
Beszorozni, mondjuk 10-el. (Vagy épp a mögötte lévő hálózat méretétől, meg jövőre gondolással együtt stb. egy akármi 1-nél nagyobb - use your gut-feeling - számmal)
Majd egy ennek megfelelő ratelimitet rátenni a forward-ra.
Találtam egy korrektnek tűnő leírást:
Ebben mondjuk jóval kevesebb icmp type van mint amit én leírtam. Mindenesetre, ha ezeket engedem befelé és kifelé is akkor jó leszek? (csak az ipv4-re vonatkozóakat, mert ipv6 most nincs)
"Pontosan mit (és miért) szeretnél?"
A közeljövőben egy tomcates java alkalmazást szeretnék futtatni, ami elsősorban restes kéréseket fog kiszolgálni. Ennek lennék kíváncsi majd az adatforgalmára.
Hát, remélem, nem iftoppal gondoltad :)
Egy sima log bőven megteszi.
Igazából reméltem, hogy iftoppal, vagy valami hasonló tool-al meg lehet oldani. :)
SARCASM ON
Aztán eléültetsz egy biorobotot?
SARCASM OFF
Nem élek tomcattel, de ha konkrétan egy webes alkalmazás adatforgalmára vagyok kíváncsi statisztikai céllal, kiszedem az access.log fájlból.
Ha precízebb kell, akkor netfilterből logold az adott portra jövő és arra válaszként adott forgalmat, csak gondold végig, hogy az ezzel járó terhelés megéri-e a mikroszekundum-pontosságot.
Azért persze, vannak átmenetek, de pl. az alkalmazás szempontjából az irreleváns, hogy mi az, amit megfogsz akár a tűzfalon, akár a webszerver oldalán, és el sem jut az alkalmazásszerverig.
"akkor netfilterből logold az adott portra jövő és arra válaszként adott forgalmat"
Ha csak számolni kell, akkor ne logolja, hanem action nélküli szabályt vegyen fel, azon bármikor látszik az összesített forgalom.
Bevallom, alapvetően Mikrotiken nevelkedtem, majd szoktam vissza a netfilterre. Hogy van ez az action nélküli megoldás?
Úgy hogy nem adsz neki "action"-t...
pl.: iptables -t filter -A INPUT -i eth0 -s 192.168.0.254
--
Debian Linux rulez... :D
RIP Ian Murdock
Megtaláltam, a -v kapcsoló lett volna a kérdés...
Köszi a tanácsot! Egyelőre az access loggal fogok próbálkozni.