- Welcome to Networking-Forums.com.
We're Here to Help!
Recent posts
#1
Homework Help / Re: Block diagram as text soft...
Last post by deanwebb - Yesterday at 07:21:45 AMFor a free version of Powerpoint, which has shape art in it, there's LibreOffice suite.
#2
Homework Help / Re: Block diagram as text soft...
Last post by icecream-guy - December 28, 2025, 07:09:28 AMI'd say Visio, but expensive
#3
Homework Help / Block diagram as text software...
Last post by networkloser - December 28, 2025, 07:02:45 AMThere are various stuffs for UML like plantUML etc. But what about for network block diagram. Are there anything?
I want to make diagram as code.
For example something like this:
A->B->C
Where A, B and C will be blocks. Request-response cycle will be shown.
I want to make diagram as code.
For example something like this:
A->B->C
Where A, B and C will be blocks. Request-response cycle will be shown.
#4
Homework Help / Re: How to study network layer...
Last post by networkloser - December 28, 2025, 07:01:07 AMthanks i will have a look.
#5
Homework Help / Re: How to study network layer...
Last post by icecream-guy - December 24, 2025, 08:26:55 AMHave you read Cisco Press - CCIE Professional Development Routing TCPIP, Volume I ?
#6
Homework Help / Re: How to study network layer...
Last post by networkloser - December 23, 2025, 12:25:44 AMI know subnetting. Routing algorithms make me faint.
#7
Homework Help / Re: How to study network layer...
Last post by deanwebb - December 22, 2025, 07:23:42 PMQuote from: networkloser on December 22, 2025, 04:57:16 AMi know ipv4 has 32 bits. ipv4 datagram format etc. only. not a lot i can recall.
Start with this information: http://www.tcpipguide.com/free/t_IPSubnetAddressingSubnettingConcepts.htm
Sections linked from the main page, and keep in mind that classless addressing is how we do things. A/B/C networks aren't used like that anymore, thanks to private IP spaces defined in RFC 1918.
#8
Homework Help / Re: How to study network layer...
Last post by icecream-guy - December 22, 2025, 06:32:53 AMstart with subnetting, learn to subnet, it is the basis of network layer, once you can subnet, the network layer will be more understandable.
#9
Homework Help / Re: How to study network layer...
Last post by networkloser - December 22, 2025, 04:57:16 AMi know ipv4 has 32 bits. ipv4 datagram format etc. only. not a lot i can recall.
#10
Forum Lobby / Stumbling into the API...
Last post by deanwebb - December 21, 2025, 08:34:25 AMAs a self-styled smartass, I am prone to bouts of tomfoolery and hijinks. This weekend, I texted the following to the family group chat:
"I will be leaving to get dinner and should be back by 6:30 pm. If you would like to continue to receive status updates, text YES to this number. Normal text and/or data rates will apply."
On one of the phones, there was a button to auto-send a YES response.
I had stumbled into the API!
Other family members tried to get that response with less, but it was clear that the full verbiage needed to be in there to make it work. I got a few more of those and we had a laugh.
Today, I went for two:
"Your appointment for 9:30 am is scheduled. Text CONFIRM to this number to confirm your appointment or CANCEL to cancel it. Normal text and/or data rates will apply."
The result? Both a CONFIRM and a CANCEL button appeared on the other phone for autoresponses.
This means, of course, that the API is invoked via scanning the text message itself. There are no back-end flags in my packets or anything like that, it's straight-up giving the system a prompt and getting a response out of it that leverages into the target system adding executable code as a result of reading the prompt.
As a security person, I find the upshot of this to be chilling. There are other functions that could be automated and if the API simply attaches code to a message based on its wording without any verification of authenticity or authority, then it is a massive hole in the system. To defend against possible abuses, I know that I have some autoresponders set up with professionals that I make appointments with. Those I already know. If I make a new appointment with a new person and get an autoresponse in the time frame of that appointment, then I'm OK with that. What's most dangerous is some kind of scam targeting people over 50 who are already at higher risk of implicitly trusting without verification. By using official-looking texts, it already increases the risk that they make an error. By having the system attach code for autoresponses, it makes them look that much more legitimate and, therefore, gives such attacks a higher conversion rate.
Which thought leads me to a larger zero-trust concept: cybersecurity also involves the concepts and philosophies surrounding our work. When we unequivocally accept any new paradigm without sufficient testing, verification, and cautious observation, then we place ourselves into a potentially unacceptably high level of risk. And when we let proven flaws remain in our systems because we choose not to disrupt production, then we know we are set up for a terrible tragedy.
"I will be leaving to get dinner and should be back by 6:30 pm. If you would like to continue to receive status updates, text YES to this number. Normal text and/or data rates will apply."
On one of the phones, there was a button to auto-send a YES response.
I had stumbled into the API!
Other family members tried to get that response with less, but it was clear that the full verbiage needed to be in there to make it work. I got a few more of those and we had a laugh.
Today, I went for two:
"Your appointment for 9:30 am is scheduled. Text CONFIRM to this number to confirm your appointment or CANCEL to cancel it. Normal text and/or data rates will apply."
The result? Both a CONFIRM and a CANCEL button appeared on the other phone for autoresponses.
This means, of course, that the API is invoked via scanning the text message itself. There are no back-end flags in my packets or anything like that, it's straight-up giving the system a prompt and getting a response out of it that leverages into the target system adding executable code as a result of reading the prompt.
As a security person, I find the upshot of this to be chilling. There are other functions that could be automated and if the API simply attaches code to a message based on its wording without any verification of authenticity or authority, then it is a massive hole in the system. To defend against possible abuses, I know that I have some autoresponders set up with professionals that I make appointments with. Those I already know. If I make a new appointment with a new person and get an autoresponse in the time frame of that appointment, then I'm OK with that. What's most dangerous is some kind of scam targeting people over 50 who are already at higher risk of implicitly trusting without verification. By using official-looking texts, it already increases the risk that they make an error. By having the system attach code for autoresponses, it makes them look that much more legitimate and, therefore, gives such attacks a higher conversion rate.
Which thought leads me to a larger zero-trust concept: cybersecurity also involves the concepts and philosophies surrounding our work. When we unequivocally accept any new paradigm without sufficient testing, verification, and cautious observation, then we place ourselves into a potentially unacceptably high level of risk. And when we let proven flaws remain in our systems because we choose not to disrupt production, then we know we are set up for a terrible tragedy.