hi folks, i just wanted to say that you should keep in mind that there are different implementations for ping/traceroute. windows clients are using icmp packets while linux is using udp packets on port 33434+ (afair). so just try to ping through your firewall from a windows client. it should work if you set up ipchains to masq icmp echo-request packets and accept incoming echo-replys. greets jb -----Ursprüngliche Nachricht----- Von: Gerling, Stephan [mailto:gerling@kub.de] Gesendet: Donnerstag, 25. Mai 2000 12:40 An: 'suse-security@suse.com' Betreff: [suse-security] IPChains Hi list, I'am trying to set up an firewall with IPCHAINS. If the IPCHAINS-Script is not started, i kann do everything. (i use the same script on an other maschine and it works very fine and i want to change the maschines) But now wenn i start the script, the rules are loaded, but i cannot ping to the outside here the error messages ping wrote xxx.xxx.xxx.xxx 64 chars, ret=-1 ping sendto :Operating is not permitted ip-forwarding is enabled. Has anyone an idea. I'm going sick about this regards, Stephan Gerling
On Fre, 26 Mai 2000 Bauer, Juergen wrote about AW: [suse-security] IPChains:
hi folks, i just wanted to say that you should keep in mind that there are different implementations for ping/traceroute. windows clients are using icmp packets while linux is using udp packets on port 33434+ (afair). so just try to ping through your firewall from a windows client. it should work if you set up ipchains to masq icmp echo-request packets and accept incoming echo-replys. greets jb
-----Ursprüngliche Nachricht----- Von: Gerling, Stephan [mailto:gerling@kub.de] Gesendet: Donnerstag, 25. Mai 2000 12:40 An: 'suse-security@suse.com' Betreff: [suse-security] IPChains
Hi list, I'am trying to set up an firewall with IPCHAINS. If the IPCHAINS-Script is not started, i kann do everything. (i use the same script on an other maschine and it works very fine and i want to change the maschines) But now wenn i start the script, the rules are loaded, but i cannot ping to the outside
here the error messages ping wrote xxx.xxx.xxx.xxx 64 chars, ret=-1 ping sendto :Operating is not permitted
ip-forwarding is enabled.
Has anyone an idea. I'm going sick about this
regards, Stephan Gerling
---------------------------------------- Content-Type: text/html; name="unnamed" Content-Transfer-Encoding: quoted-printable Content-Description: ---------------------------------------- -- ----------------------------------------------------- Martin Peikert EN 636 Fachgebiet Theoretische Elektrotechnik TU Berlin Sekretariat EN 2 fon 314-23881 fax 314-22284 http://www-tet.ee.tu-berlin.de/peikert/index.html -----------------------------------------------------
On Fre, 26 Mai 2000 Bauer, Juergen wrote about AW: [suse-security] IPChains:
hi folks,
---snip--- ---------------------------------------- Content-Type: text/html; name="unnamed" Content-Transfer-Encoding: quoted-printable Content-Description: ---------------------------------------- ---snip--- First, I apologize for my last mail. What I wanted to say is: I _LOVE_ these html-postings. Martin. -- ----------------------------------------------------- Martin Peikert EN 636 Fachgebiet Theoretische Elektrotechnik TU Berlin Sekretariat EN 2 fon 314-23881 fax 314-22284 http://www-tet.ee.tu-berlin.de/peikert/index.html -----------------------------------------------------
On Fri, 26 May 2000, Bauer, Juergen wrote:
i just wanted to say that you should keep in mind that there are different implementations for ping/traceroute. windows clients are using icmp packets while linux is using udp packets on port 33434+ (afair).
just by traceroute. ping uses under Linux also icmp. bye mw -- Markus Werner mwr@hud.de Hönigsberg & Düvel Datentechnik GmbH BZO Haus 20, 38840 Wolfsburg Tel: +49 173 927 361 5 http://www.hud.de
On Fri, May 26, 2000 at 13:02 +0200, Markus Werner wrote:
On Fri, 26 May 2000, Bauer, Juergen wrote:
i just wanted to say that you should keep in mind that there are different implementations for ping/traceroute. windows clients are using icmp packets while linux is using udp packets on port 33434+ (afair).
just by traceroute. ping uses under Linux also icmp.
AFAIK ping always uses ICMP. traceroute uses UDP (Ports cited above) by default but can be told to use ICMP, too. See "man 8 traceroute", Options "-p" and "-I", for more info. And to make it security relevant, again (that's what we're here for after all): ping can act as a tunnel transporting data from and to the outside *if* you have a relay station inside your LAN. That's why admins sometimes decide to block pings and traceroutes and no user should feel any real loss about it. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Gerhard,
i just wanted to say that you should keep in mind that there are different implementations for ping/traceroute. windows clients are using icmp packets while linux is using
Keep in mind that ICMP packets other than the request types aren't ever to be answered by an ICMP packet. A router sending ICMP_TIME_EXCEEDED for such an ICMP packet violates the standards (loops are the result).
udp packets on port 33434+ (afair). just by traceroute. ping uses under Linux also icmp.
AFAIK ping always uses ICMP. traceroute uses UDP (Ports cited above) by default but can be told to use ICMP, too. See "man 8 traceroute", Options "-p" and "-I", for more info.
And to make it security relevant, again (that's what we're here for after all): ping can act as a tunnel transporting data from and to the outside *if* you have a relay station inside your LAN. That's why admins sometimes decide to block pings and traceroutes and no user should feel any real loss about it.
This is right, but it's also a good advice _not_ to filter ICMP packets coming through the firewall into the internal network or at least to the hosts that can take advantage of ICMPs (notably mailservers or such). Without these control messages long timeouts or inefficient bandwidth usage is the result. Example: your MTA connects to a host that is filtered behind a firewall. If the filter doesn't send ICMPs, your MTA must wait until the first timeout occurs, until it will connect to the next MX. This slows down the whole process. Thanks, Roman. -- _ _ | Roman Drahtmüller "The best way to pay for a | CC University of Freiburg lovely moment is to enjoy it." | email: draht@uni-freiburg.de - Richard Bach | - -
On Sat, May 27, 2000 at 01:57 +0200, Roman Drahtmueller wrote:
Gerhard,
And to make it security relevant, again (that's what we're here for after all): ping can act as a tunnel transporting data from and to the outside *if* you have a relay station inside your LAN. That's why admins sometimes decide to block pings and traceroutes and no user should feel any real loss about it.
This is right, but it's also a good advice _not_ to filter ICMP packets coming through the firewall into the internal network or at least to the hosts that can take advantage of ICMPs (notably mailservers or such). Without these control messages long timeouts or inefficient bandwidth usage is the result.
That's why I wrote something along the lines of "decide to block pings and traceroutes" since I remember the discussions bubbling up time after time on blocking ICMP completely either breaks whole TCP stacks or important functionality thereof. The most popular feature suffering from missing ICMP seems to be MTU discovery, other problems include the timeouts you talk about. But looking at all the ICMP packet types one should at least block the redirect ones. And besides "dest unreach", "param prob", "source quench" and "time exceeded" everything else seems luxurious to pass through. The "unreach" could be filtered even more for its subtypes. And *if* you have to enable echo reqs and replies, you better block icmp to the network and broadcast addresses (remember smurf, tfn and the other DoSes?). To further protect against attacks, one would wish for a feature like FreeBSD's icmp bandwidth limiting -- is there something similar for Linux? virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Gerhard Sittig wrote:
But looking at all the ICMP packet types one should at least block the redirect ones. And besides "dest unreach", "param prob", "source quench" and "time exceeded" everything else seems luxurious to pass through. The "unreach" could be filtered even more for its subtypes. And *if* you have to enable echo reqs and replies, you better block icmp to the network and broadcast addresses (remember smurf, tfn and the other DoSes?). To further protect against attacks, one would wish for a feature like FreeBSD's icmp bandwidth limiting -- is there something similar for Linux?
Yes, traffic shaping. Documentation can be found in the kernel source tree. Have a nice read. Fred
* Gerhard Sittig wrote on Sat, May 27, 2000 at 11:09 +0200:
But looking at all the ICMP packet types one should at least block the redirect ones. And besides "dest unreach", "param prob", "source quench" and "time exceeded" everything else seems luxurious to pass through.
Do you know what happens to the payload of such packets? May the be used like in icmp echo request packets?
And *if* you have to enable echo reqs and replies, you better block icmp to the network and broadcast addresses (remember smurf, tfn and the other DoSes?).
BTW: if a firewall rejects echo request (with comm adm. prohibited), ordinary ping shows normal output, but of course even if the pinged host is down. Additionally it seems to be possible to block fragmentated ICMPs always, since usually those packets are very small, ain't? (Comments?) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Sat, May 27, 2000 at 18:18 +0200, Steffen Dettmer wrote:
* Gerhard Sittig wrote on Sat, May 27, 2000 at 11:09 +0200:
But looking at all the ICMP packet types one should at least block the redirect ones. And besides "dest unreach", "param prob", "source quench" and "time exceeded" everything else seems luxurious to pass through.
Do you know what happens to the payload of such packets? May the be used like in icmp echo request packets?
I don't know (didn't care up to now). Maybe it's time to go and fetch the appropriate RFC and have some reading ... AFAIK the ping tunnel uses the variable length payload to contain the data (which is usually just stuffed when you use the -s switch). And nobody seems to care about echo requests and replies. I'm not sure wether the above icmp packet types have room for these things or if they just get truncated right after the header.
And *if* you have to enable echo reqs and replies, you better block icmp to the network and broadcast addresses (remember smurf, tfn and the other DoSes?).
BTW: if a firewall rejects echo request (with comm adm. prohibited), ordinary ping shows normal output, but of course even if the pinged host is down.
There's always the choice between rejection and denial. :) BTW I'm aware of the fact that denied packets "reveal" there's some kind of filter in between, attracting the kids like locked doors to forbidden rooms ... But I'd rather have them run against a wall they see than letting them go as far as they want to _if_ they try and come at all.
Additionally it seems to be possible to block fragmentated ICMPs always, since usually those packets are very small, ain't? (Comments?)
Any decent firewall (or even the TCP stack) should drop corrupted and malformed packets even before the header fields are looked at and used to base decisions upon. It's mad enough that the fw rules act on behalf of data anyone untrusted delivers to you you actually try to defend against. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
* Gerhard Sittig wrote on Sat, May 27, 2000 at 22:18 +0200:
On Sat, May 27, 2000 at 18:18 +0200, Steffen Dettmer wrote:
* Gerhard Sittig wrote on Sat, May 27, 2000 at 11:09 +0200: Do you know what happens to the payload of such packets? May the be used like in icmp echo request packets?
AFAIK the ping tunnel uses the variable length payload to contain the data (which is usually just stuffed when you use the -s switch).
Yepp, in the payload of the packets. Should work with all ICMP Messages I think.
And nobody seems to care about echo requests and replies. I'm not sure wether the above icmp packet types have room for these things or if they just get truncated right after the header.
I cannot imagine that a ordinary router would modify packets in such a way! Of course, the target machine would ignore it usually, but it seems no problem to write a piece of code that could get the data out of this ping (or whatever) stream. I saw a program doing that IIRC, fraq router or something like this IIRC...
BTW: if a firewall rejects echo request (with comm adm. prohibited), ordinary ping shows normal output, but of course even if the pinged host is down.
There's always the choice between rejection and denial. :)
Yes, but of course this makes the difference. I talked about rejects only.
BTW I'm aware of the fact that denied packets "reveal" there's some kind of filter in between, attracting the kids like locked doors to forbidden rooms ...
Why should this happen? I would assume, that kids would think they hit a machine that is currently down or unused IP/DNS Name. I usually don't use packet deny but reject. Since all packets become rejected, and ICMPs become generated, I cannot imagine what could attract some kids or whoever. They see a firewall only, not more.
Additionally it seems to be possible to block fragmentated ICMPs always, since usually those packets are very small, ain't? (Comments?)
Any decent firewall (or even the TCP stack) should drop corrupted and malformed packets even before the header fields are looked at and used to base decisions upon.
Are you sure, that a fragmentated ICMP is corrupt always? Maybe there are some ways/nets with a very small MTU?
It's mad enough that the fw rules act on behalf of data anyone untrusted delivers to you you actually try to defend against.
But there's no information in a packet you could trust usually! Of course you could use IPSec only, but even in this case you need an open port 500 for keyexchange of course. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Am 28-May-00 um toeggelte Steffen Dettmer:
Why should this happen? I would assume, that kids would think they hit a machine that is currently down or unused IP/DNS Name. I usually don't use packet deny but reject.
I prever deny over reject. Deny is like a down machine, giving the attacker no info, and let him wait longer, and produces less ICMP-traffic.
Since all packets become rejected, and ICMPs become generated, I cannot imagine what could attract some kids or whoever. They see a firewall only, not more.
Yeah, they see it with reject, with deny they could only assume. ----------------------------------------------------------------------- Daniel Etter | http://www.etter.ch/~daniel | Tel. : +41 1 884 75 01 Ringstrasse 2 | | Fax : +41 1 884 62 50 8107 Buchs ZH | mailto:Daniel.Etter@etter.ch | Natel: +41 79 354 93 75
On Sun, May 28, 2000 at 18:07 +0200, Steffen Dettmer wrote:
* Gerhard Sittig wrote on Sat, May 27, 2000 at 22:18 +0200:
BTW I'm aware of the fact that denied packets "reveal" there's some kind of filter in between, attracting the kids like locked doors to forbidden rooms ...
Why should this happen? I would assume, that kids would think they hit a machine that is currently down or unused IP/DNS Name.
Portscanning a machine with some ports open and some denied (i.e. without reaction) will tell you there's some blocker in between, usually a packet filter. Of course denial slows the scan (it's running to timeouts instead of getting quick responses). But rejecting will make you subject to fingerprinting. Although I'm not *that* sure of all these things, I simply got used to - pass the valid services - deny the others and - reject auth (tcp 113) only to not slow down SMTP delivery and others curious about these things (but still not relying upon them, so I don't break anything) Feel free to tell me I'm wrong, chances are quite overwhelming that I am. :) Luckily I'm just an average user and not a "real" admin. :>
I usually don't use packet deny but reject. Since all packets become rejected, and ICMPs become generated, I cannot imagine what could attract some kids or whoever. They see a firewall only, not more.
Here's what I got from reading the ipfilter HowTo which has a lot of general firewalling stuff, too. (I guess I have to dig up the URL, it could be recommended reading. Unless somebody else already has it handy and can deliver it faster than me.) Rejecting closed TCP ports and sending icmp-unreach for closed UDP ports and ICMP requests will make the machine look like it would without the filter. Denying will reveal that there's something blocking, making the kids think "something's wrapped, it's precious and interesting for me". But it turns out to be left to the admin's personal taste to choose between denial and rejection.
Any decent firewall (or even the TCP stack) should drop corrupted and malformed packets even before the header fields are looked at and used to base decisions upon.
Are you sure, that a fragmentated ICMP is corrupt always? Maybe there are some ways/nets with a very small MTU?
There I was writing quicker than I was with reading. :( Fragmented ICMP packets aren't (necessarily) corrupted. But I had in mind an Bugtraq article of the last days where a cracker misused artificially wrongly fragmented ICMP to fool TCP stacks. It seems to be necessary to always defragment everything on a firewall. Trying to cut corners often turns out to fail sooner or later. And by employing path MTU discovery fragmentation should even become uncommon and avoidable. Maybe one even should drop fragmented packets in general, as well as too short packets to be real and source routed packets where the workstation (or origin) thinks to be more clever than the routers about routing? virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
There I was writing quicker than I was with reading. :( Fragmented ICMP packets aren't (necessarily) corrupted. But I had in mind an Bugtraq article of the last days where a cracker misused artificially wrongly fragmented ICMP to fool TCP stacks. It seems to be necessary to always defragment everything on a firewall. Trying to cut corners often turns out to fail sooner or later. And by employing path MTU discovery fragmentation should even become uncommon and avoidable. Maybe one even should drop fragmented packets in general, as well as too short packets to be real and source routed packets where the workstation (or origin) thinks to be more clever than the routers about routing?
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
Hi Gerhard, It is necessary to always defragment on a firewall, because you may not be able to tell what an IP packet actually contains. A non-defragmenting port filtering firewall can only apply the rules to the TCP/UDP header data in the first fragment. All following fragments may or may not belong to an existing connection (TCP), but the filter can't tell if it doesn't defragment. This is why non-defragmenting filters should let all fragments other than the first one pass. The cost of maintaining a list of saddr+daddr/first frag passed the filters justifies general defragmentation. Now there's an old trick: Make the fragments so small that even the TCP headers don't fit in in full length. If you don't have the header of a packet, you can't filter it by ports. (Keep in mind that fragmentation happens in the IP-layer, not in the TCP/UDP/ICMP/...-layer.) Either you drop a fragment with offset 0 that isn't long enough for a complete TCP, UDP, ICMP, ... header and accept all other frags, or you reassemble the whole datagram before you route it somewhere. The latter is recommended (and necessary for Linux), despite the performance drawback. The thing with MTU discovery: If it works, it maximizes your network throughput, if it doesn't, people will say that this O/S has a "slow" network/IP implementation. MTU discovery doesn't cause a security problem, but admins who filter _all_ ICMPs cause an MTU discovery problem (among others). Keeping to the standards still leaves you enough room for configuration and is not neccessarily a contradiction to security. Dropping fragmented packets is definitely not an option. It violates the standards, and it will make your firewall/filter somewhat unusable (you'd f.ex. notice that interactive session protocols such as ssh and telnet (and ftp-control connection) work fine, but others (http, ftp-data) don't because the packets sent are big enough to need fragmentation). Redefining the standards is an option, though... The source routed frames thing you mention is important! Thanks, Roman. -- _ _ | Roman Drahtmüller "The best way to pay for a | CC University of Freiburg lovely moment is to enjoy it." | email: draht@uni-freiburg.de - Richard Bach | - -
* Gerhard Sittig wrote on Sun, May 28, 2000 at 22:24 +0200:
On Sun, May 28, 2000 at 18:07 +0200, Steffen Dettmer wrote:
* Gerhard Sittig wrote on Sat, May 27, 2000 at 22:18 +0200:
Why should this happen? I would assume, that kids would think they hit a machine that is currently down or unused IP/DNS Name.
Portscanning a machine with some ports open and some denied (i.e. without reaction) will tell you there's some blocker in between, usually a packet filter.
Yepp, think so too.
Of course denial slows the scan (it's running to timeouts instead of getting quick responses). But rejecting will make you subject to fingerprinting.
I found many scans are very slow, i.e. a port every 20 minutes or so, to prevent IDS from working. What tells i.e. nmap when trying to analyse fingerprints of your linux box?
Although I'm not *that* sure of all these things, I simply got used to - pass the valid services - deny the others and - reject auth (tcp 113) only to not slow down SMTP delivery and others curious about these things (but still not relying upon them, so I don't break anything)
Yepp, at least ident should be rejected in my opinion too.
Feel free to tell me I'm wrong, chances are quite overwhelming that I am. :) Luckily I'm just an average user and not a "real" admin. :>
Well, I think that is mostly a question of police. I found most blocked accesses were misconfigurations or similar. I don't know what an attacker win, if she knows that the packetfilter sends ICMPs. The argument of delaying scans doesn't matter IMHO, since you can use a parallel scan or whatever.
Here's what I got from reading the ipfilter HowTo which has a lot of general firewalling stuff, too.
Rejecting closed TCP ports and sending icmp-unreach for closed UDP ports and ICMP requests will make the machine look like it would without the filter.
I think this is wrong, at least for linux ipchains, since the generated ICMP is of the type "communication administrativly prohibited", which looks different from "connection refused". But maybe some very stupid script kiddies wouldn't see this...
Denying will reveal that there's something blocking, making the kids think "something's wrapped, it's precious and interesting for me".
Well, another argument: When they see a firewall, they know that there are some security systems running. So they may decide to attack networks without security systems first, since they see there's no real chance to find a hole by scanning. If they search for a DNS Server (most networks have one), and they get a block for all ports they try to access, they know they don't need to go on. If there are some addresses looking like a down machine, they may decide to scan again next day.
Fragmented ICMP packets aren't (necessarily) corrupted. But I had in mind an Bugtraq article of the last days where a cracker misused artificially wrongly fragmented ICMP to fool TCP stacks.
last days... mmm... Do you mean the jolt2 thing? IIRC this wasn't a real fraqmentation style attack but a DoS, except for Microsoft systems maybe.
It seems to be necessary to always defragment everything on a firewall.
Of course, i.e. to prevent address rewriting by fraqmentations offsets overwriting the IP Addresses.
Trying to cut corners often turns out to fail sooner or later. And by employing path MTU discovery fragmentation should even become uncommon and avoidable.
Sorry, couldn't get this. You mean to prohibite MTU discovery? This could slow down connections a lot, especially if you have a "defragment always" firewall AFIAK.
Maybe one even should drop fragmented packets in general,
Ohh, I don't think that this would work!
as well as too short packets to be real and source routed packets
it's not so quite easy to drop too short packets I think. Telnet may send packets with just one byte date for instance. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Mon, May 29, 2000 at 12:36 +0200, Steffen Dettmer wrote:
* Gerhard Sittig wrote on Sun, May 28, 2000 at 22:24 +0200:
Trying to cut corners often turns out to fail sooner or later. And by employing path MTU discovery fragmentation should even become uncommon and avoidable.
Sorry, couldn't get this. You mean to prohibite MTU discovery? This could slow down connections a lot, especially if you have a "defragment always" firewall AFIAK.
I wasn't very clear it seems. I meant: When path MTU discovery (and obeying the gotten values, of course:) is a common technique, fragmentation shouldn't have to happen at all. So I still feel that dropping fragmented packets in general to be a valid option. It will only disturb the partners not adjusting their MTU and thus causing problems (afford in terms of cpu cycles and memory consumption) to me. Unless I got something wrong (confused some layers?) in which case I'm sure you tell me I did. (I already start to develop a feeling of this to be true. I'll await to learn and get rid of this misbelief ...)
Maybe one even should drop fragmented packets in general, as well as too short packets to be real and source routed packets
it's not so quite easy to drop too short packets I think. Telnet may send packets with just one byte date for instance.
By too short a packet I thought of "not having enough room to even contain a full IP header and whatever is the header of the layer above (TCP/UDP for ports, ICMP for types, etc). This doesn't touch the length of the payload for the application. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
* Gerhard Sittig wrote on Mon, May 29, 2000 at 19:12 +0200:
On Mon, May 29, 2000 at 12:36 +0200, Steffen Dettmer wrote:
* Gerhard Sittig wrote on Sun, May 28, 2000 at 22:24 +0200: [at this ident level]
I wasn't very clear it seems. I meant: When path MTU discovery (and obeying the gotten values, of course:) is a common technique, fragmentation shouldn't have to happen at all.
I cannot imagine that MTU discovery works through masquerading routers, since the ICMP would never reach the sender. Correct me if I'm wrong.
So I still feel that dropping fragmented packets in general to be a valid option.
Useing IPSec FreeS/WAN you would drop most packets, since they use internally a MTU around 16K IIRC, and a "re-fragmentation" occurs [AFAIK].
cycles and memory consumption) to me. Unless I got something wrong (confused some layers?) in which case I'm sure you tell me I did.
Well, maybe there're some (broken) implemtations without MTU discovery or with a buggy one. Maybe a Palm IIIx (don't know anything about it's IP stack, but it's a simple one)...
it's not so quite easy to drop too short packets I think. Telnet may send packets with just one byte date for instance.
By too short a packet I thought of "not having enough room to even contain a full IP header and whatever is the header of the layer above (TCP/UDP for ports, ICMP for types, etc). This doesn't touch the length of the payload for the application.
Well, so it would be simply malformed you mean? Isn't the linux kernel dropping such packets always? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (8)
-
Bauer, Juergen -
Daniel Etter -
Fred Mobach -
Gerhard Sittig -
Markus Werner -
Martin P.Peikert -
Roman Drahtmueller -
Steffen Dettmer