Das längste Thema

    Zitat von mainziman

    warum bricht meine Leitung ein, wenn ich alles mit DROP terminiere, und nichts antworte?


    Zitat von mainziman

    man findet auch einiges zum Thema DROP vs. REJECT


    ich hab es bis jetzt mit der Default-Regel DROP


    Zitat von mainziman

    die Default Policy von DROP auf ACCEPT geändert


    was jetzt? drop, reject oder accept?


    wir reden hier schon von der default-policy, ja? könnt noch immer sein, daß Du als letzte rule eine catch-all drinnen hast die dann anders als die default-policy "abweist".


    und die default-policy ingres auf accept zu stellen ist imho keine gute idee!


    unabhängig davon was Du eingestellt hast, es steht alles in der von mir verlinkten antwort.

    Code
    When using DROP rules: 
- UDP packets will be dropped and the behavior will be the same as connecting to an unfirewalled port with no service. 
- TCP packets will return an ACK/RST which is the same response that an open port with no service on it will respond with. Some routers will respond with and ACK/RST on behalf of servers which are down.
When using REJECT rules an ICMP packet is sent indicating the port is unavailable.
    Zitat von hoedlmoser

    was jetzt? drop, reject oder accept?

    wir reden hier schon von der default-policy, ja?

    ja davon


    Code
    *filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

    wenn ich hier an Stelle ACCEPT aber DROP nehme, dann bricht die Leitung ein;

    REJECT als default policy ist nicht möglich (liefet einen Fehler);


    Zitat von hoedlmoser

    und die default-policy ingres auf accept zu stellen ist imho keine gute idee!

    offensichtlich das einzig Richtige ...

    wenn ich die paar Ports welche ich von bestimmten Quellen offen brauch,

    mit einer 2ten Regel

    f. TCP

    -A INPUT -i eth1 -p tcp --dport <Port> -j REJECT --reject-with tcp-reset

    f. UDP

    -A INPUT -i eth1 -p udp --dport <Port> -j REJECT

    terminiere

    dann liefert ein Portscan von anderer Stelle bei TCP mit -sS bzw. -sT

    nmap -v -p 1-1024 -sS <IP>

    Code
    Initiating SYN Stealth Scan at 11:01
Scanning #DNS (#IP) [1024 ports]
Completed SYN Stealth Scan at 11:01, 22.81s elapsed (1024 total ports)
Nmap scan report for #DNS (#IP)
Host is up (0.18s latency).
All 1024 scanned ports on #DNS (#IP) are closed

    einzig gewußt hätt ich, wie ich das 'Host is up' auf 'Host is down' hier bring; ICMP wird gedropp'd

    sprich ein ping <IP> bringt das ...

    Code
    PING #IP (#IP) 56(84) bytes of data.
^C
--- #IP ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7657ms

    ein traceroute liefert das ...

    Code
    traceroute to #IP (#IP), 30 hops max, 60 byte packets
 1 ...
 2 ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  5.913 ms  5.971 ms  5.947 ms
 3-7 [...]
 8 * * * an Stelle meines Routers
 9 * * *
10-29 [* * *]
30 * * *

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Zitat von mainziman

    wenn ich hier an Stelle ACCEPT aber DROP nehme, dann bricht die Leitung ein

    entgegen der von mir oben verlinkten und zitierten antwort von serverfault muß ich mich korrigieren, DROP verwirft das packerl gänzlich, da antwortet der server mit genau nix!


    warum bei Dir im gegenständlichen fall die leitung einbricht wenn der server die packerle verwirft erklärt sich mir nicht, kann aber wahrscheinlich nur in zusammenhang mit Deinem router gesehen werden.


    hier seien meine ergebnisse bzgl iptables mit drop und reject zusammengefasst:

    client versucht sich am server auf port 23 via TCP zu verbinden, dort lauscht aber kein daemon

    • in einem jungfräulichen zustand (policy accept und keine rules) meldet der client ein 'Connection refused', im tcpdump sieht man einen reset und nmap meldet den port als closed.
    • mit der policy drop braucht der client 2 minuten und 10 sekunden um ein 'Connection timed out' zu melden, im tcpdump sieht man nur wiederholte syns des client, nmap sieht den port nach knapp 2 sekunden scan als filtered.
    • mit einer expliziten reject rule meldet der client ein 'Connection refused', im tcpdump sieht man einen 'ICMP tcp port unreachable' und nmap meldet den port als filtered.
    • mit einer tcp reset reject rule meldet der client ein 'Connection refused', im tcpdump sieht man einen reset und nmap meldet den port als closed.

    ein interessanter artikel bzgl DROP vs REJECT sei auch noch erwähnt http://www.chiark.greenend.org…rb/network/drop-vs-reject er kommt zu dem konklusio, daß man DROP aus clientsicht wegen timeouts vermeiden möchte.


    Zitat von mainziman

    offensichtlich das einzig Richtige ...

    offensichtlich keine ahnung. oder hast Du am ende Deines regelwerks noch eine catch-all reject rule?


    Zitat von mainziman

    wenn ich die paar Ports welche ich von bestimmten Quellen offen brauch,

    mit einer 2ten Regel

    [...]

    terminiere

    Du weißt aber schon, daß der erste match greift?! da kannst Du danach rejecten was Du willst.


    Zitat von mainziman

    All 1024 scanned ports on #DNS (#IP) are closed

    aus meinen empirischen tests von oben leite ich mal ab, daß nmap dann einen port als closed meldet, wenn mit einem RST geantwortet worden ist. das heißt aber in weiterer folge, daß Du die packerle nicht dropst. sondern entweder in iptables mit einem 'REJECT --reject-with tcp-reset' oder Dein betrübssystem einen TCP RST raus haut.


    Zitat von mainziman

    einzig gewußt hätt ich, wie ich das 'Host is up' auf 'Host is down' hier bring; ICMP wird gedropp'd

    wozu dropped man ICMP? ist das schon wieder so ein 'security by obscurity' ding?

    und wenn Du das wirklich auf down haben willst, dann könnte man das in der man page von nmap nachlesen, ich hab das mal für Dich getan.

    Zitat

    If no host discovery options are given, Nmap sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request.

    Echt jetzt? Ihr macht euch über 200 MBit/s lustig?

    Euch ist schon klar, dass vielerorts noch nicht mal das zu Verfügung steht.

    Ich selbst bin z.B. froh mittlerweile 50 MBit/s zu haben. :)

    Für mich wären 200/20 also tatsächlich "fett" ;)

    (OK, 175 könnte ich inzwischen bekommen... Ist aber unnötig. Mir reichen die 50 tatsächlich völlig)

    Zitat von DerRené

    Und mit Cable kannste mich jagen

    Der Meinung war ich lange auch.

    Aber mit docsis3.1 habe ich andere Erfahrungen. Das CMTS sitzt ja nicht mehr in der Kopfstation, sondern wird über HFC quasi an die Straßenecke verlagert.

    Mit entsprechender Priorisierung, die man wohl erhält wenn man einmal mittels der Breitbandmessung-App nachgewiesen die Rechnung kürzt, komme ich kaum noch unter 800 im Downstream.

    Zitat von aRaphael

    Echt jetzt? Ihr macht euch über 200 MBit/s lustig?

    Nein, eher über den Vergleich mit ISDN als Datenmedium. Das sollte es doch selbst in Österreich inzwischen nirgends mehr geben.

    Und: 200Mbit ist auch allgemein nicht mehr wirklich das, was als "fette Leitung" bezeichnet wird. :)

    Zitat von aRaphael

    Euch ist schon klar, dass vielerorts noch nicht mal das zu Verfügung steht.

    durchaus, aber ändern kann ich daran auch nichts. 🤷‍♂️ ;)


    Zitat von aRaphael

    Mir reichen die 50 tatsächlich völlig

    jeder hat eben andere Bedürfnisse. gingen hier "nur" 50 MBit/s, würden wir damit sicher auch irgendwie klarkommen - damals ging's ja mit einem 56K Modem auch irgendwie... Aber hey, was ein Leistungssprung als dann mit ISDN Kanalbündelung möglich war und die 2. Leitung dann doch nicht, wie ursprünglich geplant, zum Telefonieren frei war. xD Die Ansprüche steigen eben. :)


    Mich hat lediglich die Formulierung "fett" getriggert, da 200 MBit/s eben in vielen Regionen möglich sind. Sei es durch die Giga-Offensive von Vodafone (mit etwas Glück kommt ja dann auch ne gewisse Geschwindigkeit abends noch beim TN an) oder eben den vielerorts vorangetriebenen FTTH-Ausbau. Wird auch langsam mal Zeit.

    Zitat von DerRené

    Mich hat lediglich die Formulierung "fett" getriggert

    vor x Jahren hatte ich einen dicken PC; der hatte in etwa die Power die unsere Server in der Arbeit hatten;

    ist alles relativ; ;)


    Zitat von ASS

    Nein, eher über den Vergleich mit ISDN als Datenmedium. Das sollte es doch selbst in Österreich inzwischen nirgends mehr geben.

    wieso sollte es ISDN nicht mehr geben?

    der Vergleich mit ISDN war einfach der, dass EIN Portscan bei einer ISDN Leitung diese dicht macht, sollte klar sein, aber eine 200/20 MBit Leitung ...


    ich mein welche Technik ist denn bei den Breitband-Internetzugängen in Dtl. die verbreitete?

    in Österreich dürften es entweder tatsächlich Glasfaser, wenn die Energieversorger mal was in die Pampa verlegen

    oder in urbanen Gebieten die DOCSIS Geschichte sein;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Zitat von ASS

    Weil in Deutschland mittlerweile wohl auch die letzten ISDN Vermittlungen abgebaut und verschrottet sind.

    In DE war die Ausgangssituation auch eine andere. Soweit ich weiß war bei euch (fast) alles ISDN. Von einigen wenigen Ausnahmen mal abgesehen ;)


    In Österreich war bzw. ist es genau umgekehrt. Da war POTS quasi Standard und ISDN ist war das Premiumprodukt, das meistens nur Firmen hatten.

    Zitat von ASS

    Oder hat man die nach Österreich exportiert?

    ^^

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Danke 1
    Zitat von hoedlmoser

    wozu dropped man ICMP? ist das schon wieder so ein 'security by obscurity' ding?

    deswegen ...

    Zitat

    If no host discovery options are given, Nmap sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request.

    und zu meiner Überraschung, seit dem ich des heute gedropp'd habe, sind die Zugriffe um rund ¼-½ gesunken; :)

    wir reden hier nicht über einen vServer sondern über mein Internet zu Hause; ;)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Zitat von hoedlmoser

    aluhut. dann viel spaß mit zb Fragmentation Needed (IPv4) / Packet Too Big (IPv6).

    der Aluhut ist dann wohl auf Deiner Seite, oder erklär mir, wie so ein Paket zu mir kommen kann, ohne,

    dass es das Ergebnis eines zuvor versendeten Paketes ist? ;)

    jede korrekt konfigurierte IPtables Router-/Firewall hat folgende Regeln
    -I FORWARD -i <WAN-Device> -o <LAN-Device> -m state --state ESTABLISHED,RELATED -j ACCEPT

    bzw.

    -I INPUT -i <WAN-Device> -m state --state ESTABLISHED,RELATED -j ACCEPT

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)