Any protocol that isn't designed to accomdate NAT is incompatible with the modern Internet and is obsolete by design
Wrong. You mix up different problems. There are 'evil' protocols like ftp or ipsec or sun/rpc or... which are not compatible with single NAT (client NATed, server not). ie. they negotiate a random second port for a data channel like ftp does. These protocols are 'bad by design'. Some of them can be NATed if the nat box tracks the negotiation ("ftp helper module").
But mr. Walker is speaking about the double NAT problem: if client (the peer that initiates a connection) and the server (the peer that receives that initial packet) are located behind NAT boxes you are lost. NO protocol is compatible to that situation.
Many propose "oh just configure portforwarding on your NAT box", but that does not scale. Imagine a bunch of workstations configured via dhcp behind NAT (typical setup in mid-range companies). How do you set up that? What are you doing as netadmin if everyday another P2P protocol pops up?
Mr. Walker's rant is sad but true. The only solutions i see are
wait for ipv6 and hope it's potential will be used (instead of re-apply NAT to it)
(will never happen) create a generic protocol for NAT-box communication for anvertising internal services. Each p2p-protocol could use it. NAT box vendors had to implement it.
(the way IM services work) install huge proxies which route all p2p-traffic
(the way filesharing networks work) classify peers: 'good' peers are not NATed and act as proxies for the others. As gratification they get more bandwidth within the fs-network
forget p2p
I am sure that we all would use VoIP now if there were no NAT.
To be precise: they have much more noise, but You can only use a fraction of that noise for steganography. Otherwise You would destroy or significantly alter the original content of the compressed file.
The basic problem with steganography is that it hides content in noise but compression reduces noise.
It is easy to 'steganohide' content in uncompressed noisy files like tiff or wav. But that content gets destroyed by lossfull compression which is mainly used by multimedia formats (jpeg, mpeg, divx, mpg3,...). If not, it's called a watermark, but (un)fortunately nobody found a watermark algorithm yet which is robust against lossfull codecs and adding some more noise.
So You have to steganohide Your content after compressing. But compressed files have much less noise, and that noise is not random noise but has statistical quirks. If You just hide Your content as white noise and add it to the file - thats detectable, because it changes the statistical behaviour of the file!
Instead You have to write an specific steganografic algorithm for each lossfull compression format You want to hide content in! It has to respect the 'format noise character'. That's what Niels Provos did for pnm and jpeg with outguess.
Serial numbers only affect master-slave communication (and selfwritten scripts violating rfcs), but all masters and slaves for.com &.net belong to VS. See Paul Vixies reply to the same question on NANUG.
/graf0z.
Finally, the patch party is over (for now).
on
Kernel 2.6.1 Released
·
· Score: 4, Insightful
I got really tired of applying combinations of those patches to newest kernel source (due to security issues). They 're now all included to 2.6! Only MPPE-support seems still to lack.
They must have beaten up Linus to get all those accepted...
Linus and co ripped out [...] i think they've learned their lesson and try everything to avoid that pain. 2.6 will probably stabalize much faster than 2.4 (see also Alan Cox' post).
The only remote filesystem i found where the en-/decryption of files is done on the client side is TCFS. Unfortunately, it seems to be not maintained any more (last news 13months old, linuxversion still uses 2.2).
All other "encrypting remote filesystems" encrypt only the filetransfer, not the filestorage (AFS or - if i understood the FAQ correctly - SFS). So the fileserver admin (or an intruder or trojan) is able to read served files cleartext.
What's required is a remote filesystem where the clients do not need to trust the service nodes for data integrity and privacy. If i did not miss something (please tell me!), the only option nowadays is stacking a local crypting fs on top of a remote fs, e.g. NCryptfs on top of NFS or AFS.
This is the usual misunderstanding of the word "firewall": Classically a firewall is just a packetfilter (that means it filters packets due to rules which only consider packetheaders). This MS document uses "firewall"="packetfilter". But most "firewall products" offer packetfilter + host IDS + content-filtering, virus-scanning transparent proxies + network IDS + more gimmicks. They are sometimes referred as "application level firewalls". This is an example:
Outgoing connection filtering (that's included in SP2)
*Really* detailed logging (seemed to have improved in SP2)
Pop-up ad blocking, Banner ad blocking, Cookie control, Policies for pop-ups, scripting, ActiveX and so on handled on a per-site basis - content-filtering transparent http proxy (hint: use a more secure browser instead)
/graf0z.
ps: Don't get the impression that i like the SP2 packetfilter - it's really inferior to professional packetfilters.
when I looked into XP's firewall, it only blocked incoming connections, not outgoing
They are definitly intruding the personal fw market: Look into "Appendix B: Netsh Command Syntax for the Netsh Firewall Ipv4 Context" for the "add allowedprogram" command - finally, they realized that there is something like trojans...
They're still far away from other packetfilters like netfilter/pf/..:
no match against source or dest ip
nothing beyond TCP/UDP/ICMP (like GRE, ESP, AH)
no subchains (or whatever You wanna call conditional ramifications/jumps)
no rate-limiting (e.g. against SYN-flood)
no NAT
it's not clear how stateful it is (i.e. does it verify TCP sequence numbers?)
protocol helpers for RPC/DCOM, but not for FTP, IRC, H.323
no tweaky guru stuff like TCP-MSS mangling for tunnels (like VPN or PPPoE)
There's still a lot of work waiting for the ms devel team...
I have to correct myself: You may use ANY packet You want (IP, IPX, whatever), as long as it
contains the "magic sequence"
is contained in a valid ethernet frame
is address to the target's MAC- or a multicast address (including broadcast).
Because of the handshake You cannot use TCP, but any UDP or ICMP (ping!) packet including the magic would do it. It has to pass the firewall (if any). The dest address could be
unicast if the last router has a static arp entry for the dest
broadcast if the last router forwards broadcast packets
multicast if You have a multicast routing path from You into the last subnet.
At least the "standard AMD Magic Packet format" of WoL is ethernet-type 0x0842, not IP (0x0800). Instead of an IP-packet with dest- and source ip address it just contains repeatedly
"FF FF FF FF FF FF 00 11 22 33 44 55"
(if 00:11:22:33:44:55 is the target MAC). So it won't pass any routers, You have to do this in an ethernet-segment. Try
# ether-wake 00:11:22:33:44:55
and catch it with Your favorite sniffer.
It would be senseless to use IP for WoL, as the arp-table of the last router has already forgotten the MAC of the dest ip and cannot resolve via arp-request it as the destination host is sleeping. If You have no machine next to Your target, You're lost.
From the article: "Oxenhielm's solution pertains to a special version of the second part of problem 16" (bold by me).
In other word's, problem no 16 is still unsolved besides special cases.
Special versions of fermats theorem were already proofed by fermat himself. But it took 300 years until Andrew Wiles and one of his students proved it generally. If You look at the history of famous mathematical conjectures (ie fermats, poincares) You'll see: prooving a special case will probably not really help prooving the general case. If You are very lucky, You get a hint how to solve the "real" problem.
DSA and ECC both do encryption by exponentation, relying on the assumtion that the reverse function - the logarithm - is infeasible with the used keylengths. They are both called "Discrete Logarithm Systems".
But the multiplication is done in completly different mathematical contexts: DSA multiplies in the rings Z/p (that are the natural numbers modulo p, p being a prime) where ECC multiplies in suitable "elliptic curve groups over finite fields" . That are finite sets of "numbers" paired with an complicated operation called "multiplication". These "numbers" behave quiet odd.
The main practical difference is the neccessary keylength. Depending on the chosen eliptic curve, ECC keys are 4-8 times smaller than DSA keys. They get much closer to the "no attack is faster than the brute force attack"-paradigm than other public key algorithms like DSA or RSA.
Unfortunatly, huge classes of suitable elliptic curves got patented.
Google for free ECC software. There are at least some libraries published by academic research groups.
A firewall/NIDS cannot inspect encrypted data if the encrypted tunnel does not end at it.
Want to attack a httpd behind a mature NIDS? Establish an SSL-session to port 443 and send Your "GET/cgi-bin/dummy.pl?AAAAAAAA..."! NIDS blinded.
To avoid this, You have to terminate the SSL-tunnel in front of Your IDS, i.e. by setting up a transparent http-proxy holding the X.509-certificate and the key-pair on Your "application layer firewall". Most products do not offer this possibility.
and NIDS is that all current systems ready for production use are based on pattern matching, just like virus scanners. It detects a "bad packet" (like one containing a standard rootshell) if it has an according signatures in its database. Additionally it can enforce protocols (i.e. by dropping evil overlapping IP-fragments). Both happens at high costs as IP-fragments and TCP-segments have to be reassembled for inspection.
These system may filter standard attacks (i.e. exploits you find at bugtraq, packetstorm) quite good, but You can image that it's easy to poke such a firewall by varying an attack. They know many standard ways of varying (like "/cgi-bin/../cgi-bin/" instead of "/cgi-bin/", or inserting NOPs into a rootshell), but there are a thousand and one way for doing the same thing, and most won't get detected.
So: Do NOT think Your $XXXXXX application level oversecure paranoia firewall ransoms You from secure network design or patching Your systems! Instead, do the usual:
use seperated subnets of different security level (like a dmz)
hold Your systems on recent patchlevel
tighten Your configs, review them with >2 eyes
use proxies (maybe with authorization). Build virus-scanner into http- and smtp-proxy
do NOT consider Your internal network "save", so don't use telnet for administration Your internal *NIX servers
The last point is due to the fact that it's too easy to inject hostile code into a browser. Most scripting attackts get NOT detected by state-of-the-art virusscanners if they are slightly modified. So consider the desktop workstations in Your network as a bunch of trojans.
To summarize: You have a excellent chance of averting 99% of all attacks (as those are known attacks of script-kiddies/zombies/...) with standard techniques like the above mentioned. You have a good chance of making a random hacker to move away to an easier target. You have almost no chance of averting a skilled hacker with time who wants to get into YOUR machines.
As far as i understood, GBDE uses - like many other crypto systems - different keys on different levels. There are "master keys" for protecting "sector keys". The master keys are only used for key-encryption, so they should be usable in slow crypting devices like cryptocards or usb cryptodongles. Since the master key never leaves such a token (master key operations are performed on an embedded chip), even a trojan with root privileges could only read data while the token is attached (in a way, they are "--x------"). Some of these cryptotokens even have an own input device (PIN-keypad) such that the passphrase for unlocking the keys cannot be sniffed.
Is it possible to do that (instead of just keeping parts of the key on an usb storage device) with freebsd/GBDE?
I think some ibm thinkpad T30 come with TCPA chip which could (at least theoretically) work as such a token, too.
... with my redhat linux 7.x/8/9 (i remember tweaking rc.sysinit in 7.something), also with BIOS (and win2k). No ps/2 needed.
I have a cherry keyboard with built-in 4x usb hub, mouse attached to it (and racing wheel;-).
I'm thinking about tinkering some more usb connectors and a switch/toggle into that keyboard so that i can connect it more than one pc, easy switching to and fro. Ok, i still need a vga switch...
The only concern I have with ISC's fix to BIND is that they just filter for that one IP address (64.94.110.11)... all Verisign has to do is change the IP in their wildcard A-record and we'll be back to square one.
wrong
You are talking about one of those on-the-fly patches released by some pissed-of admin on the same day. The ISC-patch allows you to say "the following zone are only allowed to have delegations" (like NS-records), all other data (like A-records) are ignored. That's exactly the behaviour You expect from a TLD.
Of course verisign could get around that (by putting a windcard NS-record into their TLDs), but that would be really offensive. Let's see if they will go that far...
Verisign switched from their buggy, not SMTP-compliant mailrejector "Snubby Mail Rejector Daemon v1.3" on 64.94.110.11 towards postfix (according to the banner)?
$ telnet oauwnxtrgqoiezrfgnxocrzq.net 25 Trying 64.94.110.11... Connected to oauwnxtrgqoiezrfgnxocrzq.net. Escape character is '^]'. 220 sitefinder.verisign.com VeriSign mail rejector (Postfix)
... because then mails to mistyped domains will end up waiting in MTA-queues instead of being bounced immediately (some other protocols may have weird behaviour, too). Instead:
ask your ISP for patching bind (or whatever ns-software they use)
install a patched bind (djbdns,...) locally as a caching dns
if you have no chance of using a patched nameserver (why that?), you may reject (not: drop) 64.94.110.11:80/tcp only and install one of those patches to your MTA (postfix, sendmail,...)
if you are customer of verisign, ask them for suspending their new "service"
In times of dDoS and flooding worms, ISPs should offer rate limiting initial packets to their customers, eg. by forcing rules like "max. N tcp/SYN or ICMP echo-request per IP per second"
According to this analysis, a simple packetsniffer (like tcpdump) should reveal if it's nachi: if its echo-request storm detects a living IP, a MS RPC DCOM exploit follows (eg on ports 135 or 445).
Slashdot Mirror
Nice visualization of the /. effect. Daily graph explodes at posting time of parent ;-)
Wrong. You mix up different problems. There are 'evil' protocols like ftp or ipsec or sun/rpc or ... which are not compatible with single NAT (client NATed, server not). ie. they negotiate a random second port for a data channel like ftp does. These protocols are 'bad by design'. Some of them can be NATed if the nat box tracks the negotiation ("ftp helper module").
But mr. Walker is speaking about the double NAT problem: if client (the peer that initiates a connection) and the server (the peer that receives that initial packet) are located behind NAT boxes you are lost. NO protocol is compatible to that situation.
Many propose "oh just configure portforwarding on your NAT box", but that does not scale. Imagine a bunch of workstations configured via dhcp behind NAT (typical setup in mid-range companies). How do you set up that? What are you doing as netadmin if everyday another P2P protocol pops up?
Mr. Walker's rant is sad but true. The only solutions i see are
I am sure that we all would use VoIP now if there were no NAT.
Ok, got it. Now guess my mother tongue. Tip: we do so ;-)
To be precise: they have much more noise, but You can only use a fraction of that noise for steganography. Otherwise You would destroy or significantly alter the original content of the compressed file.
It is easy to 'steganohide' content in uncompressed noisy files like tiff or wav. But that content gets destroyed by lossfull compression which is mainly used by multimedia formats (jpeg, mpeg, divx, mpg3, ...). If not, it's called a watermark, but (un)fortunately nobody found a watermark algorithm yet which is robust against lossfull codecs and adding some more noise.
So You have to steganohide Your content after compressing. But compressed files have much less noise, and that noise is not random noise but has statistical quirks. If You just hide Your content as white noise and add it to the file - thats detectable, because it changes the statistical behaviour of the file!
Instead You have to write an specific steganografic algorithm for each lossfull compression format You want to hide content in! It has to respect the 'format noise character'. That's what Niels Provos did for pnm and jpeg with outguess.
Serial numbers only affect master-slave communication (and selfwritten scripts violating rfcs), but all masters and slaves for .com & .net belong to VS. See Paul Vixies reply to the same question on NANUG.
- UML
- ipsec
- ebtables & bridge-netfilter
- robert love's preemptable patch
- LSM-hooks (which make not everybody happy:grsecurity, RSBAC
- LS-module SE-linux
- filesystem-encryption
- apci 2.5 backports
- Kernel
.config
- DVB-support
I got really tired of applying combinations of those patches to newest kernel source (due to security issues). They 're now all included to 2.6! Only MPPE-support seems still to lack.They must have beaten up Linus to get all those accepted ...
When i was a twelve year old schoolboy i read this book and was really fascinated. Same idea. /graf0z.
All other "encrypting remote filesystems" encrypt only the filetransfer, not the filestorage (AFS or - if i understood the FAQ correctly - SFS). So the fileserver admin (or an intruder or trojan) is able to read served files cleartext.
What's required is a remote filesystem where the clients do not need to trust the service nodes for data integrity and privacy. If i did not miss something (please tell me!), the only option nowadays is stacking a local crypting fs on top of a remote fs, e.g. NCryptfs on top of NFS or AFS.
The rest ist not packetfiltering:
ps: Don't get the impression that i like the SP2 packetfilter - it's really inferior to professional packetfilters.
They are definitly intruding the personal fw market: Look into "Appendix B: Netsh Command Syntax for the Netsh Firewall Ipv4 Context" for the "add allowedprogram" command - finally, they realized that there is something like trojans...
They're still far away from other packetfilters like netfilter/pf/..:
There's still a lot of work waiting for the ms devel team ...
Because of the handshake You cannot use TCP, but any UDP or ICMP (ping!) packet including the magic would do it. It has to pass the firewall (if any). The dest address could be
Read AMD whitepaper and a howto.
At least the "standard AMD Magic Packet format" of WoL is ethernet-type 0x0842, not IP (0x0800). Instead of an IP-packet with dest- and source ip address it just contains repeatedly
"FF FF FF FF FF FF 00 11 22 33 44 55"
(if 00:11:22:33:44:55 is the target MAC). So it won't pass any routers, You have to do this in an ethernet-segment. Try
# ether-wake 00:11:22:33:44:55
and catch it with Your favorite sniffer.
It would be senseless to use IP for WoL, as the arp-table of the last router has already forgotten the MAC of the dest ip and cannot resolve via arp-request it as the destination host is sleeping. If You have no machine next to Your target, You're lost.
graf0z.
In other word's, problem no 16 is still unsolved besides special cases.
Special versions of fermats theorem were already proofed by fermat himself. But it took 300 years until Andrew Wiles and one of his students proved it generally. If You look at the history of famous mathematical conjectures (ie fermats, poincares) You'll see: prooving a special case will probably not really help prooving the general case. If You are very lucky, You get a hint how to solve the "real" problem.
No, DSA != ECC.
DSA and ECC both do encryption by exponentation, relying on the assumtion that the reverse function - the logarithm - is infeasible with the used keylengths. They are both called "Discrete Logarithm Systems".
But the multiplication is done in completly different mathematical contexts: DSA multiplies in the rings Z/p (that are the natural numbers modulo p, p being a prime) where ECC multiplies in suitable "elliptic curve groups over finite fields" . That are finite sets of "numbers" paired with an complicated operation called "multiplication". These "numbers" behave quiet odd.
The main practical difference is the neccessary keylength. Depending on the chosen eliptic curve, ECC keys are 4-8 times smaller than DSA keys. They get much closer to the "no attack is faster than the brute force attack"-paradigm than other public key algorithms like DSA or RSA.
Unfortunatly, huge classes of suitable elliptic curves got patented.
Google for free ECC software. There are at least some libraries published by academic research groups.
Want to attack a httpd behind a mature NIDS? Establish an SSL-session to port 443 and send Your "GET /cgi-bin/dummy.pl?AAAAAAAA..."! NIDS blinded.
To avoid this, You have to terminate the SSL-tunnel in front of Your IDS, i.e. by setting up a transparent http-proxy holding the X.509-certificate and the key-pair on Your "application layer firewall". Most products do not offer this possibility.
These system may filter standard attacks (i.e. exploits you find at bugtraq, packetstorm) quite good, but You can image that it's easy to poke such a firewall by varying an attack. They know many standard ways of varying (like "/cgi-bin/../cgi-bin/" instead of "/cgi-bin/", or inserting NOPs into a rootshell), but there are a thousand and one way for doing the same thing, and most won't get detected.
So: Do NOT think Your $XXXXXX application level oversecure paranoia firewall ransoms You from secure network design or patching Your systems! Instead, do the usual:
- use seperated subnets of different security level (like a dmz)
- hold Your systems on recent patchlevel
- tighten Your configs, review them with >2 eyes
- use proxies (maybe with authorization). Build virus-scanner into http- and smtp-proxy
- do NOT consider Your internal network "save", so don't use telnet for administration Your internal *NIX servers
The last point is due to the fact that it's too easy to inject hostile code into a browser. Most scripting attackts get NOT detected by state-of-the-art virusscanners if they are slightly modified. So consider the desktop workstations in Your network as a bunch of trojans.To summarize: You have a excellent chance of averting 99% of all attacks (as those are known attacks of script-kiddies/zombies/...) with standard techniques like the above mentioned. You have a good chance of making a random hacker to move away to an easier target. You have almost no chance of averting a skilled hacker with time who wants to get into YOUR machines.
Is it possible to do that (instead of just keeping parts of the key on an usb storage device) with freebsd/GBDE?
I think some ibm thinkpad T30 come with TCPA chip which could (at least theoretically) work as such a token, too.
I have a cherry keyboard with built-in 4x usb hub, mouse attached to it (and racing wheel ;-).
I'm thinking about tinkering some more usb connectors and a switch/toggle into that keyboard so that i can connect it more than one pc, easy switching to and fro. Ok, i still need a vga switch ...
ps: anybody experiances with soundblaster extigy or an audigy2nx and linux?
wrong
You are talking about one of those on-the-fly patches released by some pissed-of admin on the same day. The ISC-patch allows you to say "the following zone are only allowed to have delegations" (like NS-records), all other data (like A-records) are ignored. That's exactly the behaviour You expect from a TLD.
Of course verisign could get around that (by putting a windcard NS-record into their TLDs), but that would be really offensive. Let's see if they will go that far ...
Verisign switched from their buggy, not SMTP-compliant mailrejector "Snubby Mail Rejector Daemon v1.3" on 64.94.110.11 towards postfix (according to the banner)?
...
$ telnet oauwnxtrgqoiezrfgnxocrzq.net 25
Trying 64.94.110.11...
Connected to oauwnxtrgqoiezrfgnxocrzq.net.
Escape character is '^]'.
220 sitefinder.verisign.com VeriSign mail rejector (Postfix)
At least, they are now able to bounce properly
/graf0z.
(Linux/netfilter example:
Would not really help, but lower the impact.