And by "it'd be great", what you really mean is "the article is completely useless without them". Half of the items are "no shit"; another 20% is "huh?", and the remaining are "that might be interesting to learn more about - but with no additional information, I don't even have enough keywords to Google to find out more".
I tried to write up a little about the ones that I know something about, here it is:
Data on the network cannot be altered.
False, if something goes through another device, it can be altered. Important because, well, man in the middle.
Encrypted data on the network cannot be altered.
Same as the above. Harder, but still doable
Data cannot be accidentally corrupted, because TCP has checksums and Ethernet has CRCs
This is about like saying "only 1 bit can be flipped at once, so parity checking will always catch it"
If it's inside my perimeter firewall, that means I have total control over it (@armorguy)
Similar to the top ones, still harder, but it's a weak point if someone gets into your perimeter at all.
Packets arrive in the order in which they were sent.
Completely false, though TCP will reorder them back to the original order for you.
If you can't ping the target, then it doesn't exist. (@jjarmoc)
Trivial to make a host not respond to pings
If you can ping the target, then it does exist.
Again, trivial to make a router or any device respond to pings for a lot of IPs
TCP RSTs come from end-nodes.
Devices in the middle sending RSTs is really common, google "comcast rst packets"
Bytes must be "swapped" from the network byte-order to the host CPU byte-order.
IP/TCP and such protocol bytes must be swapped. The only thing that cares at the application layer is the application code, it can just say "everything is little endian" and be done with it.
It's an internal web app -- outsiders won't be able to discover where it is (@biosshadow)
if this is about a "exposed under an obscure name", the tools like fierce can probe for it. If it's exposed to the internet at all, consider it under attack at all times.
The DHCP address will be the same after a reboot (@shewfig)
Not necessarily true, depends on the DHCP server and such.
The DHCP address will remain the same until the next reboot.
You get a lease time, OBSERVE IT. Don't just keep using it cause you say "this is mine still!"
Well, it'll last a long time between changes
One culprit is coffeeshops, there have been reports of coffeeshops with 30 minute lease times. I've seen cable modems hand out 30 second leases, but that was when it was still trying to connect to the cable side, so it wanted the computer to keep checking back
The DHCP server and local router are the same (@schrotthaufen)
Not at all a requirement, and would cause your packets to go off into nowhere if you tried to rely on it.
> The only thing that cares at the application layer is the application code,
True, but...
> it can just say "everything is little endian" and be done with it.
... doesn't quite follow. If you're blitting integers directly, your code will break on either a big- or little-endian boxes. Better to pick a standard encoding and always serialize/deserialize properly whatever that means. That standard encoding may be little-endian (maybe better than big-endian - such systems are overwhelmingly more common on the desktop/server) or may be some packed representation. But ideally you could change the representation without changing application code other than the serialization/deserialization itself (which may well live in a library).
I had taken that to read that there are programs in the wild that assume hosts are little endian and always "swap" bytes as opposed to converting between the two orders (which might be a no-op on a big endian system).
>> It's an internal web app -- outsiders won't be able to discover where it is (@biosshadow)
>if this is about a "exposed under an obscure name", the tools like fierce can probe for it. If it's exposed to the internet at all, consider it under attack at all times.
This is effectively the problem with all of these "things programmers assume" articles: they give no solutions and effectively just moan about possible problems.
Cellular carriers will ACK a packet destined for a device on their network before they have actually delivered it if they have the device registered and are confident they can deliver the packet "soon." I have seen packets happily being ACKed that are destined for a device that I just powered down. About a minute later the carrier starts telling the truth, but now you have no idea what actually got through to your device.
Or at least they're unique on a single machine... except for the various OSes and hardware platforms that have deliberately made all MAC addresses the same for a given machine.
Way back in the land before time, I acquired a number of old 486s and ISA NICs. Being a good Slashdot nerd, I of course thought "lets make a Beowulf cluster of these!"
So I've got the cluster set up, and it's mostly working. There's two nodes though that behave funny. Imagine my surprise when I try pinging one of them and get two responses per ping! Sure enough, two ISA NICs pulled randomly out of a box of garbage indeed had identical MACs. I learned a lot about IP and the MAC layer from that project!
Seems to have missed the falsehood that everything on the network will respond really quickly and so it's fine to have loads of blocking calls on starting an application
Well, NBO is big endian and PPC/Sparc/MIPS were usually BE in servers, now in routers and TVs, and LE in printers... Though POWER8 switched to LE.
So you can (and I have) write programs for these BE systems that completely neglect to use swizzling. You will also see code that doesn't use the swizzling macros (htons, ntohs, etc) because they 'know' the packets need to be swizzled and they do it always, when they shouldn't on some architectures.
31 comments
[ 0.22 ms ] story [ 55.1 ms ] threadhttps://people.eecs.berkeley.edu/~rcs/research/interactive_l...
Actually - the return packets are ICMP (TTL expired in transit), but the packets you send, _by default_, are UDP.
Traceroute can indeed be instructed to use ICMP though, but it's not the default on an any OS I know.
Windows not uses ICMP by default, but there is no switch to use UDP packets instead of ICMP packets.[1]
Yes, I'm well aware that UDP is the default on most Unix-based systems.
1. https://technet.microsoft.com/en-us/library/cc940128.aspx
explain
Then there are all the ways an employee can inadvertently or intentionally make its existence public.
https://www.google.com.au/search?q=discovering+internal+web+...
Leading to gems like this:
https://www.verisgroup.com/2014/07/15/internal-web-applicati...
And this:
https://books.google.com.au/books?id=lXr0AgAAQBAJ&pg=PA429&l...
Or even this:
http://www.pentest-standard.org/index.php/Intelligence_Gathe...
And of course even that's only true within a single connection.
True, but...
> it can just say "everything is little endian" and be done with it.
... doesn't quite follow. If you're blitting integers directly, your code will break on either a big- or little-endian boxes. Better to pick a standard encoding and always serialize/deserialize properly whatever that means. That standard encoding may be little-endian (maybe better than big-endian - such systems are overwhelmingly more common on the desktop/server) or may be some packed representation. But ideally you could change the representation without changing application code other than the serialization/deserialization itself (which may well live in a library).
>> It's an internal web app -- outsiders won't be able to discover where it is (@biosshadow)
>if this is about a "exposed under an obscure name", the tools like fierce can probe for it. If it's exposed to the internet at all, consider it under attack at all times.
"ACKs come from an end node"
Cellular carriers will ACK a packet destined for a device on their network before they have actually delivered it if they have the device registered and are confident they can deliver the packet "soon." I have seen packets happily being ACKed that are destined for a device that I just powered down. About a minute later the carrier starts telling the truth, but now you have no idea what actually got through to your device.
- MAC addresses are unique.
- LANs won't be bridged.
- Spanning tree will converge quickly.
- Quickly enough that it will beat BIOS getting to DHCP for netbooting.
- There will only be one circuit in the network so you can disable spanning tree.
- The path MTU will be at least 1500 (or 9000, or x).
- Path MTU discovery will work.
- Packets with DF bit set won't be fragmented.
- ICMP won't be dropped.
- Network circuits will be the same path in both directions.
- There will be one NIC / a default route.
- The domain name 'localhost' will always resolve to localhost, or 127.0.0.1.
- A DNS responder exists on the network.
- It is a good idea to try to resolve IP addresses as names.
- A device will use IPv4 by default (some systems opportunistically look for A and AAAA addresses and try both).
- All networks have a path to the internet.
- There will be no proxy required, or
- The proxy won't require a login, or
- The proxy credentials won't have a backslash.
I'm diverging higher up the stack at this point so I'll stop.
Or at least they're unique on a single machine... except for the various OSes and hardware platforms that have deliberately made all MAC addresses the same for a given machine.
One more: - There will never be more than 1000/2000/... MAC addresses per subnet.
So I've got the cluster set up, and it's mostly working. There's two nodes though that behave funny. Imagine my surprise when I try pinging one of them and get two responses per ping! Sure enough, two ISA NICs pulled randomly out of a box of garbage indeed had identical MACs. I learned a lot about IP and the MAC layer from that project!
- Localhost is 127.0.0.1
- A TCP SYN will also always result in a SYN-ACK
- Ok, a SYN-ACK or a RST
- Ok, ok, an out-going TCP packet will always result in a TCP response
https://support.f5.com/kb/en-us/solutions/public/13000/200/s...
"Bytes must be "swapped" from the network byte-order to the host CPU byte-order."
Don't PowerPC and Sparc hardware require byte swapping(depending on what endian mode they are in)? Or am I misreading this?
So you can (and I have) write programs for these BE systems that completely neglect to use swizzling. You will also see code that doesn't use the swizzling macros (htons, ntohs, etc) because they 'know' the packets need to be swizzled and they do it always, when they shouldn't on some architectures.