lainchan archive - /λ/ - 19498
[ Return /
Go to bottom ]
File: 1476851207763.png (37.72 KB, 229x300, wtfamicasting.jpeg)
I have a pretty good experience with programming in C and have put significant work into a few non-trivial projects, but my knowledge of networking leaves much to be desired. I've taken a networking course and done simple toy programs like a port scanner and a simple client-server messenger, but I'm not really sure how to progress to an intermediate and eventually expert level. I want to become a networking wizard.
Any tips, or suggestions on what I could build to gain some real practical experience with the full TCP-IP stack and maybe learn how and why to use raw sockets etc.?
Any tips, or suggestions on what I could build to gain some real practical experience with the full TCP-IP stack and maybe learn how and why to use raw sockets etc.?
You can sniff traffic by asking for raw sockets, and also inject packets with write() (directly to the network device).
You could use libpcap as well for sniffing, which makes it easier. With raw packets you'd have to make the decoding routines yourself, look at the header and determine if it's Ethernet and what protocol it carries (IP, ICMP..) then strip the ethernet header and look at the IP header and determine if it's TCP or UDP, and so on. What you could do for it not to be just an excercise, is a genral purpose CLI spoofer.
The book to read is without a doubt TCP illustrated.
Volume 1 discusses the protocols themselves
Volume 2 discusses the implementation, I really like this one
You could use libpcap as well for sniffing, which makes it easier. With raw packets you'd have to make the decoding routines yourself, look at the header and determine if it's Ethernet and what protocol it carries (IP, ICMP..) then strip the ethernet header and look at the IP header and determine if it's TCP or UDP, and so on. What you could do for it not to be just an excercise, is a genral purpose CLI spoofer.
The book to read is without a doubt TCP illustrated.
Volume 1 discusses the protocols themselves
Volume 2 discusses the implementation, I really like this one
File: 1476896743829.png (617.46 KB, 200x150, tcp.jpg)
>>19505
>without a doubt TCP illustrated
Seconded,
TCP/IP Illustrated is an excellent resource.
Following this I'd suggest cracking open both the modern BSD and the Linux network stacks and really taking a go at groking it proper.
Get yourself an adderall script and get cracking m80. Your path is long, but the way is paved with gold for those who seek truth.
>without a doubt TCP illustrated
Seconded,
TCP/IP Illustrated is an excellent resource.
Following this I'd suggest cracking open both the modern BSD and the Linux network stacks and really taking a go at groking it proper.
Get yourself an adderall script and get cracking m80. Your path is long, but the way is paved with gold for those who seek truth.
what do lains think of Andrew Tannenbaum's "Computer Networks" book?
>>19511
Vol2 is written using an older version of the BSD tcp stack, but it is still a solid way to learn how you might DIY. The tcp standard hasn't changed too terribly much since its implementation. A couple things you will be missing there is ipv6, and I don't think it touches on mobile IP.
Another book that might be of interest is Beej's guide https://beej.us/guide/bgnet/
Vol2 is written using an older version of the BSD tcp stack, but it is still a solid way to learn how you might DIY. The tcp standard hasn't changed too terribly much since its implementation. A couple things you will be missing there is ipv6, and I don't think it touches on mobile IP.
Another book that might be of interest is Beej's guide https://beej.us/guide/bgnet/
File: 1478146789998.png (631.62 KB, 200x125, gandalf-004.jpg)
OP here. After doing some reading and a lot of googling I've managed to combine an ARP poison attack with DNS spoofing on my LAN using pure C sockets (I'm aware that things like ettercap and libpcap exist, but that's obviously not the point). I now have the ability to sniff all traffic that passes through my NAT, and also redirect my friends google queries to gay porn sites. So this is what it feels like to be the NSA.
Tell me about your networking exploits. What have you done, what do you know how to do? Nothing illegal or unethical; just for educational purposes.
Tell me about your networking exploits. What have you done, what do you know how to do? Nothing illegal or unethical; just for educational purposes.
>>19901
You'll have to account for HSTS. Which can at some junctures, be mitigated by redirecting the DNS to a domain that is not on the HSTS list: mail.google.com becomes email.google.com, etc.
Also you can play with JS botnets. If you set the the HTTP header for cache time to several years, any file you MITM will be cached. Think of common JS files that are served through CDNs.
You'll have to account for HSTS. Which can at some junctures, be mitigated by redirecting the DNS to a domain that is not on the HSTS list: mail.google.com becomes email.google.com, etc.
Also you can play with JS botnets. If you set the the HTTP header for cache time to several years, any file you MITM will be cached. Think of common JS files that are served through CDNs.
>>19906
HSTS has been a thorn in my side, but luckily most sites don't use it. Another problem is that my DNS injections are really crude. I just replace the IP of all class A RR answers, which doesn't work on a lot of sites. I need to do more reading on DNS.
>If you set the the HTTP header for cache time to several years, any file you MITM will be cached. Think of common JS files that are served through CDNs.
This sounds difficult (especially since I don't know JS too well) but potentially amazing.
HSTS has been a thorn in my side, but luckily most sites don't use it. Another problem is that my DNS injections are really crude. I just replace the IP of all class A RR answers, which doesn't work on a lot of sites. I need to do more reading on DNS.
>If you set the the HTTP header for cache time to several years, any file you MITM will be cached. Think of common JS files that are served through CDNs.
This sounds difficult (especially since I don't know JS too well) but potentially amazing.
File: 1478225087632.png (206.25 KB, 200x154, tumblr_o-blivia_151947570664o1.png)
Andrew tennanbaum's networking series is very comprehensive but its a slow read and tends to be intensely theoretical.
a few little projects
-build an encrypted recursive dns with unbound / dnscrypt
-build a router with pfsense
-read the rfc on BGP
-learn to open sockets with python and run your own private server on your local subnet
-register a free subdomain at afraid.org/freedns and play with the different zone records and things you can do with the bind system
-create a vpn / learn to dyndns
-wireshark
-ciscos packetswitcher program for network management of protocols like ospf / wiring / vlans
-rent a vps
a few little projects
-build an encrypted recursive dns with unbound / dnscrypt
-build a router with pfsense
-read the rfc on BGP
-learn to open sockets with python and run your own private server on your local subnet
-register a free subdomain at afraid.org/freedns and play with the different zone records and things you can do with the bind system
-create a vpn / learn to dyndns
-wireshark
-ciscos packetswitcher program for network management of protocols like ospf / wiring / vlans
-rent a vps
File: 1478503363570.png (38.23 KB, 200x153, howtopose.jpg)
>>20032
>1. Can you talk in general what kind of non-trivial C projects you've done?
I would be a little too close to doxing myself if I did that, but it's related to secure communications.
>2. Why Google? Try SearX or ixquick
I'll check both those out.
>3. Any new cool projects you made out of this like that redirector you've mentioned?
I've just been playing around with DNS spoofing the past few days, trying different things and learning about how DNS works. I tried to spoof the DNS request rather than the response (i.e. I drop the target's request, spoof my own request with the same ID, then let the response through to the target), but that doesn't work. I guess the client has to verify that the original request query name matches the query name in the response. My new working method has me doing a single initial DNS request for the "trap" domain, storing the result, and then replacing DNS responses to the target with my stored result while leaving the target's query intact.
I haven't decided what my next project will be yet. I'm thinking maybe a router like >>19920 suggested. I'm also beginning to learn how to use tcpdump alongside/instead of wireshark.
>4. Still going at it with TCPIP illustrated? How beneficial and practical is it
I'm finding it invaluable as a protocol reference, which is exactly what I needed. I've been reading through RFC's as well, but those can be pretty verbose.
>1. Can you talk in general what kind of non-trivial C projects you've done?
I would be a little too close to doxing myself if I did that, but it's related to secure communications.
>2. Why Google? Try SearX or ixquick
I'll check both those out.
>3. Any new cool projects you made out of this like that redirector you've mentioned?
I've just been playing around with DNS spoofing the past few days, trying different things and learning about how DNS works. I tried to spoof the DNS request rather than the response (i.e. I drop the target's request, spoof my own request with the same ID, then let the response through to the target), but that doesn't work. I guess the client has to verify that the original request query name matches the query name in the response. My new working method has me doing a single initial DNS request for the "trap" domain, storing the result, and then replacing DNS responses to the target with my stored result while leaving the target's query intact.
I haven't decided what my next project will be yet. I'm thinking maybe a router like >>19920 suggested. I'm also beginning to learn how to use tcpdump alongside/instead of wireshark.
>4. Still going at it with TCPIP illustrated? How beneficial and practical is it
I'm finding it invaluable as a protocol reference, which is exactly what I needed. I've been reading through RFC's as well, but those can be pretty verbose.