Explain the difference between v1, v2c and v3 Traps PDU/format.
This requires you to go through the RFC documents, which means this is not programming related, and probably belongs to ServerFault.
Give you some hints:
SNMP v1 defines a special TRAP message format, different from other messages (such as GET). https://www.rfc-editor.org/rfc/rfc1157#page-27 This message format is not used any more in SNMP v2 and v3. If an SNMP agent sends out such TRAP messages for v2 or v3, that can be a bug.
Since v2, TRAP starts to use the common message format (the same as GET and so on). So it is called SNMPv2-Trap-PDU. https://www.rfc-editor.org/rfc/rfc3416#page-22
SNMP v3 introduces the security model to all messages, so TRAP receives such update too. It is still based on SNMPv2-Trap-PDU.
SNMPv2 defines traps in a slightly different way.
In a MIB, SNMPv1 traps are defined as Trap-PDU, SNMPv2 traps are defined as NOTIFICATION-TYPE. SNMPv2 also does away with the notion of generic traps instead, it defines many specific traps (properly speaking, notification) in public MIBs.
SNMPv3 traps, which are simply SNMPv2 traps with added authentication (credentials based) (Common authentication Techniques MD5 or SHA) and privacy capabilities(Encryption Techniques - DES,3DES,AES128/192/256).
Most SNMP implementation support only v1.
Reference_1 Reference_2
Below is the SNMP4j code to send snmpv3 trap.
public void sendTrap_Version3() {
//TrasportMapping
TransportMapping transport;
try {
transport = new DefaultUdpTransportMapping();
transport.listen();
//Creating SNMP object
snmp = new Snmp(transport);
//Creating USM
USM usm = new USM(SecurityProtocols.getInstance(), new OctetString(MPv3.createLocalEngineID()), 0);
SecurityModels.getInstance().addSecurityModel(usm);
// Add user to the USM
snmp.getUSM().addUser(
new OctetString("MD5DES"),
new UsmUser(new OctetString("MD5DES"), AuthMD5.ID, new OctetString("MD5DESUsrAuthPwd"), PrivDES.ID,
new OctetString("MD5DESUsrPrivPwd")));
// Create the target
Address targetAddress = GenericAddress.parse("udp:10.120.7.107/162");
UserTarget target = new UserTarget();
target.setAddress(targetAddress);
target.setRetries(3);
target.setTimeout(5000);
target.setVersion(SnmpConstants.version3);
target.setSecurityLevel(SecurityLevel.AUTH_PRIV);
target.setSecurityName(new OctetString("MD5DES"));
// Create PDU
ScopedPDU pdu = new ScopedPDU();
pdu.add(new VariableBinding(SnmpConstants.sysUpTime, new TimeTic(new Date().toString())));
pdu.add(new VariableBinding(SnmpConstants.snmpTrapOID,SnmpConstants.linkDown));
pdu.add(new VariableBinding(SnmpConstants.snmpTrapAddress, new IpAddress("127.3.4.1")));
pdu.add(new VariableBinding(new OID("1.3.6.1.2.1.2.2.1.1.1"), new Integer32(1)));
pdu.setType(ScopedPDU.TRAP);
snmp.send(pdu, target);
} catch (IOException e) {
e.printStackTrace();
}
}
Related
I am doing development for WSN in Omnet. I want to sniff a unicast message but I don't have an idea how can i do it in Omnet. I made some research but i couldn't found any method for that
When I send data to another node, I am sending it as an unicast with this method :
cModule *nodeIndex = flatTopolojiModulu->getSubmodule("n", i);//n is array
sendDirect(new cMessage("msg"), nodeIndex, "in");
I am using sendDirect method because I am working on wireless network. According to this description : https://stackoverflow.com/a/36082721/5736731
sendDirect method is usually the case in wireless networks.
But when send message with sendDirect, a message is being handled by receiver node. For example, according to code example above:
if i=2, message that is sent only can handle by node which has index "2" from
void AnyClassName::handleMessage(cMessage *msg) function
An example of broadcasting messages can be found in OMNeT++ Manual.
You should create only one instance of message that all nodes have to receive, and then send a new copy of this message to each node in loop. The dup() method has to be used to create the copy of a message.
cMessage * msg = new cMessage("msg");
// totalN is the total number of nodes
for (int i = 0; i < totalN; ++i) {
cModule *nodeIndex = flatTopolojiModulu->getSubmodule("n", i);
sendDirect(msg->dup(), nodeIndex, "in");
}
// original message is no longer needed
delete msg;
Does the send() in omnet++ set the source address of the packet to the current host address?
Why am I asking? because I'm trying to code a class for a malicious host "Eve" that performs a replay attack.
void MalAODVRouter::handleMessage(cMessage *msg)
{
cMessage *ReplayMsg = msg->dup();
AODVRouting::handleMessage(msg);
capturedMsgs++;
if (capturedMsgs==10) // One out of every 10 packets (frequency of replay)
{
//we can add a delay before sending the copy of the message again (1 time unit)
sendDelayed(ReplayMsg, 1,"ipOut");
ReplayedMsgs++;
std::cout<<"Launched Replay Packet!\n";
ev<<"Launched Replay Packet!\n";
this->capturedMsgs=0;
// }
}
}
You can see at the beginning of my code snippet I tried using the function dup() to duplicate a packet (msg) Eve's receives while its on it's on its way to the legitimate destination.
Now, can I send the duplicated packet later and it would be having the original source address OR should I dig deeper into layers to fake the source address to have Bob's address instead of Eve's? like below:
/*UDPPacket *udpPacket = dynamic_cast<UDPPacket *>(msg);
AODVControlPacket *ctrlPacket = check_and_cast<AODVControlPacket *>(udpPacket->decapsulate());
IPv4ControlInfo *udpProtocolCtrlInfo = dynamic_cast<IPv4ControlInfo *>(udpPacket->getControlInfo());
ASSERT(udpProtocolCtrlInfo != NULL);
IPv4Address sourceAddr = udpProtocolCtrlInfo->getSrcAddr(); //get Source Address
IPv4Address destinationAddr = udpProtocolCtrlInfo->getDestAddr(); //get Destination Address
IPv4Address addr = getSelfIPAddress();
if (addr != destinationAddr) // if it is not destined for "Eve"
{
UDPPacket *ReplayUDPPacket = udpPacket;
AODVControlPacket *ReplayCtrlPacket = check_and_cast<AODVControlPacket *>(ReplayUDPPacket->decapsulate());
IPv4ControlInfo *ReplayUDPProtocolCtrlInfo = dynamic_cast<IPv4ControlInfo *>(ReplayUDPPacket->getControlInfo());
ASSERT(ReplayUDPProtocolCtrlInfo != NULL);
ReplayUDPProtocolCtrlInfo->setSrcAddr(sourceAddr); //Forge Source
ReplayUDPProtocolCtrlInfo->setDestAddr(destinationAddr); //Keep Destination
*/
//we can add a delay before sending the copy of the message again (1 time unit)
sendDelayed(ReplayMsg, 1,"ipOut");
ReplayedMsgs++;
std::cout<<"Launched Replay Packet!\n";
ev<<"Launched Replay Packet!\n";
this->capturedMsgs=0;
Does the send() method automatically sets the source address of the outgoing packet to the current host address? If so, then my replay attempt is not working...
send() is an OMNeT++ API call. As OMNeT++ is just a generic discrete event simulation framework, it does not know anything about the model code (so it cannot and should not manipulate it). IP address is a defined in the INET framework so only code from the INET framework can change it.
On the other hand the modules in the standard host below you module can do whatever they want before the packet is sent out to the network. Now in this actual case, the source IP address is determined by the control info that is attached to the packet. dup()-ing the packet copies that information too, so the IP address will be the same.
Introduction
I'm trying to create a port-forwarding sample with tcp connections, so I need map client identification with his socket. When the client requests port-forwarding, I have to know who owns the sockets.
To do that, I created the following code:
std::map<std::string, tcp::socket> box_map;
std::map<std::string, tcp::socket>::iterator it;
it = box_map.find(id);
if (it != box_map.end())
return;
else{
box_map.insert(std::pair<std::string, tcp::socket>(id,s));
return;
}
Problem
But I got the following error:
error: use of deleted function ‘boost::asio::basic_stream_socket<boost::asio::ip::tcp>::basic_stream_socket(const boost::asio::basic_stream_socket<boost::asio::ip::tcp>&)’
tcp::socket is not copy constructible. So you'd have to construct the new pair in-place by moving your socket using emplace:
box_map.emplace(id, std::move(s));
Alternatively, you could just still use insert and just move into the pair you're constructing:
box_map.insert(std::make_pair(id, std::move(s)));
Is there any example on how to do constrained delegation with Java 8/7. I tried searching around with no luck
Best Regards
Here is the Java 8 code snippet that allows to generate a SPNEGO token with TGS ticket for an impersonated user:
GSSManager manager = GSSManager.getInstance();
GSSName userName = manager.createName("targetUser", GSSName.NT_USER_NAME);
GSSCredential impersonatedUserCreds =
((ExtendedGSSCredential)serviceCredentials).impersonate(userName);
final Oid KRB5_PRINCIPAL_OID = new Oid("1.2.840.113554.1.2.2.1");
GSSName servicePrincipal =
manager.createName("HTTP/webservice-host.domain.ltd", KRB5_PRINCIPAL_OID);
ExtendedGSSContext extendedContext =
(ExtendedGSSContext) manager.createContext(servicePrincipal,
new Oid("1.3.6.1.5.5.2"),
impersonatedUserCreds,
GSSContext.DEFAULT_LIFETIME);
final byte[] token = extendedContext.initSecContext(new byte[0], 0, 0);
Beware extendedContext is not established yet. Multiple rounds with server may be required.
A simple demonstration code is available at https://github.com/ymartin59/java-kerberos-sfudemo
You may also refer to the follow project code: https://github.com/tellisnz/collared-kerberos
Is it possible to configure Lync 2013 to only send a single 180/183 ringing back upstream after an INVITE to Lync triggers multiple INVITEs to Lync subscriber endpoints that each end up generating a 180/183 message.
In case of simultaneous ring, I want Lync to consume all these 180s to avoid unnecessary messaging back to the originator INVITE'ing Lync that is behind a SBC.
It seems to be acting as a forking proxy rather than b2bua.
You're right by saying Lync forks calls. If a user has multiple endpoints, Lync will fork the call to each endpoint and in return each endpoint will return the ringing response.
You can create an MSPL script to catch 180 responses. Since MSPL is stateless, it would require a backing application (a ServerApplication) that checks if a 180 response is already sent for the current call, and block subsequent ringing responses. Based on the assumption that for all requests the CallID header will be identical, you can then decide which responses to send and which not.
A simple MSPL would be something like:
<lc:applicationManifest
lc:appUri="http://www.contoso.com/DefaultRoutingScript"
xmlns:lc="http://schemas.microsoft.com/lcs/2006/05">
<lc:responseFilter reasonCodes="1XX" />
<lc:proxyByDefault action="true" />
<lc:splScript><![CDATA[
if (sipResponse && sipResponse.StatusCode == 180)
{
Dispatch("OnResponse");
}
]]></lc:splScript>
</lc:applicationManifest>
Then in your server application you handle the OnResponse event, I imagine something like this:
public void OnResponse(object sender, ResponseReceivedEventArgs e)
{
if (e.Response.StatusCode == 180)
{
var callIdHeader = e.Response.AllHeaders.FindFirst(Header.StandardHeaderType.CallID);
if (callIdHeader != null)
{
var callId = callIdHeader.Value;
if (ShouldSendRingingResponse(callId))
{
e.ClientTransaction.ServerTransaction.SendResponse(e.Response);
}
}
}
}
public bool ShouldSendRingingResponse(string callId) { .... }
Then you can create some logic in the ShouldSendRingingResponse function to see whether to send the 180 response or not.
Note that I did not test this, it's just a basic outline of how I would attempt to handle the situation.
There isn't a way to prevent this in Lync; however, typically an AudioCodes SBC will be deployed too that contains an option to handle this scenario.
Multiple 18x:
The device supports the interworking of different support for multiple18x responses (including 180 Ringing, 181 Call is Being Forwarded, 182 Call Queued,and 183 Session Progress) that are forwarded to the caller. The UA can be configured as supporting only receipt of the first 18x response (i.e., the device forwards only this response to the caller), or receipt of multiple 18x responses (default). This is configured by the IP Profile parameter, 'SBC Remote Multiple 18x Support